Hi Greg and Fujii, Just a point on terminology: there's a difference in the usage of semi-synchronous between DRBD and MySQL semi-synchronous replication, which was originally developed by Google.
In the Google case semi-synchronous replication is a quorum algorithm where clients receive a commit notification only after at least one of N slaves has received the replication event. In the DRBD case semi-synchronous means that events have reached the slave but are not necessarily durable. There's no quorum. Of these two usages the Google semi-sync approach is the more interesting because it avoids the availability problems associated with fully synchronous operation but gets most of the durability benefits. Cheers, Robert On 11/12/09 9:29 PM PST, "Fujii Masao" <masao.fu...@gmail.com> wrote: > On Fri, Nov 13, 2009 at 1:49 PM, Greg Smith <g...@2ndquadrant.com> wrote: >> Right, those are the possibilities, all four of them have valid use cases in >> the field and are worth implementing. I don't like the label >> "semi-synchronous replication" myself, but it's a valuable feature to >> implement, and that is unfortunately the term other parts of the industry >> use for that approach. > > BTW, MySQL and DRBD use the term "semi-synchronous": > http://forge.mysql.com/wiki/ReplicationFeatures/SemiSyncReplication > http://www.drbd.org/users-guide/s-replication-protocols.html > > Regards, > > -- > Fujii Masao > NIPPON TELEGRAPH AND TELEPHONE CORPORATION > NTT Open Source Software Center > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
