Re: data guard fast start failover

From: <Laimutis.Nedzinskas_at_seb.lt>
Date: Mon, 19 Jan 2009 14:43:51 +0200
Message-ID: <OF1AD15A15.AA754364-ONC2257543.00457A71-C2257543.0045EF9D_at_seb.lt>



from Alex Gorbachev <ag_at_oracloid.com> Observer and standby couldn't distinguish network connectivity issue on primary from any primary host failure, power outage or whatever else.

Exactly! But what I did was simple: killed both observer and standby. Then primary killed itself. Which is a part of a split brain prevention. But in this case it means that one must make sure that at least one standby or observer(or a second observer) are allways alive, running and accesible to the primary.
Else one can get an unexpected shutdown of primary.

Brgds, Laimis

                                                                           
             Alex Gorbachev                                                
             <ag_at_oracloid.com>                                             
                                                                        To 
             2009.01.19 13:33          Laimutis.Nedzinskas_at_seb.lt          
                                                                        cc 
                                       ORACLE-L Freelists                  
                                       <oracle-l_at_freelists.org>            
                                                                   Subject 
                                       Re: data guard fast start failover  
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Laimutis,

As Ian explained, if your current primary looses connectivity to both Observer and standby, it *must* shutdown to avoid situation with two primary databases active and diverging. Indeed, if Observer and Standby are loosing connectivity to the primary (that is OK and operational otherwise) then Observer and standby will make decision to promote standby database to the primary role - the primary database has failed for them. Observer and standby couldn't distinguish network connectivity issue on primary from any primary host failure, power outage or whatever else.

Having data integrity above all, primary must be stopped to avoid split-brain - i.e. both databases in primary role. What you call dangerous must be relatively routine failover assuming DR is designed and implemented properly and can actually be promoted to primary safely and hold the traffic.

Cheers,
Alex

On 19/01/2009, at 6:40 PM, Laimutis.Nedzinskas_at_seb.lt wrote:

> In my case primary killed itself because it lost communication with
> BOTH
> observer and standby. Then primary thinks that since FSF is enabled
> then
> observer and/or standby would attempt to failover.
> It has a sense but it's kind of dangerous.

--
http://www.freelists.org/webpage/oracle-l
Received on Mon Jan 19 2009 - 06:43:51 CST

Original text of this message