Re: Standalone synchronous master
От | Josh Berkus |
---|---|
Тема | Re: Standalone synchronous master |
Дата | |
Msg-id | 52D2096A.2090001@agliodbs.com обсуждение исходный текст |
Ответ на | Re: Standalone synchronous master (Hannu Krosing <hannu@2ndQuadrant.com>) |
Ответы |
Re: Standalone synchronous master
Re: Standalone synchronous master Re: Standalone synchronous master |
Список | pgsql-hackers |
On 01/10/2014 06:27 PM, Bruce Momjian wrote: > How would that work? Would it be a tool in contrib? There already is a > timeout, so if a tool checked more frequently than the timeout, it > should work. The durable notification of the admin would happen in the > tool, right? Well, you know what tool *I'm* planning to use. 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. Such a tool would *also* be capable of detecting when the synchronous replica was back up and operating, and switch back to sync mode, something we simply can't do inside Postgres. And it would be a lot easier to configure an external tool with monitoring system integration so that it can alert the DBA to degradation in a way which the DBA was liable to actually see (which is NOT the Postgres log). 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. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
В списке pgsql-hackers по дате отправления: