On Thu, Sep 30, 2010 at 3:09 PM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
>>> * Support multiple standbys with various synchronization levels.
>>
>> Not required for that case.
>
> IMHO at least we'll still need to support asynchronous standbys in the same
> mix, that's an existing feature.
My intention is to commit the core part of synchronous replication (which would
be used for every use cases) at first. Then we can implement the
feature for each
use case.
I agree that 9.1 should support asynchronous standbys in the same mix, but this
seems to be extended feature rather than very core.
>>> * What happens if a synchronous standby isn't connected at the moment?
>>> Return immediately vs. wait forever.
>>
>> The wait-forever option is not required for that case. Let's implement
>> the return-immediately at first.
>>
>> ..-
>>
>>> * async, recv, fsync and replay levels of synchronization.
>>
>> At least one of three synchronous levels should be included in the first
>> commit. I think that either recv or fsync is suitable for first try
>> because those don't require wake-up signaling from startup process to
>> walreceiver and are relatively easy to implement.
>
> What is the use case for that combination? For zero data loss, you *must*
> wait forever if a standby isn't connected. For keeping a hot standby server
> up-to-date so that you can freely query the standby instead of the master,
> you need replay level synchronization.
For high availability, and zero data loss unless the disk on one of master
and standby gets corrupted after the other goes down. It's the same use case
that cluster with shared disk covers.
I proposed to implement the "return-immediately" at first because it doesn't
require standby registration. But if many people think that the "wait-forever"
is the core rather than the "return-immediately", I'll follow them. We can
implement the "return-immediately" after that.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center