Re: Fully-automatic streaming replication failover when master dies? - Mailing list pgsql-general
On Sun, Jan 26, 2014 at 12:50 PM, Scott Marlowe <scott.marlowe@gmail.com> wrote:
Are you running your cluster in synchronous mode across geographically
diverse data centers? If not how long do you wait for the master to
come back before you fail over? A millisecond? A second? A minute? The
answer will likely be different for me than for you.
Questions like this and other failover criteria could be configurations. at the least simplest of clusters and failovers sceanrios could be facilitated out of box (either using PostgreSQL itself using a tool e.g. pgpool).
While ACID isn't the main or only reason for things being different,
it IS a valid reason because different people use PostgreSQL for
different things. If I'm running it as a session server, I treat it
one way, as a key-value store another, as a transactional database
handling monetary funds yet another.
If there is a failover and something is not replicated, I am gonna lose those transaction [unless I have wal and archives available from the primary node]. I would believe that same should apply to mongoDB too (instead of losing transactions you will be losing operations). I am not getting how being ACID or non-ACID changes this scenario. If the stand by was synchronous [which is what someone using it for montary funds would do], I do no lose any transaction [which is what someone using it for montary funds would need]. Still I see that an automatic failover can be performed (and scenario is more simple with sync-replication rather than it being complex).
The decision of where to failover in a multi-slave cluster can be based on xlogs replayed. To avoid split brain scenario one can always do what mongoDB does (which is again out of a very simple mathematical theory and nothing which one can attribute to it being non-ACID). Cluster always has odd nodes. lets say node1 replicates to node2 and node3 and because of n/w failure node2 and node1 and node2 can not see node3 but can see each other, so node1 will see that it can still remain master since it has majority of nodes in its visibility. it was node1 which was not visible to node2 and node3, one of them would become primary.
You're refusal to accept that
this is a complex issue with complex answers isn't helping you find
the right answer to your problem.
I am just trying to understand the complexity and see if I am overlooking anything :-)
Dmitry Koterov wrote:
PostgreSQL supports synchronous multi-master, MongoDB supports write concern, but this causes a performance penalty).
Well, if multi-master is what you were talking about all along then may be my arguments are all wrong (and I am sorry to everyone).
ACID (primarily isolation and serilization) would make a big deal here. Multi Master with Relational databases is an all together different thing. Anyways I doubt that "PostgreSQL supports synchronous multi-master"
Best Regards,
Sameer Kumar | Database Consultant
ASHNIK PTE. LTD.
101 Cecil Street, #11-11 Tong Eng Building, Singapore 069533
M : +65 8110 0350 T: +65 6438 3504 | www.ashnik.com
www.facebook.com/ashnikbiz | www.twitter.com/ashnikbiz
This email may contain confidential, privileged or copyright material and is solely for the use of the intended recipient(s).
Attachment
pgsql-general by date: