On Fri, Feb 25, 2011 at 3:44 PM, Josh Berkus <josh@agliodbs.com> wrote:
>
>> Right now, as it stands, the syncrep patch will be happy as soon as
>> the data has been fsynced to either B or A-prime; I don't think we can
>> guarantee at any point that A-prime can become the leader, and feed B.
>
> Yeah, I think that's something we said months ago is going to be a 9.2
> feature, no sooner.
Ah, okay, I had missed that discussion, I also did not know it got so
specific as to address this case (are you sure?) rather than something
more general, say quorum or N-safe durability.
>> 2. The unprivileged user can disable syncrep, in any situation. This
>> flexibility is *great*, but you don't really want people to do it when
>> one is performing the switchover. Rather, in a magical world we'd hope
>> that disabling syncrep would just result in not having to
>> synchronously commit to B (but, in this case, still synchronously
>> commit to A-prime)
>>
>> In other words, to my mind, you can use syncrep as-is to provide
>> 2-safe durability xor a scheduled switchover: as soon as someone wants
>> both, I think they'll have some trouble. I do want both, though.
>
> Hmmm, I don't follow this. The user can only disable syncrep for their
> own transactions. If they don't care about the persistence of their
> transaction post-failover, why should the DBA care?
The user may have their own level of durability guarantee they want to
attain (that's why machine "B" is syncrepped in my example), but when
doing the switchover I think an override to enable a smooth handoff
(meaning: everything syncrepped) would be best. What I want to avoid
is an ack from "COMMIT" from the primary (machine "A"), and then, post
switchover, the data isn't there on machine A-Prime (or "B", provided
it was able to follow successfully at all, as in the current case it
might get ahead of A-prime in the WAL).
--
fdr
