Data group set examples - assure_mimix - 10.0

The following examples illustrate how data group set affects procedures for data group activity.

Data group set example - Table 1 shows a three-node cluster that is configured to replicate from two unique source journals. Two sets of data groups are required, one for each journal. Each data group set contains the necessary data groups to allow any node in the cluster to become the primary node.

Table 1 illustrates these concepts:

• Since only one node can be the primary node, data groups defined between nodes which do not include the primary node must be disabled. In this example, one data group in the set must be disabled at any given time.

• The primary node cannot be determined from just the three-part name of a data group definition. The three-part name only identifies systems, not system roles within the data group or node roles within the cluster.

  Example of a data group set.

  Cluster Nodes	Data Group Sets
  	Name  System1 System2 DG1      A      B    DG1      A      C    DG1      B      C
  	Name  System1 System2 DG2      B      A DG2      C      A DG2      C      B

Working with target-side only replication processes example - When resolving data group issues, at times it may be appropriate to start or end only the processes which run on the affected node. The key concept to remember is to consider the entire node, not just a data group.

While MIMIX commands for starting and ending data groups (STRDG and ENDDG) permit specifying only source or target processes, these commands are not node-aware; that is, they cannot ensure that the specified processes will be acted upon on all data groups on a specific node. Within a data group, the STRDG or ENDDG command can determine replication roles of each system (source or target) by evaluating the data group’s data source parameter (DTASRC) but the commands are not aware of the cluster node roles (primary, backup, or replicate). Therefore, you may need to request the STRDG or ENDDG command multiple times to achieve the expected results.

Consider a cluster which has the data group set identified in Table 1. For this example, node A is the primary node and you want to take action on replication processes on node B. Data groups DG1 B C and DG2 C B are disabled.

Table 2 illustrates that it is better to issue multiple command requests than to not have all the appropriate processes which run on a node selected. Each row shows a variation for specifying the data group definition (DGDFN) on a request scoped to only target processes PRC(*ALLTGT). When only one command is used, either row is not sufficient to ensure that all target processes on node B are ended.

The Result column illustrates the variations in results due to which system is considered source by the data group. It also illustrates that the cluster role of primary node does not necessarily correlate to the data group role of source system. At times, such as following a switch, the primary node role and data group source role are not the same system. Using two commands corresponding to the two rows in Table 2 will ensure that all of the appropriate processes are selected for action.

Data groups DG1 B C and DG2 C B are not shown in Table 2 because they are disabled and will be ignored by any STRDG or ENDDG request.

DGDFN(*ALL *ALL B) PRC(*ALLTGT)

DG1 A B action occurs on node B
DG1 A C not selected
DG2 B A not selected
DG2 C A not selected

DGDFN(*ALL B *ALL) PRC(*ALLTGT)

DG1 A B not selected
DG1 A C not selected
DG2 B A action occurs on node B
DG2 C A not selected