Re: Standalone synchronous master
От | Florian Pflug |
---|---|
Тема | Re: Standalone synchronous master |
Дата | |
Msg-id | 0F82AD6E-7C4B-4BA6-B762-D42704A8D9C6@phlo.org обсуждение исходный текст |
Ответ на | Re: Standalone synchronous master (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: Standalone synchronous master
|
Список | pgsql-hackers |
On Jan12, 2014, at 04:18 , Josh Berkus <josh@agliodbs.com> wrote: > Thing is, when we talk about auto-degrade, we need to determine things > like "Is the replica down or is this just a network blip"? and take > action according to the user's desired configuration. This is not > something, realistically, that we can do on a single request. Whereas > it would be fairly simple for an external monitoring utility to do: > > 1. decide replica is offline for the duration (several poll attempts > have failed) > > 2. Send ALTER SYSTEM SET to the master and change/disable the > synch_replicas. > > In other words, if we're going to have auto-degrade, the most > intelligent place for it is in > RepMgr/HandyRep/OmniPITR/pgPoolII/whatever. It's also the *easiest* > place. Anything we do *inside* Postgres is going to have a really, > really hard time determining when to degrade. +1 This is also how 2PC works, btw - the database provides the building blocks, i.e. PREPARE and COMMIT, and leaves it to a transaction manager to deal with issues that require a whole-cluster perspective. best regards, Florian Pflug
В списке pgsql-hackers по дате отправления: