Synchronous replication
in [PgSql]
|
From: Fujii Masao on 27 Jul 2010 00:41 On Tue, Jul 27, 2010 at 12:36 PM, Joshua Tolley <eggyknap(a)gmail.com> wrote: > Perhaps I'm hijacking the wrong thread for this, but I wonder if the quorum > idea is really the best thing for us. I've been thinking about Oracle's way of > doing things[1]. In short, there are three different modes: availability, > performance, and protection. "Protection" appears to mean that at least one > standby has applied the log; "availability" means at least one standby has > received the log info (it doesn't specify whether that info has been fsynced > or applied, but presumably does not mean "applied", since it's distinct from > "protection" mode); "performance" means replication is asynchronous. I'm not > sure this method is perfect, but it might be simpler than the quorum behavior > that has been considered, and adequate for actual use cases. In my case, I'd like to set up one synchronous standby on the near rack for high-availability, and one asynchronous standby on the remote site for disaster recovery. Can Oracle's way cover the case? "availability" mode with two standbys might create a sort of similar situation. That is, since the ACK from the near standby arrives in first, the near standby acts synchronous and the remote one does asynchronous. But the ACK from the remote standby can arrive in first, so it's not guaranteed that the near standby has received the log info before transaction commit returns a "success" to the client. In this case, we have to failover to the remote standby even if it's not under control of a clusterware. This is a problem for me. 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 27 Jul 2010 00:43 On Mon, Jul 26, 2010 at 8:25 PM, Robert Haas <robertmhaas(a)gmail.com> wrote: > On Mon, Jul 26, 2010 at 6:48 AM, Marko Tiikkaja > <marko.tiikkaja(a)cs.helsinki.fi> wrote: >> On 7/26/10 1:44 PM +0300, Fujii Masao wrote: >>> >>> On Mon, Jul 26, 2010 at 6:36 PM, Yeb Havinga<yebhavinga(a)gmail.com> �wrote: >>>> >>>> I wasn't entirely clear. My suggestion was to have only >>>> >>>> � acknowledge_commit = {no|recv|fsync|replay} >>>> >>>> instead of >>>> >>>> � replication_mode = {async|recv|fsync|replay} >>> >>> Okay, I'll change the patch accordingly. >> >> For what it's worth, I think replication_mode is a lot clearer. >> Acknowledge_commit sounds like it would do something similar to >> asynchronous_commit. > > I agree. As the result of the vote, I'll leave the parameter "replication_mode" as it is. 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 27 Jul 2010 01:28 On Wed, Jul 21, 2010 at 4:36 PM, Fujii Masao <masao.fujii(a)gmail.com> wrote: >> I was actually hoping to see a patch for these things first, before any of >> the synchronous replication stuff. Eliminating the polling loops is >> important, latency will be laughable otherwise, and it will help the >> synchronous case too. > > At first, note that the poll loop in the backend and walreceiver doesn't > exist without synchronous replication stuff. > > Yeah, I'll start with the change of the poll loop in the walsender. I'm > thinking that we should make the backend signal the walsender to send the > outstanding WAL immediately as the previous synchronous replication patch > I submitted in the past year did. I use the signal here because walsender > needs to wait for the request from the backend and the ack message from > the standby *concurrently* in synchronous replication. If we use the > semaphore instead of the signal, the walsender would not be able to > respond the ack immediately, which also degrades the performance. > > The problem of this idea is that signal can be sent per transaction commit. > I'm not sure if this frequent signaling really harms the performance of > replication. BTW, when I benchmarked the previous synchronous replication > patch based on the idea, AFAIR the result showed no impact of the > signaling. But... Thought? Do you have another better idea? The attached patch changes the backend so that it signals walsender to wake up from the sleep and send WAL immediately. It doesn't include any other synchronous replication stuff. The signal is sent right after a COMMIT, PREPARE TRANSACTION, COMMIT PREPARED or ABORT PREPARED record has been fsync'd. To suppress redundant signaling, I added the flag which indicates whether walsender is ready for sending WAL up to the currently-fsync'd location. Only when the flag is false, the backend sets it to true and sends the signal to walsender. When the flag is true, the signal doesn't need to be sent. The flag is set to false right before walsender sends WAL. 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
From: Yeb Havinga on 27 Jul 2010 04:42 Fujii Masao wrote: > On Mon, Jul 26, 2010 at 8:25 PM, Robert Haas <robertmhaas(a)gmail.com> wrote: > >> On Mon, Jul 26, 2010 at 6:48 AM, Marko Tiikkaja >> <marko.tiikkaja(a)cs.helsinki.fi> wrote: >> >>> On 7/26/10 1:44 PM +0300, Fujii Masao wrote: >>> >>>> On Mon, Jul 26, 2010 at 6:36 PM, Yeb Havinga<yebhavinga(a)gmail.com> wrote: >>>> >>>>> I wasn't entirely clear. My suggestion was to have only >>>>> >>>>> acknowledge_commit = {no|recv|fsync|replay} >>>>> >>>>> instead of >>>>> >>>>> replication_mode = {async|recv|fsync|replay} >>>>> >>>> Okay, I'll change the patch accordingly. >>>> >>> For what it's worth, I think replication_mode is a lot clearer. >>> Acknowledge_commit sounds like it would do something similar to >>> asynchronous_commit. >>> >> I agree. >> > > As the result of the vote, I'll leave the parameter "replication_mode" > as it is. > I'd like to bring forward another suggestion (please tell me when it is becoming spam). My feeling about replication_mode as is, is that is says in the same parameter something about async or sync, as well as, if sync, which method of feedback to the master. OTOH having two parameters would need documentation that the feedback method may only be set if the replication_mode was sync, as well as checks. So it is actually good to have it all in one parameter But somehow the shoe pinches, because async feels different from the other three parameters. There is a way to move async out of the enumeration: synchronous_replication_mode = off | recv | fsync | replay This also looks a bit like the "synchronous_replication = N # similar in name to synchronous_commit" Simon Riggs proposed in http://archives.postgresql.org/pgsql-hackers/2010-05/msg01418.php regards, Yeb Havinga PS: Please bear with me, I thought a bit about a way to make clear what deduction users must make when figuring out if the replication mode is synchronous. That question might be important when counting 'which servers are the synchronous standbys' to debug quorum settings. replication_mode from the assumption !async -> sync and !async -> recv|fsync|replay to infer recv|fsync|replay -> synchronous_replication. synchronous_replication_mode from the assumption !off -> on and !off -> recv|fsync|replay to infer recv|fsync|replay -> synchronous_replication. I think the last one is easier made by humans, since everybody will make the !off-> on assumption, but not the !async -> sync without having that verified in the documentation. -- 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 27 Jul 2010 05:11
Joshua Tolley wrote: > Perhaps I'm hijacking the wrong thread for this, but I wonder if the quorum > idea is really the best thing for us. For reference: it appeared in a long thread a while ago http://archives.postgresql.org/pgsql-hackers/2010-05/msg01226.php. > In short, there are three different modes: availability, > performance, and protection. "Protection" appears to mean that at least one > standby has applied the log; "availability" means at least one standby has > received the log info > Maybe we could do both, by describing use cases along the availability, performance and protection setups in the documentation and how they would be reflected with the standby related parameters. 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 |