Filter
Top Products
192 Creating and administering disk groups
Handling conflicting configuration copies
for the disks in their copies of the configuration database, and also in each disk’s
private region, are updated separately on that host. When the disks are
subsequently re-imported into the original shared disk group, the actual serial
IDs on the disks do not agree with the expected values from the configuration
copies on other disks in the disk group.
Depending on what happened to the different portions of the split disk group,
there are two possibilities for resolving inconsistencies between the
configuration databases:
■ If the other disks in the disk group were not imported on another host,
VxVM resolves the conflicting values of the serial IDs by using the version
of the configuration database from the disk with the greatest value for the
updated ID (shown as the value of
update_tid in the output from the
vxprint -m diskgroup | grep update_tid command). This case is
illustrated below.
Figure 4-2 Example of a serial split brain condition that can be resolved
automatically
Disk A
Actual A = 1
Expected A = 1
Expected B = 0
Configuration
database
Disk B
Actual B = 0
Expected A = 0
Expected B = 0
Configuration
database
Imported shared disk group
Disk A
Actual A = 1
Expected A = 1
Expected B = 0
Configuration
database
Disk B
Actual B = 0
Expected A = 1
Expected B = 0
Configuration
database
Partial disk group
imported on host X
Disk B not imported
1.Disk A is imported on a separate
host. Disk B is not imported. The
actual and expected serial IDs are
updated only on disk A.
2.The disk group is re- imported on
the cluster. The configuration copy
on disk A is used to correct the
configuration copy on disk B as the
actual value of the updated ID on
disk A is greatest.