From: | Beena Emerson <memissemerson(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Support for N synchronous standby servers - take 2 |
Date: | 2015-07-03 04:53:43 |
Message-ID: | 1435899223939-5856394.post@n5.nabble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Josh Berkus wrote:
>
> Say you take this case:
>
> "2" : { "local_replica", "london_server", "nyc_server" }
>
> ... which should ensure that any data which is replicated is replicated
> to at least two places, so that even if you lose the entire local
> datacenter, you have the data on at least one remote data center.
> EXCEPT: say you lose both the local datacenter and communication with
> the london server at the same time (due to transatlantic cable issues, a
> huge DDOS, or whatever). You'd like to promote the NYC server to be the
> new master, but only if it was in sync at the time its communication
> with the original master was lost ... except that you have no way of
> knowing that.
Please consider the following:
If we have multiple replica on each DC, we can use the following:
3(local1, 1(london1, london2), 1(nyc1, nyc2))
In this case at least 1 from each DC is sync rep. When local and London
center is lost, NYC promotion can be done by comparing the LSN.
Also quorum would also ensure that even if one of the standby in a data
center goes down, another can take over, preventing data loss.
In the case 3(local1, london1, nyc1)
If nyc1, is down, the transaction would wait continuously. This can be
avoided.
-----
--
Beena Emerson
--
View this message in context: http://postgresql.nabble.com/Support-for-N-synchronous-standby-servers-take-2-tp5849384p5856394.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
From | Date | Subject | |
---|---|---|---|
Next Message | Etsuro Fujita | 2015-07-03 05:05:34 | Re: Foreign join pushdown vs EvalPlanQual |
Previous Message | Fabien COELHO | 2015-07-03 04:50:19 | Re: PATCH: remove nclients/nthreads constraint from pgbench |