Hi,
Quoting "Greg Smith" :
"Synchronous replication - guarantees "zero data loss" by the means
of atomic write operation, i.e. write either completes on both sides
or not at all. Write is not considered complete until
acknowledgement by both local and remote storage."
Note that a storage
Markus Wanner wrote:
You will definitely find different definitions and requirements of what
synchronous replication means there.
To quote from the Wikipedia entry on "Database Replication" that Simon
pointed to during the earlier discussion,
http://en.wikipedia.org/wiki/Database_replication
Hi,
Greg Stark wrote:
I think my definition would be that a query against the replica will
produce the same result as a query against the master -- and that that
will be the case even after a system failure. That might not
necessarily mean that the log entry is fsynced on the replica, only
that
On Fri, Nov 13, 2009 at 3:17 PM, Greg Smith wrote:
> Yeah, that's the "other parts of the industry" I was referring to. MySQL
> uses "semi-synchronous" to distinguish between its completely asynchronous
> default replication mode and one where it provides a somewhat safer
> implementation. The d
Fujii Masao wrote:
On Fri, Nov 13, 2009 at 1:49 PM, Greg Smith 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, an
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 comm
On Fri, Nov 13, 2009 at 1:49 PM, Greg Smith 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 unfortu
On Fri, Nov 13, 2009 at 11:54 AM, Greg Stark wrote:
> I think my definition would be that a query against the replica will
> produce the same result as a query against the master -- and that that
> will be the case even after a system failure. That might not
> necessarily mean that the log entry i
Fujii Masao wrote:
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
On Fri, Nov 13, 2009 at 2:37 AM, Fujii Masao wrote:
> 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
I think my definition would be that a query against the replica will
produce the same result as a
On Fri, Nov 13, 2009 at 11:15 AM, Greg Smith 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 replicati
On Fri, Nov 13, 2009 at 10:58 AM, Aidan Van Dyk wrote:
> * Fujii Masao [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
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 do
* Fujii Masao [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...
--
Aidan Van Dyk
On Fri, Nov 13, 2009 at 1:49 AM, Greg Smith 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 som
Tom Lane wrote:
Fujii Masao 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.
Fujii Masao 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
On Thu, 2009-11-12 at 21:45 +0900, Fujii Masao wrote:
> But, as I said on my first post on this thread, even such low-frequent
> fsync-WAL-before-buffer-flush might cause a response time spike on the
> primary because the walreceiver must sleep during that fsync. I think
> that leaving the WAL-log
On Thu, Nov 12, 2009 at 6:27 PM, Simon Riggs wrote:
> I agree with you, though it has taken some time to understand what you
> said and at first my reaction was to disagree. I think the responses you
> got on this are because you dived straight in with a question before
> explaining other things a
On Thu, 2009-11-12 at 17:03 +0900, Fujii Masao wrote:
> On Thu, Nov 12, 2009 at 4:32 PM, Heikki Linnakangas
> wrote:
> > Fujii Masao wrote:
> >> The problem is that fsync needs to be issued too frequently, which would
> >> be harmless in asynchronous replication, but not in synchronous one.
> >>
Hi,
On Thu, Nov 12, 2009 at 4:32 PM, Heikki Linnakangas
wrote:
> Fujii Masao wrote:
>> 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
Fujii Masao wrote:
> 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.
>
> So I'm incli
On Thu, Nov 12, 2009 at 12:03 PM, Tom Lane wrote:
> Fujii Masao writes:
>> Should the standby also have to follow the WAL rule during recovery?
>> The current patch doesn't care about the write order of the data page
>> and WAL in the standby. So, after both servers fail, restarting the
>> ex-sta
Fujii Masao writes:
> Should the standby also have to follow the WAL rule during recovery?
> The current patch doesn't care about the write order of the data page
> and WAL in the standby. So, after both servers fail, restarting the
> ex-standby by itself might corrupt the data.
Surely the receiv
Hi,
Should the standby also have to follow the WAL rule during recovery?
The current patch doesn't care about the write order of the data page
and WAL in the standby. So, after both servers fail, restarting the
ex-standby by itself might corrupt the data.
If the standby follows the WAL rule, walr
25 matches
Mail list logo