Example: Merge

Within IBM® i cluster technology, a merge operation occurs in several different situations.

A merge operation can occur with one of the following configurations:

Table 1. Merge between a primary and secondary partition
merge
primary partition secondary partition
Table 2. Merge between a secondary and 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.

See Synchronization of monitored resource for information about the behavior of a cluster administrative domain during a rejoin.

Table 3. Merge between a primary and secondary partition
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. 1 and 3
  2. 1 and 4
  3. 2 and 3 (Cannot happen since a majority partition has the primary node active and must have a copy of the CRG.)
  4. 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.
Table 4. Secondary and secondary merge scenario
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. 1 and 3
  2. 1 and 4
  3. 2 and 3
  4. 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.