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 <pie...@hogranch.com> wrote: > On 1/22/2014 1:35 PM, Dmitry Koterov wrote: > >> >> So does something similar and more-or-less stable exist for PostgrSQL too? >> >> > you'd need to implement that yourself using a cluster management package, > and something like repmgr to handle the transitions. > > 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 >
