<story><title>Call me maybe: Elasticsearch 1.5.0</title><url>https://aphyr.com/posts/323-call-me-maybe-elasticsearch-1-5-0</url></story><parent_chain></parent_chain><comment><author>teraflop</author><text>&amp;gt; How often the translog is fsynced to disk. Defaults to 5s. [...] In this test we kill random nodes and restart them. [...] In Elasticsearch, write acknowledgement takes place before the transaction is flushed to disk, which means you can lose up to five seconds of writes by default. In this particular run, ES lost about 10% of acknowledged writes.&lt;p&gt;Something bothers me about this: if the bug was merely a failure to call fsync() before acknowledging an operation, then killing processes shouldn&amp;#x27;t be enough to cause data loss. Once you write to a file and the syscall returns, the written data goes into the OS&amp;#x27;s buffers, and even if the process is killed it won&amp;#x27;t be lost. The only time fsync matters is if the entire machine dies (because of power loss or a kernel panic, for instance) before those buffers can be flushed.&lt;p&gt;So is the data actually not even making it to the OS before being acked to the client? Or is Jepsen doing something more sophisticated, like running each node in a VM with its own block device instead of sharing the host&amp;#x27;s filesystem?</text></comment>
<story><title>Call me maybe: Elasticsearch 1.5.0</title><url>https://aphyr.com/posts/323-call-me-maybe-elasticsearch-1-5-0</url></story><parent_chain></parent_chain><comment><author>Meekro</author><text>Elasticsearch has its flaws, but are there really any alternatives that do what it does? In my case, I need to do fulltext search across millions of documents -- nearly a TB of text in all, and still growing. Many database engines can do basic fulltext, but what else can scale like Elasticsearch does while offering powerful fulltext features like fuzzy matching and &amp;quot;more like this?&amp;quot;</text></comment>