write ahead logging in standby (streaming replication)
in [PgSql]
|
From: Tom Lane on 12 Nov 2009 09:52 Fujii Masao <masao.fujii(a)gmail.com> writes: > The problem is that fsync needs to be issued too frequently, which would > be harmless in asynchronous replication, but not in synchronous one. > A transaction would have to wait for the primary's and standby's fsync > before returning a "success" to a client. Surely that is exactly what is *required* if the user has asked for synchronous replication. regards, tom lane -- 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 12 Nov 2009 20:52 On Fri, Nov 13, 2009 at 1:49 AM, Greg Smith <greg(a)2ndquadrant.com> wrote: > This a distressingly common thing people get wrong about replication. You > can either have synchronous replication, which as you say has to be slow: > you must wait for an fsync ACK from the secondary and a return trip before > you can say something is committed on the primary. Or you can get better > performance by not waiting for all of those things, but the minute you do > that it's *not* synchronous replication anymore. You can't get > high-performance and true synchronous behavior; you have to pick one. The > best you can do if you need both is work on accelerating fsync everywhere > using the standard battery-backed write cache technique. I'm not happy that such frequent fsyncs would harm even semi-synchronous replication (i.e., you must wait for a *recv* ACK from the secondary and a return trip before you can say something is committed on the primary. This corresponds to the DRBD's protocol B) rather than synchronous one. Personally, I think that semi-synchronous replication is sufficient for HA. 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: Greg Smith on 12 Nov 2009 21:15 Fujii Masao wrote: > Personally, I think that semi-synchronous replication is sufficient for HA. > Whether or not you think it's sufficient for what you have in mind, "synchronous replication" requires a return ACK from the secondary before you say things are committed on the primary. If you don't do that, it's not true sync replication anymore; it's asynchronous replication. Plenty of people decide that a local commit combined with a promise to synchronize as soon as possible to the slave is good enough for their apps, which as you say is getting referred to as "semi-synchronous replication" nowadays. That's an awful name though, because it's not true--that's asynchronous replication, just aiming for minimal lag. It's OK to say that's what you want, but you can't say it's really a synchronous commit anymore if you do things that way. -- Greg Smith 2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support greg(a)2ndQuadrant.com www.2ndQuadrant.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 12 Nov 2009 21:20 On Fri, Nov 13, 2009 at 10:58 AM, Aidan Van Dyk <aidan(a)highrise.ca> wrote: > * Fujii Masao <masao.fujii(a)gmail.com> [091112 20:52]: > >> Personally, I think that >> semi-synchronous replication is sufficient for HA. > > Often, but that's not synchronous replication so don't call it such... Hmm, though I'm not sure about your definition of "synchronous", if the primary waits for a *redo* ACK from the standby before returning a "success" of a transaction to a client, you can call SR synchronous? This is one of TODO items of SR for v8.5. 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 12 Nov 2009 21:37 On Fri, Nov 13, 2009 at 11:15 AM, Greg Smith <greg(a)2ndquadrant.com> wrote: > Whether or not you think it's sufficient for what you have in mind, > "synchronous replication" requires a return ACK from the secondary before > you say things are committed on the primary. If you don't do that, it's not > true sync replication anymore; it's asynchronous replication. Plenty of > people decide that a local commit combined with a promise to synchronize as > soon as possible to the slave is good enough for their apps, which as you > say is getting referred to as "semi-synchronous replication" nowadays. > That's an awful name though, because it's not true--that's asynchronous > replication, just aiming for minimal lag. It's OK to say that's what you > want, but you can't say it's really a synchronous commit anymore if you do > things that way. Umm... what is your definition of "synchronous"? I'm planning to provide four synchronization modes as follows, for v8.5. Does this fit in your thought? The primary waits ... before returning "success" of a transaction; * nothing - asynchronous replication * recv ACK - semi-synchronous replication * fsync ACK - semi-synchronous replication * redo ACK - synchronous replication Or, in synchronous replication, we must wait a fsync and a redo ACK? 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
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 Prev: total execution time as reported by auto_explain Next: New VACUUM FULL |