RE: HDR+Connection Manager in intermittent network scenario

> On 12/03/2010 07:46 PM, Nate Woodward wrote: > > I'm trying to acheive high availability without data loss. I have an > HDR > > pair configured with a connection manager on each box for redundancy. > > Clients are pointed at an sqlhosts group with the connection managers > in > > them, and the connection managers are configured to redirect the > clients > > to the current primary server in the pair. The connection managers > are > > also configured for failover, with FOC = HDR,10, so that the > secondary > > takes over the primary's job if it fails. > > > > Now, I'm worried about this scenario: > > - primary gets disconnected from network > > - secondary is brought to primary mode > > - primary regains network connectivity > > - two primary's are on the network -- what now? > > > > I'm considering writing an ALARMPROGRAM script to bring down the > primary > > if it loses network connectivity, so that HDR can be re-established > with > > the old secondary as the new primary. Is there a better way to do > what > > I'm trying to accomplish? > > <snipped> It is mainly because of dangerous situations like this (dual primaries) that I maintain that there should be a *third* server to monitor both the primary and secondary. Besides monitoring, that third server should also be the one to execute the switchover of the primary duties to the secondary server (when the old primary becomes unresponsive), and should also be the one to re-direct the client traffic to the new primary db server. This is the very successful model that we put in place here in 2004 for a highly critical HDR pair -- obviously, this was *before* MACH 11 and Connection Manager. (for more info, see my presentation from the 2006 NA IIUG/IDUG Conference, available in the member area of iiug.org) My recommendation would be to put the Connection Manager on a small *third* server, ideally situated very close network-wise to the majority of your client connections. The redundant CM should ideally be on a fourth server, but also located close by client servers. The main point here, of course, is to *NOT* have your CM on the same server as your DBMS. HTH, Paul Mosser