On Mon, Jan 16, 2012 at 7:01 AM, Jeff Janes <jeff.janes@gmail.com> wrote:
> On Fri, Jan 13, 2012 at 10:12 AM, Kevin Grittner
> <Kevin.Grittner@wicourts.gov> wrote:
>> Jeff Janes <jeff.janes@gmail.com> wrote:\
>>
>>> I don't understand why this is controversial.
>>
>> I'm having a hard time seeing why this is considered a feature. It
>> seems to me what is being proposed is a mode with no higher
>> integrity guarantee than asynchronous replication, but latency
>> equivalent to synchronous replication.
>
> There are never 100% guarantees. You could always have two
> independent failures (the WAL disk of the master and of the slave)
> nearly simultaneously.
>
> If you look at weaker guarantees, then with asynchronous replication
> you are almost guaranteed to lose transactions on a fail-over of a
> busy server, and with the proposed option you are almost guaranteed
> not to, as long as disconnections are rare.
Yes. The proposed mode guarantees that you don't lose transactions
when single failure happens, but asynchronous replication doesn't. So
the proposed one has the benefit of reducing the risk of data loss to
a certain extent.
OTOH, when more than one failures happen, in the proposed mode, you
may lose transactions. For example, imagine the case where the standby
crashes, the standalone master runs for a while, then its database gets
corrupted. In this case, you would lose any transactions committed while
standalone master is running.
So, if you want to avoid such a data loss, you can use synchronous replication
mode. OTOH, if you can endure the data loss caused by double failure for
some reasons (e.g., using reliable hardware...) but not that caused by single
failure, and want to improve the availability (i.e., want to prevent
transactions
from being blocked after single failure happens), the proposed one is good
option to use. I believe that some people need this proposed replication mode.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
