From: | MARK CALLAGHAN <mdcallag(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Sync Rep Design |
Date: | 2011-01-02 20:13:46 |
Message-ID: | AANLkTimYmhs7q=OFjy=4bgcPuDHvgKu9XJJHBw=q8anL@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Dec 30, 2010 at 9:02 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> <reads MySQL documentation>
>
> I see now that you've tried to design this feature in a way that is
> similar to MySQL's offering, which does have some value. But it
> appears to me that the documentation you've written here is
> substantially similar to the MySQL 5.5 reference documentation. That
> could get us into a world of legal trouble - that documentation is not
> even open source, let alone BSD.
>
> http://dev.mysql.com/doc/refman/5.5/en/replication-semisync.html
The docs originate from work done by my former team at Google. The
content license on this is CC 3.0 BY-SA, so I don't think that should
be a concern.
http://code.google.com/p/google-mysql-tools/wiki/SemiSyncReplication
http://code.google.com/p/google-mysql-tools/wiki/SemiSyncReplicationDesign
>From http://dev.mysql.com/doc/refman/5.5/en/replication-semisync.html)
the MySQL docs don't mention that other transactions can view the
committed data on the master between steps 1 and 2. Is that possible
in this case?
As described in the the MySQL docs, semi-sync has another benefit for
some deployments. It rate limits busy clients to prevent them from
creating replication lag between the primary and standby servers. I
also provided the text for that
(http://bugs.mysql.com/bug.php?id=57911) if you are concerned about
copying.
--
Mark Callaghan
mdcallag(at)gmail(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2011-01-02 20:27:10 | Re: Sync Rep Design |
Previous Message | Kevin Grittner | 2011-01-02 18:13:00 | Re: management of large patches |