Re: Issues with Quorum Commit

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