Re: Best Practice
- From: Laimutis.Nedzinskas@xxxxxx
- To: oracle-l@xxxxxxxxxxxxx
- Date: Fri, 20 Jan 2012 14:15:17 +0200
> No?
repeat - FSF takes care of that. Primary shuts down if it can ot
communicate with BOTH observer AND primary. Why - because primary knows
that in this situation standby is(if it is still alive) already
failing-over.
Now all that works if observer is running and FSF is enabled. Just to
enable FSF the observer has to access both db's
Your solution to stop/start observer is fine but keep in mind that FSF is
only enabled after the observer can communicate with both db's: observer
must know in what state both of them are to enable FSF.
After it is enabled observer keeps communicating with both db's as well is
db's keep communicating. If primary loses connections then it shuts down.
If you start/stop the observer during/after the disaster happened then
observer will know nothing about the state of databases. Meaning FSF won't
be enabled to avoid a split brain.
Then it's up to you to risk starting standby manually both because of lost
data and because of split brain.
The genius idea about how it all works together is introducing time
dimension into the logic (I believe you can find a CS discipline which
deals exactly with such kind of problems) - you can agree that if primary
can not communicate with standby+observer then after s-seconds it shuts
down.
I'd say that this logic not only prevents a split brain but also a data
loss (i.e. desyncronization between primary and standby):
It looks like the primary won't even downgrade into Maximum
Protection mode (i.e. async) if it can not communicate with both standby
and observer. Which means that commit on primary won't happen too. Q.E.D.
brgds, Laimis N
---------------------------------------------------------------------------------
Please consider the environment before printing this e-mail
|------------>
| From: |
|------------>
>---------------------------------------------------------------------------------------------------------------------------------------------|
|mek s <sidi.bouzid.meknessy@xxxxxxxxx>
|
>---------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:. |
|------------>
>---------------------------------------------------------------------------------------------------------------------------------------------|
|Laimutis.Nedzinskas@xxxxxx
|
>---------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date: |
|------------>
>---------------------------------------------------------------------------------------------------------------------------------------------|
|2012.01.20 13:50
|
>---------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject: |
|------------>
>---------------------------------------------------------------------------------------------------------------------------------------------|
|Re: Best Practice
|
>---------------------------------------------------------------------------------------------------------------------------------------------|
Yes, the only option giving this configuration is to manually failover to
the standby , but at least we will not be in split brain situation.
But, your config has more chance to get into split brain situation ;
imagine your standby and observer can't communicate with the primary (due
to network issue) then the observer will failover to the standby. You will
get both new Primary + old Primary in open state. No?
2012/1/20 <Laimutis.Nedzinskas@xxxxxx>
>I am thinking to use another host on the standby DC, where I can run
another OBSERVER in the case of the primary is not available.
the question is who is going to execute the FSF process when it has
to be
executed.
If primary DC fails together with the observer then nobody is left to
execute the FSF.
After you come and start Observer at the standby it won;t do anything
(to
my best knowledge) because to enable FSF the observer has to
communicate
with both db's first - this is mostly about a split brain.
--
//www.freelists.org/webpage/oracle-l
Other related posts:
