Comment on Elasticsearch node crashes can cause data lossComments−klapinat0r11ySuggested reading -- the link.by not fsync'ing each operation (though one can configure ES to do so).It may not be default, but we've seen, again and again, how people are influenced by what they read about a database (e.g. MongoDB).The lesson by now should be: always know your DB.−sitkack11yFsync should always be on by default. Require the user to turn it off. I'd even argue that `fsync` itself is broken and that semantics should be inverted.−eternalban11yWhat about pervasive virtualization? The issue here is not really fsync. A fault-tolerant in-memory cluster should not lose data.−sitkack11yWrites should be durable by whatever means the platform deems durable. Durable should be the default. It should take work to have non-durable io.−andrewdanks11yalways know your DBTrue, but Elasticsearch is not intended to be a permanent datastore.
Comments
Suggested reading -- the link.
It may not be default, but we've seen, again and again, how people are influenced by what they read about a database (e.g. MongoDB).
The lesson by now should be: always know your DB.
Fsync should always be on by default. Require the user to turn it off. I'd even argue that `fsync` itself is broken and that semantics should be inverted.
What about pervasive virtualization? The issue here is not really fsync. A fault-tolerant in-memory cluster should not lose data.
Writes should be durable by whatever means the platform deems durable. Durable should be the default. It should take work to have non-durable io.
True, but Elasticsearch is not intended to be a permanent datastore.