Storage Foundation for Oracle® RAC 7.4.1 Administrator's Guide - Linux
- Section I. SF Oracle RAC concepts and administration
- Overview of Storage Foundation for Oracle RAC
- About Storage Foundation for Oracle RAC
- Component products and processes of SF Oracle RAC
- About Virtual Business Services
- Administering SF Oracle RAC and its components
- Administering SF Oracle RAC
- Starting or stopping SF Oracle RAC on each node
- Administering VCS
- Administering I/O fencing
- About the vxfentsthdw utility
- Testing the coordinator disk group using the -c option of vxfentsthdw
- About the vxfenadm utility
- About the vxfenclearpre utility
- About the vxfenswap utility
- Administering the CP server
- Administering CFS
- Administering CVM
- Changing the CVM master manually
- Administering Flexible Storage Sharing
- Backing up and restoring disk group configuration data
- Administering SF Oracle RAC global clusters
- Administering SF Oracle RAC
- Overview of Storage Foundation for Oracle RAC
- Section II. Performance and troubleshooting
- Troubleshooting SF Oracle RAC
- About troubleshooting SF Oracle RAC
- Troubleshooting I/O fencing
- Fencing startup reports preexisting split-brain
- Troubleshooting CP server
- Troubleshooting server-based fencing on the SF Oracle RAC cluster nodes
- Issues during online migration of coordination points
- Troubleshooting Cluster Volume Manager in SF Oracle RAC clusters
- Troubleshooting CFS
- Troubleshooting interconnects
- Troubleshooting Oracle
- Troubleshooting ODM in SF Oracle RAC clusters
- Prevention and recovery strategies
- Tunable parameters
- Troubleshooting SF Oracle RAC
- Section III. Reference
Examining GAB seed membership
The number of systems that participate in the cluster is specified as an argument to the gabconfig command in /etc/gabtab. In the following example, two nodes are expected to form a cluster:
# cat /etc/gabtab
/sbin/gabconfig -c -n2
GAB waits until the specified number of nodes becomes available to automatically create the port "a" membership. Port "a" indicates GAB membership for an SF Oracle RAC cluster node. Every GAB reconfiguration, such as a node joining or leaving increments or decrements this seed membership in every cluster member node.
A sample port 'a' membership as seen in gabconfig -a is shown:
Port a gen 7e6e7e01 membership 01
In this case, 7e6e7e01 indicates the "membership generation number" and 01 corresponds to the cluster's "node map". All nodes present in the node map reflects the same membership ID as seen by the following command:
# gabconfig -a | grep "Port a"
The semi-colon is used as a placeholder for a node that has left the cluster. In the following example, node 0 has left the cluster:
# gabconfig -a | grep "Port a"
Port a gen 7e6e7e04 membership ;1
When the last node exits the port "a" membership, there are no other nodes to increment the membership ID. Thus the port "a" membership ceases to exist on any node in the cluster.
When the last and the final system is brought back up from a complete cluster cold shutdown state, the cluster will seed automatically and form port "a" membership on all systems. Systems can then be brought down and restarted in any combination so long as at least one node remains active at any given time.
The fact that all nodes share the same membership ID and node map certifies that all nodes in the node map participates in the same port "a" membership. This consistency check is used to detect "split-brain" and "pre-existing split-brain" scenarios.
Split-brain occurs when a running cluster is segregated into two or more partitions that have no knowledge of the other partitions. The pre-existing network partition is detected when the "cold" nodes (not previously participating in cluster) start and are allowed to form a membership that might not include all nodes (multiple sub-clusters), thus resulting in a potential split-brain.
Note:
I/O fencing prevents data corruption resulting from any split-brain scenarios.