On 06.10.2010 18:02, Dimitri Fontaine wrote:
> Heikki Linnakangas<heikki.linnakangas@enterprisedb.com> writes:
>>> 1. base-backup — self explaining
>>> 2. catch-up — getting the WAL to catch up after base backup
>>> 3. wanna-sync — don't yet have all the WAL to get in sync
>>> 4. do-sync — all WALs are there, coming soon
>>> 5. ok (async | recv | fsync | reply — feedback loop engaged)
>>>
>>> So you only consider that a standby is a candidate for sync rep when
>>> it's reached the ok state, and that's when it's able to fill the
>>> feedback loop we've been talking about. Standby state != ok, no waiting
>>> no nothing, it's *not* a standby as far as the master is concerned.
>>
>> You're not going to get zero data loss that way. Can you elaborate what the
>> use case for that mode is?
>
> You can't pretend to sync with zero data loss until the standby is ready
> for it, or you need to take the site down while you add your standby.
>
> I can see some user willing to take the site down while doing the base
> backup dance then waiting for initial sync, then only accepting traffic
> and being secure against data loss, but I'd much rather that be an
> option and you could watch for your standby's state in a system view.
>
> Meanwhile, I can't understand any reason for the master to pretend it
> can safely manage any sync-rep transaction while there's no standby
> around. Either you wait for the quorum and don't have it, or you have to
> track standby states with precision and maybe actively reject writes.
I'm sorry, but I still don't understand the use case you're envisioning.
How many standbys are there? What are you trying to achieve with
synchronous replication over what asynchronous offers?
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com