From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Hannu Krosing <hannu(at)2ndquadrant(dot)com>, MauMau <maumau307(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kevin Grittner <kgrittn(at)ymail(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Rajeev rastogi <rajeev(dot)rastogi(at)huawei(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Standalone synchronous master |
Date: | 2014-01-12 03:18:02 |
Message-ID: | 52D2096A.2090001@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2014-01-12 03:20:07 | Re: units in postgresql.conf comments |
Previous Message | Peter Geoghegan | 2014-01-11 23:45:43 | Re: Race condition in b-tree page deletion |