Re: Fully-automatic streaming replication failover when master dies?

On Sun, Jan 26, 2014 at 12:50 PM, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)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

[image: email patch]

This email may contain confidential, privileged or copyright material and
is solely for the use of the intended recipient(s).