On Fri, Nov 13, 2009 at 11:15 AM, Greg Smith <greg@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