Synchronous replication
in [PgSql]
|
From: Fujii Masao on 2 Aug 2010 04:45 On Sun, Aug 1, 2010 at 3:11 PM, Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> wrote: > I don't think any of this quorum stuff makes much sense without explicitly > registering standbys in the master. I'm not sure if this is a good idea. This requires users to do more manual operations than ever when setting up the replication; assign unique name (or ID) to each standby, register them in the master, specify the names in each recovery.conf (or elsewhere), and remove the registration from the master when getting rid of the standby. But this is similar to the way of MySQL replication setup, so some people (excluding me) may be familiar with it. > That would also solve the fuzziness with wal_keep_segments - if the master > knew what standbys exist, it could keep track of how far each standby has > received WAL, and keep just enough WAL for each standby to catch up. What if the registered standby stays down for a long time? Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 2 Aug 2010 06:53 On Mon, Aug 2, 2010 at 5:02 AM, Fujii Masao <masao.fujii(a)gmail.com> wrote: > On Sun, Aug 1, 2010 at 9:51 PM, Robert Haas <robertmhaas(a)gmail.com> wrote: >> Perhaps someone will claim that nobody wants to do that anyway (which >> I don't believe, BTW), but even in simpler cases it would be nicer to >> have an explicit policy rather than - in effect - inferring a policy >> from a soup of GUC settings. �For example, if you want one synchronous >> standby (A) and two asynchronous standbys (B and C). �You can say >> quorum=1 on the master and then configure vote=1 on A and vote=0 on B >> and C, but now you have to look at four machines to figure out what >> the policy is, and a change on any one of those machines can break it. >> �ISTM that if you can just write synchronous_standbys=A on the master, >> that's a whole lot more clear and less error-prone. > > Some standbys may become master later by failover. So we would > need to write something like synchronous_standbys=A on not only > current one master but also those standbys. Changing > synchronous_standbys would require change on all those servers. > Or the master should replicate even that change to the standbys? Let's not get *the manner of specifying the policy* confused with *the need to update the policy when the master changes*. It doesn't seem likely you would want the same value for synchronous_standbys on all your machines. In the most common configuration, you'd probably have: on A: synchronous_standbys=B on B: synchronous_standbys=A -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Yeb Havinga on 2 Aug 2010 08:57 Fujii Masao wrote: > On Mon, Aug 2, 2010 at 7:53 PM, Robert Haas <robertmhaas(a)gmail.com> wrote: > >> Let's not get *the manner of specifying the policy* confused with *the >> need to update the policy when the master changes*. It doesn't seem >> likely you would want the same value for synchronous_standbys on all >> your machines. In the most common configuration, you'd probably have: >> >> on A: synchronous_standbys=B >> on B: synchronous_standbys=A >> > > Oh, true. But, what if we have another synchronous standby called C? > We specify the policy as follows?: > > on A: synchronous_standbys=B,C > on B: synchronous_standbys=A,C > on C: synchronous_standbys=A,B > > We would need to change the setting on both A and B when we want to > change the name of the third standby from C to D, for example. No? > What if the master is named as well in the 'pool of servers that are in sync'? In the scenario above this pool would be A,B,C. Working with this concept has as benefit that the setting can be copied to all other servers as well, and is invariant under any number of failures or switchovers. The same could also hold for quorum expressions like A && (B || C), if A,B,C are either master or standby. I initially though that once the definitions could be the same on all servers, having them in a system catalog would be a good thing. However that'd propably hard to setup, and also in the case of failures during change of the parameters it could become very messy. regards, Yeb Havinga -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 2 Aug 2010 09:02 On Mon, Aug 2, 2010 at 8:57 AM, Yeb Havinga <yebhavinga(a)gmail.com> wrote: > Fujii Masao wrote: >> >> On Mon, Aug 2, 2010 at 7:53 PM, Robert Haas <robertmhaas(a)gmail.com> wrote: >> >>> >>> Let's not get *the manner of specifying the policy* confused with *the >>> need to update the policy when the master changes*. �It doesn't seem >>> likely you would want the same value for �synchronous_standbys on all >>> your machines. �In the most common configuration, you'd probably have: >>> >>> on A: synchronous_standbys=B >>> on B: synchronous_standbys=A >>> >> >> Oh, true. But, what if we have another synchronous standby called C? >> We specify the policy as follows?: >> >> on A: synchronous_standbys=B,C >> on B: synchronous_standbys=A,C >> on C: synchronous_standbys=A,B >> >> We would need to change the setting on both A and B when we want to >> change the name of the third standby from C to D, for example. No? >> > > What if the master is named as well in the 'pool of servers that are in > sync'? In the scenario above this pool would be A,B,C. Working with this > concept has as benefit that the setting can be copied to all other servers > as well, and is invariant under any number of failures or switchovers. The > same could also hold for quorum expressions like A && (B || C), if A,B,C are > either master or standby. > > I initially though that once the definitions could be the same on all > servers, having them in a system catalog would be a good thing. However > that'd propably hard to setup, and also in the case of failures during > change of the parameters it could become very messy. Yeah, I think this information has to be stored either in GUCs or in a flat-file somewhere. Putting it in a system catalog will cause major problems when trying to get a down system back up, I think. I suspect that for complex setups, people will need to use some kind of cluster-ware to update the settings as nodes go up and down. But I think it will still be simpler if the nodes are named. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 2 Aug 2010 07:32
On Mon, Aug 2, 2010 at 7:06 AM, Fujii Masao <masao.fujii(a)gmail.com> wrote: > On Mon, Aug 2, 2010 at 7:53 PM, Robert Haas <robertmhaas(a)gmail.com> wrote: >> Let's not get *the manner of specifying the policy* confused with *the >> need to update the policy when the master changes*. �It doesn't seem >> likely you would want the same value for �synchronous_standbys on all >> your machines. �In the most common configuration, you'd probably have: >> >> on A: synchronous_standbys=B >> on B: synchronous_standbys=A > > Oh, true. But, what if we have another synchronous standby called C? > We specify the policy as follows?: > > on A: synchronous_standbys=B,C > on B: synchronous_standbys=A,C > on C: synchronous_standbys=A,B > > We would need to change the setting on both A and B when we want to > change the name of the third standby from C to D, for example. No? Sure. If you give the standbys names, then if people change the names, they'll have to update their configuration. But I can't see that as an argument against doing it. You can remove the possibility that someone will have a hassle if they rename a server by not allowing them to give it a name in the first place, but that doesn't seem like a win from a usability perspective. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |