You're likely to lose data in *any* deployment with the walogs turned off.
And, to reiterate what Sean says, I wouldn't really consider any benchmark with the walogs turned off valid except for "internal" benchmarks (ones where we evaluate components only within Accumulo for the sake of improving Accumulo itself and not comparing it to other systems).
walog provides data loss protection in a specific set of circumstances. Most of our deployments are under a different set of circumstances. Accumulo is only one part of our systems and we have other mechanisms for protecting against the loss of data. We find the walog actually becomes a bottleneck in certain circumstances and so turning it off increases the overall reliability of our system.
On Sat, May 17, 2014 at 04:27:29PM -0400, Josh Elser wrote:
Absolutely, if you restrict a problem, you can work around it in other ways. Not going to argue that.
Since this is a user list though, I got very worried seeing something that roughly says "I'm benchmarking Accumulo with the WALs off". If you're providing resiliency against data lost using other tactics, that's fine, I just wanted to make sure that users who read this thread later don't think that running tests against Accumulo with the WALs off is "normal".
Looking forward to see the full picture of the benchmarks!
Disabling walogs in the shell does not require a tserver restart, but I am not sure about the minor compaction setting.
The advantage of setting the config in the shell is that you do not have copy the config file across the cluster or worry about it being inconsistent. The advantage of the config file is that it will survive re-initialization of Accumulo. On Sat, May 17, 2014 at 6:22 PM, Josh Elser <[EMAIL PROTECTED]> wrote:
NEW: Monitor These Apps!
Apache Lucene, Apache Solr and all other Apache Software Foundation projects and their respective logos are trademarks of the Apache Software Foundation.
Elasticsearch, Kibana, Logstash, and Beats are trademarks of Elasticsearch BV, registered in the U.S. and in other countries. This site and Sematext Group is in no way affiliated with Elasticsearch BV.
Service operated by Sematext