On Tue, May 25, 2010 at 10:29 AM, Josh Berkus <josh@agliodbs.com> wrote:
> I agree that #4 should be done last, but it will be needed, not in the
> least by your employer ;-) . I don't see any obvious way to make #4
> compatible with any significant query load on the slave, but in general
> I'd think that users of #4 are far more concerned with 0% data loss than
> they are with getting the slave to run read queries.
Since #2 and #3 are enough for 0% data loss, I think that such users
would be more concerned about what results are visible in the standby.
No?
> What we should do is specify it per-standby, and then have a USERSET GUC
> on the master which specifies which transactions will be synched, and
> those will be synched only on the slaves which are set up to support
> synch. That is, if you have:
>
> Master
> Slave #1: synch
> Slave #2: not synch
> Slave #3: not synch
>
> And you have:
> Session #1: synch
> Session #2: not synch
>
> Session #1 will be synched on Slave #1 before commit. Nothing will be
> synched on Slaves 2 and 3, and session #2 will not wait for synch on any
> slave.
>
> I think this model delivers the maximum HA flexibility to users while
> still making intuitive logical sense.
This makes sense.
Since it's relatively easy and simple to implement such a boolean GUC flag
rather than "per-transaction" levels (there are four valid values #1, #2,
#3 and #4), I'll do that.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center