Synchronous replication
in [PgSql]
|
From: Greg Stark on 1 Aug 2010 08:30 On Sun, Aug 1, 2010 at 7:11 AM, Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> wrote: > In fact, it's possible for one standby to sync up to X, then disconnect and > reconnect, and have the master count it second time in the quorum. > Especially if the master doesn't notice that the standby disconnected, e.g a > network problem. > > I don't think any of this quorum stuff makes much sense without explicitly > registering standbys in the master. This doesn't have to be done manually. The streaming protocol could include the standby sending its system id to the master. The master could just keep a list of system ids with the last record they've been sent and the last they've confirmed receipt, fsync, application, whatever the protocol covers. If the same system reconnects it just overwrites the existing data for that system id. -- greg -- 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 1 Aug 2010 08:51 On Sun, Aug 1, 2010 at 8:30 AM, Greg Stark <gsstark(a)mit.edu> wrote: > On Sun, Aug 1, 2010 at 7:11 AM, Heikki Linnakangas > <heikki.linnakangas(a)enterprisedb.com> wrote: >> In fact, it's possible for one standby to sync up to X, then disconnect and >> reconnect, and have the master count it second time in the quorum. >> Especially if the master doesn't notice that the standby disconnected, e.g a >> network problem. >> >> I don't think any of this quorum stuff makes much sense without explicitly >> registering standbys in the master. > > This doesn't have to be done manually. The streaming protocol could > include the standby sending its system id to the master. The master > could just keep a list of system ids with the last record they've been > sent and the last they've confirmed receipt, fsync, application, > whatever the protocol covers. If the same system reconnects it just > overwrites the existing data for that system id. That seems entirely too clever. Where are you going to store this data? What if you want to clean out the list? I've felt from the beginning that the idea of doing synchronous replication without having an explicit notion of what standbys are out there was not on very sound footing, and I think the difficulties of making quorum commit work properly are only further evidence of that. Much has been made of the notion of "wait for N votes, but allow standbys to explicitly give up their vote", but that's still not fully general - for example, you can't implement A && (B || C). 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. -- 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: Fujii Masao on 1 Aug 2010 22:08 On Sun, Aug 1, 2010 at 9:30 PM, Greg Stark <gsstark(a)mit.edu> wrote: > This doesn't have to be done manually. Agreed, if we register standbys in the master. > The streaming protocol could > include the standby sending its system id to the master. The master > could just keep a list of system ids with the last record they've been > sent and the last they've confirmed receipt, fsync, application, > whatever the protocol covers. If the same system reconnects it just > overwrites the existing data for that system id. Since every standby has the same system id, we cannot distinguish them by that id. ISTM that the master should assign the unique id for each standby, and they should save it in pg_control. 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 1 Aug 2010 22:26 On Sun, Aug 1, 2010 at 10:08 PM, Fujii Masao <masao.fujii(a)gmail.com> wrote: > On Sun, Aug 1, 2010 at 9:30 PM, Greg Stark <gsstark(a)mit.edu> wrote: >> This doesn't have to be done manually. > > Agreed, if we register standbys in the master. > >> The streaming protocol could >> include the standby sending its system id to the master. The master >> could just keep a list of system ids with the last record they've been >> sent and the last they've confirmed receipt, fsync, application, >> whatever the protocol covers. If the same system reconnects it just >> overwrites the existing data for that system id. > > Since every standby has the same system id, we cannot distinguish > them by that id. ISTM that the master should assign the unique id > for each standby, and they should save it in pg_control. Another option might be to let the user name them. standby_name='near' standby_name='far1' standby_name='far2' ....or whatever. -- 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: Fujii Masao on 2 Aug 2010 05:02
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? 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 |