Synchronous replication
in [PgSql]
|
From: Fujii Masao on 2 Aug 2010 08:03 On Mon, Aug 2, 2010 at 8:32 PM, Robert Haas <robertmhaas(a)gmail.com> wrote: > 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. I'm just comparing your idea (i.e., set synchronous_standbys on each possible master) with my idea (i.e., set replication_mode on each standby). Though your idea has the advantage described in the following post, it seems to make the setup of the standbys more complicated, as I described. So I'm trying to generate better idea. http://archives.postgresql.org/pgsql-hackers/2010-08/msg00007.php 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: Fujii Masao on 2 Aug 2010 07:06 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? 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: Heikki Linnakangas on 3 Aug 2010 11:35 On 27/07/10 13:29, Fujii Masao wrote: > On Tue, Jul 27, 2010 at 7:39 PM, Yeb Havinga<yebhavinga(a)gmail.com> wrote: >> Fujii Masao wrote: >> I noted the changes in XlogSend where instead of *caughtup = true/false it >> now returns !MyWalSnd->sndrqst. That value is initialized to false in that >> procedure and it cannot be changed to true during execution of that >> procedure, or can it? > > That value is set to true in WalSndWakeup(). If WalSndWakeup() is called > after initialization of that value in XLogSend(), *caughtup is set to false. There's some race conditions with the signaling. If another process finishes XLOG flush and sends the signal when a walsender has just finished one iteration of its main loop, walsender will reset xlogsend_requested and go to sleep. It should not sleep but send the pending WAL immediately. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- 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: Heikki Linnakangas on 4 Aug 2010 09:38 On 02/08/10 11:45, Fujii Masao wrote: > 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? Then you risk running out of disk space. Similar to having an archive command that fails for some reason. That's one reason the registration should not be too automatic - there is serious repercussions if the standby just disappears. If the standby is a synchronous one, the master will stop committing or delay acknowledging commits, depending on the configuration, and the master needs to keep extra WAL around. Of course, we can still support unregistered standbys, with the current semantics. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- 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 5 Aug 2010 06:40
On Wed, Aug 4, 2010 at 12:35 AM, Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> wrote: > There's some race conditions with the signaling. If another process finishes > XLOG flush and sends the signal when a walsender has just finished one > iteration of its main loop, walsender will reset xlogsend_requested and go > to sleep. It should not sleep but send the pending WAL immediately. Yep. To avoid that race condition, xlogsend_requested should be reset to false after sleep and before calling XLogSend(). I attached the updated version of the patch. Of course, the code is also available in my git repository: git://git.postgresql.org/git/users/fujii/postgres.git branch: wakeup-walsnd Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center |