Re: Synchronization levels in SR

On Thu, May 27, 2010 at 3:21 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On Thu, 2010-05-27 at 11:28 +0900, Fujii Masao wrote:
>> On Wed, May 26, 2010 at 10:20 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> > On Wed, 2010-05-26 at 18:52 +0900, Fujii Masao wrote:
>> >
>> >> I guess that dropping the support of #3 doesn't reduce complexity
>> >> since the code of #3 is almost the same as that of #2. Like
>> >> walreceiver sends the ACK after receiving the WAL in #2 case, it has
>> >> only to do the same thing after the WAL flush.
>> >
>> > Hmm, well the code for #3 is similar also to the code for #4. So if you
>> > do #2, its easy to do #2, #3 and #4 together.
>>
>> No. #4 requires the way of prompt communication between walreceiver and
>> startup process, but #2 and #3 not. That is, in #4, walreceiver has to
>> wake the startup process up as soon as it has flushed WAL. OTOH, the
>> startup process has to wake walreceiver up as soon as it has replayed
>> WAL, to request it to send the ACK to the master. In #2 and #3, the
>> prompt communication from walreceiver to startup process, i.e., changing
>> the poll loop in the startup process would also be useful for the data
>> to be visible immediately on the standby. But it's not required.
>
> You need to pass WAL promptly on primary from backend to WALSender.
> Whatever mechanism you use can also be reused symmetrically on standby
> to provide #4. So not a problem.

I cannot be so optimistic since the situation differs from one process
to another.

>> > The comment is about whether having #3 makes sense from a user interface
>> > perspective. It's easy to add options, but they must have useful
>> > meaning.
>>
>> #3 would be useful for people wanting further robustness. In #2,
>> when simultaneous power failure on the master and the standby,
>> and concurrent disk crash on the master happen, transaction whose
>> "success" indicator has been returned to a client might be lost.
>> #3 can avoid such a critical situation. This is one of reasons that
>> DRBD supports "Protocol C", I think.
>
> Which few people use it, or if they do its because DRBD didn't
> originally support multiple standbys. Not worth emulating IMHO.

If so, #3 would be useful for people who don't afford to buy more
than one standby servers, too :)

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center