|
Event
|
Node A: What Happens?
|
Node B: What Happens?
|
Action
|
|---|
All private networks fail.
|
Node A races for majority of coordinator disks.
If Node A wins race for coordinator disks, Node A ejects Node B from the shared disks and continues.
|
Node B races for majority of coordinator disks.
If Node B loses the race for the coordinator disks, Node B removes itself from the cluster.
|
When Node B is ejected from cluster, repair the private networks before attempting to bring Node B back.
|
All
private networks function again after event above.
|
Node A continues to work.
|
Node B has crashed. It cannot start the database since it is unable to write to the data disks.
|
Reboot Node B after private networks are restored.
|
One private network fails.
|
Node A prints message about an IOFENCE on the console but continues.
|
Node B prints message on the console about jeopardy and continues.
|
Repair private network. After network is repaired, both nodes automatically use it.
|
Node A hangs.
|
Node A is extremely busy for some reason or is in the kernel debugger.
When Node A is no longer hung or in the kernel debugger, any queued writes to the data disks fail because Node A is ejected. When Node A receives message from GAB about being ejected, it removes itself from the cluster.
|
Node B loses heartbeats with Node A, and races for a majority of coordinator disks.
Node B wins race for coordinator disks and ejects Node A from shared data disks.
|
Verify private networks function and reboot Node A.
|
Nodes A and B and private networks lose power. Coordinator and data disks retain power.
Power returns to nodes and they reboot, but private networks still have no power.
|
Node A reboots and I/O fencing driver (vxfen) detects Node B is registered with coordinator disks. The driver does not see Node B listed as member of cluster because private networks are down. This causes the I/O fencing device driver to prevent Node A from joining the cluster. Node A console displays:
Potentially a preexisting split brain. Dropping out of the cluster. Refer to the user documentation for steps required to clear preexisting split brain.
|
Node B reboots and I/O fencing driver (vxfen) detects Node A is registered with coordinator disks. The driver does not see Node A listed as member of cluster because private networks are down. This causes the I/O fencing device driver to prevent Node B from joining the cluster. Node B console displays:
Potentially a preexisting split brain. Dropping out of the cluster. Refer to the user documentation for steps required to clear preexisting split brain.
|
Refer to section in Troubleshooting chapter for instructions on resolving preexisting split brain condition.
|
Node A crashes while Node B is down. Node B comes up and Node A is still down.
|
Node A is crashed.
|
Node B reboots and detects Node A is registered with the coordinator disks. The driver does not see Node A listed as member of the cluster. The I/O fencing device driver prints message on console:
Potentially a preexisting split brain. Dropping out of the cluster. Refer to the user documentation for steps required to clear preexisting split brain.
|
Refer to section in Troubleshooting chapter for instructions on resolving preexisting split brain condition.
|
The disk array containing two of the three coordinator disks is powered off.
Node B leaves the cluster and the disk array is still powered off.
|
Node A continues to operate as long as no nodes leave the cluster.
Node A races for a majority of coordinator disks. Node A fails because only one of three coordinator disks is available. Node A removes itself from the cluster.
|
Node B continues to operate as long as no nodes leave the cluster.
Node B leaves the cluster.
|
Power on failed disk array and restart I/O fencing driver to enable Node A to register with all coordinator disks.
|
