<div dir="ltr"><div>Hi,</div><div><br><div>I've waited for someone to jump in and say this, but it hasn't happened. You really, really don't want to try dealing with netsplits and application failover in an app specific manner. It is not safe, and you will likely lose data. You really need a consensus algorithm like raft or paxos to handle this type of thing safely, or else you will end up with conflicting data on both sides of the partition.</div><div><br></div><div>It may be quite a large dependency to rely on, but riak 2.0 has strongly consistent keys[1] that you could use to build a lock server to point to the active master server. Alternatively you could use riak_ensemble[2] directly to build a custom solution.</div><div><br></div><div>Lastly, you can simply choose to not use failover and accept that when the primary goes down you will be offline until it comes back up. The secondary is just there to provide disaster recovery in case the primary is irrecoverable. This is a much safer and simpler solution, and one historically used by conventional databases with both asynchronous and synchronous replication. If you must have some level of fault tolerance/ HA you can use paxos. If your application can handle eventual consistency and the data types fit the model, you could try to use CRDTs [3]. That would allow you 100% availability and even allow writes to happen to both servers at once!</div><div><br></div><div>I can't stress enough how important it is to not build ad-hoc failover protocols for this purpose. It will bite you. I've been bitten before, and so have many other people relying on this mechanism. While it may seem easier than using a proper distributed systems protocol at first, when you lose customer data in production, you quickly learn that easy isn't best.</div><div><br></div><div>Best wishes,</div><div>Andrew</div><div><br></div><div>[1] <a href="http://docs.basho.com/riak/latest/dev/advanced/strong-consistency/">http://docs.basho.com/riak/latest/dev/advanced/strong-consistency/</a></div></div><div>[2] <a href="https://github.com/basho/riak_ensemble">https://github.com/basho/riak_ensemble</a></div><div>[3] <a href="https://en.wikipedia.org/wiki/Conflict-free_replicated_data_types">https://en.wikipedia.org/wiki/Conflict-free_replicated_data_types</a></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 20, 2014 at 9:56 AM, Mark Nijhof <span dir="ltr"><<a href="mailto:mark.nijhof@cre8ivethought.com" target="_blank">mark.nijhof@cre8ivethought.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thank you!</div><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Thu, Nov 20, 2014 at 3:51 PM, Imants Cekusins <span dir="ltr"><<a href="mailto:imantc@gmail.com" target="_blank">imantc@gmail.com</a>></span> wrote:<br></span><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">the code is in<br>
<br>
<a href="https://github.com/aminishiki/distr_netsplit.git" target="_blank">https://github.com/aminishiki/distr_netsplit.git</a><br>
<br>
any comments are welcome!<br>
</blockquote></span></div><br><br clear="all"><span class=""><div><br></div>-- <br><div><div dir="ltr">Mark Nijhof<br><div><div>t:   <a href="https://twitter.com/MarkNijhof" target="_blank">@MarkNijhof</a><br>s:  marknijhof</div></div><div><br></div></div></div>
</span></div>
<br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>