On Tue, Jul 27, 2010 at 12:36 PM, Joshua Tolley <eggyknap@gmail.com> wrote:
> Perhaps I'm hijacking the wrong thread for this, but I wonder if the quorum
> idea is really the best thing for us. I've been thinking about Oracle's way of
> doing things[1]. In short, there are three different modes: availability,
> performance, and protection. "Protection" appears to mean that at least one
> standby has applied the log; "availability" means at least one standby has
> received the log info (it doesn't specify whether that info has been fsynced
> or applied, but presumably does not mean "applied", since it's distinct from
> "protection" mode); "performance" means replication is asynchronous. I'm not
> sure this method is perfect, but it might be simpler than the quorum behavior
> that has been considered, and adequate for actual use cases.
In my case, I'd like to set up one synchronous standby on the near rack for
high-availability, and one asynchronous standby on the remote site for disaster
recovery. Can Oracle's way cover the case?
"availability" mode with two standbys might create a sort of similar situation.
That is, since the ACK from the near standby arrives in first, the near standby
acts synchronous and the remote one does asynchronous. But the ACK from the
remote standby can arrive in first, so it's not guaranteed that the near standby
has received the log info before transaction commit returns a "success" to the
client. In this case, we have to failover to the remote standby even if it's not
under control of a clusterware. This is a problem for me.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center