On Wed, Sep 1, 2010 at 2:33 PM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> Once we're done with that, all the big questions are still left.
Yeah, let's discuss about those topics :)
> How to configure it?
Before discussing about that, we should determine whether registering
standbys in master is really required. It affects configuration a lot.
Heikki thinks that it's required, but I'm still unclear about why and
how.
Why do standbys need to be registered in master? What information
should be registered?
> What does synchronous replication mean, when is a transaction
> acknowledged as committed?
I proposed four synchronization levels:
1. async doesn't make transaction commit wait for replication, i.e., asynchronous replication. This mode has been
alreadysupported in 9.0.
2. recv makes transaction commit wait until the standby has received WAL records.
3. fsync makes transaction commit wait until the standby has received and flushed WAL records to disk
4. replay makes transaction commit wait until the standby has replayed WAL records after receiving and flushing them to
disk
OTOH, Simon proposed the quorum commit feature. I think that both
is required for various our use cases. Thought?
> What to do if a standby server dies and never
> acknowledges a commit?
The master's reaction to that situation should be configurable. So
I'd propose new configuration parameter specifying the reaction.
Valid values are:
- standalone When the master has waited for the ACK much longer than the timeout (or detected the failure of the
standby),it closes the connection to the standby and restarts transactions.
- down When that situation occurs, the master shuts down immediately. Though this is unsafe for the system requiring
highavailability, as far as I recall, some people wanted this mode in the previous discussion.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center