Merge operations can occur in several different situations.
A merge operation can occur with one of the following configurations:
| merge | |
|---|---|
| primary partition | secondary partition |
| merge | |
|---|---|
| secondary partition | secondary partition |
Primary and secondary partitions are unique to cluster resource groups (CRG). For a primary-backup CRG, a primary partition is defined as the partition that contains the node identified as the primary access point. A secondary partition is defined as a partition that does not contain the node identified as the primary access point.
For peer CRG, if the recovery domain nodes are fully contained
within one partition, it will be the primary partition. If the recovery domain
nodes span a partition, there will be no primary partition. Both partitions
will be secondary partitions. 
In the case of a cluster administrative domain, if the domain
is partitioned into two or more partitions, then each partition will continue
to operate as a single group. Change to resources will continue to be synchronized
within each partition. When the partitions are merged back together, the system
will synchronize the changes from each partition. The end result is that the
monitored resources will be consistent across the domain. You cannot add or
remove MREs while the cluster administrative domain is partitioned.
| merge operation | |||
|---|---|---|---|
| primary partition | secondary partition | ||
| contains copy of CRG | does NOT contain copy of CRG | contains copy of CRG | does NOT contain copy of CRG |
| (1) | (2) | (3) | (4) |
During a primary secondary merge as shown in the diagram above, the following situations are possible:
- 1 and 3
- 1 and 4
- 2 and 3 (Cannot happen since a majority partition has the primary node active and must have a copy of the CRG.)
- 2 and 4 (Cannot happen since a majority partition has the primary node active and must have a copy of the CRG.)
Primary-secondary merge situations
A copy of the CRG object is sent to all nodes in the secondary partition. The following actions can result on the nodes in the secondary partition:
- No action since the secondary node is not in the CRG's recovery domain.
- A secondary node's copy of the CRG is updated with the data from the primary partition.
- The CRG object is deleted from a secondary node since the secondary node is no longer in the CRG's recovery domain.
- The CRG object is created on the secondary node since the object does not exist. However, the node is in the recovery domain of the CRG copy that is sent from the primary partition.
| merge operation | |||
|---|---|---|---|
| secondary partition | secondary partition | ||
| contains copy of CRG | does NOT contain copy of CRG | contains copy of CRG | does NOT contain copy of CRG |
| (1) | (2) | (3) | (4) |
During a secondary-secondary merge as shown in the diagram above, the following situations are possible:
- 1 and 3
- 1 and 4
- 2 and 3
- 2 and 4
Secondary-secondary merge situation 1
For
a primary-backup CRG, the node with the most recent change to the CRG is selected
to send a copy of the CRG object to all nodes in the other partition. If multiple
nodes are selected because they all appear to have the most recent change,
the recovery domain order is used to select the node.
When
merging two secondary partitions for peer CRG, the version of the peer CRG
with Active status will copied to other nodes in the other partition. If both
partitions have the same status for peer CRG, the partition which contains
the first node listed in the cluster resource group recovery domain will be
copied to nodes in another partition.
The
following actions can occur on the receiving partition nodes in either a primary-backup
CRG or a peer CRG:
- No action since the node is not the CRG's recovery domain.
- The CRG is created on the node since the node is in the recovery domain of the copy of the CRG object it receives.
- The CRG is deleted from the node since the node is not in the recovery domain of the copy of the CRG object it receives.
Secondary-secondary merge situations 2 and 3
A node from the partition which has a copy of the CRG object is selected to send the object data to all nodes in the other partition. The CRG object may be created on nodes in the receiving partition if the node is in the CRG's recovery domain.
Secondary-secondary merge situation 4
Internal data is exchanged to ensure consistency throughout the cluster.
A primary partition can subsequently be partitioned into a primary and secondary partition. If the primary node fails, Cluster Resource Service (CRS) detects it as a node failure. The primary partition becomes a secondary partition. The same result occurs if you ended the primary node that uses the End Cluster Node API. A secondary partition can become a primary partition if the primary node becomes active in the partition either through a rejoin or merge operation.
For a merge operation, the exit program is called on all nodes in the CRG's recovery domain regardless of which partition the node is in. The same action code as rejoin is used. No roles are changed as a result of the merge, but the membership status of the nodes in the CRG's recovery domain is changed from partition to active. Once all partitions merge together, the partition condition is cleared, and all CRG API's can be used.