Re: Configuring synchronous replication

On 24/09/10 01:11, Simon Riggs wrote:
> On Thu, 2010-09-23 at 20:42 +0300, Heikki Linnakangas wrote:
>> If you want the behavior where the master doesn't acknowledge a
>> commit
>> to the client until the standby (or all standbys, or one of them
>> etc.)
>> acknowledges it, even if the standby is not currently connected, the
>> master needs to know what standby servers exist. *That's* why
>> synchronous replication needs a list of standby servers in the master.
>>
>> If you're willing to downgrade to a mode where commit waits for
>> acknowledgment only from servers that are currently connected, then
>> you don't need any new configuration files.
>
> As I keep pointing out, waiting for an acknowledgement from something
> that isn't there might just take a while. The only guarantee that
> provides is that you will wait a long time. Is my data more safe? No.

It provides zero data loss, at the expense of availability. That's what
synchronous replication is all about.

> To get zero data loss *and* continuous availability, you need two
> standbys offering sync rep and reply-to-first behaviour.

Yes, that is a good point.

I'm starting to understand what your proposal was all about. It makes
sense when you think of a three node system configured for high
availability with zero data loss like that.

The use case of keeping hot standby servers up todate in a cluster where
read-only queries are distributed across all nodes seems equally
important though. What's the simplest method of configuration that
supports both use cases?

> You don't need standby registration to achieve that.

Not necessarily I guess, but it creeps me out that a standby can just
connect to the master and act as a synchronous slave, and there is no
controls in the master on what standby servers there are.

More complicated scenarios with quorums and different number of votes
get increasingly complicated if there is no central place to configure
it. But maybe we can ignore the more complicated setups for now.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com