Re: Fully-automatic streaming replication failover when master dies?
| От | Dmitry Koterov |
|---|---|
| Тема | Re: Fully-automatic streaming replication failover when master dies? |
| Дата | |
| Msg-id | CA+CZih4-nZHesC9UtzPsVvUFyTHRE7L110Xi_DqnXVCT7=7iGQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Fully-automatic streaming replication failover when master dies? (John R Pierce <pierce@hogranch.com>) |
| Ответы |
Re: Fully-automatic streaming replication failover when
master dies?
|
| Список | pgsql-general |
It's even more tricky if it's not well-covered by automated tests, I suppose. :-) There could be a number of methods to forbid the master to rise up from the grave, e.g. voting quorum (or the simplest, but less elegant, solution - a centralized "witness" daemon who does all the work for all the machines). At least MongoDB does the work well, and with almost zero configuration.
My question was about a ready and well-tested solutions, do they exist.
On Thu, Jan 23, 2014 at 1:54 AM, John R Pierce <pierce@hogranch.com> wrote:
On 1/22/2014 1:35 PM, Dmitry Koterov wrote:you'd need to implement that yourself using a cluster management package, and something like repmgr to handle the transitions.
So does something similar and more-or-less stable exist for PostgrSQL too?
database failover is extremely tricky stuff. you have to make very very sure you don't get into a stoned cluster where both nodes THINK they are master. most well implemented failover clusters make use of hardware 'fencing' to block the presumed-dead former master from coming back online without manual intervention.
--
john r pierce 37N 122W
somewhere on the middle of the left coast
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
В списке pgsql-general по дате отправления: