What happens when one of the replicas dies temporary/permanently and how does it relate with data consistency?
For example let's consider this situation:
I made an update of a document inside fruits table,
rethinkdb answered me with ok and then immediately meteor hits this database
But luckily I had a cluster configured with the following requirements met: http://www.rethinkdb.com/docs/failover/
But it looks like in this scenario I lose this one particular update and probably something else that has not been replicated yet, while application still thinks the data is reliably saved...
I'm not quite understand how I should design my application in order to make it tolerant to such behavior, it seems to be incredible complex
What is a common practice? Any advice?
Thanks
RethinkDB doesn't acknowledge a write before it has propagated to a majority of the table's replicas. So unless more than one server fail at the same time (assuming you have 3 replicas overall), you will never lose a write that has been confirmed.
The only exception is if you explicitly set the write_acks on the table to "single". You can find more details of this setting and its consequences in http://www.rethinkdb.com/docs/consistency/