The SCHA_TARGET_NODES query tag for scha_resourcegroup_get returns a list of target node names to which the given resource group is currently in the process of switching over. This query returns a meaningful value while the resource group is in PENDING_OFFLINE state on its current master or in PENDING_ONLINE state on the target node of the switchover. This query is typically called from a Stop or Postnet_stop method of a resource within the switching resource group. The output argument type is scha_str_array_t**. The corresponding operation tag for the command line form of scha_resourcegroup_get is Target_nodes. See the scha_resourcegroup_get(1HA) and the scha_resourcegroup_get(3HA) man pages for more information.
Note the following points about the SCHA_TARGET_NODES query tag:
If a switchover is not in progress on the given resource group, the Target_nodes query returns an empty list.
If a switchover is in progress on a multi-mastered resource group, in which the Maximum_primaries setting is greater than 1, the list returned by the Target_node query contains all nodes in the targeted mastery of the resource group, excluding current masters. For a single-mastered resource group, the returned list contains at most one target node.
The SCHA_TARGET_NODES query returns the target nodes for failbacks, scha_control giveovers, or user-initiated resource group switch or resource group remaster commands. Resource group switches include clresourcegroup switch or clresourcegroup online commands.
The SCHA_TARGET_NODES query tag does not return the destination nodes for resource groups that are taken offline due to a node evacuation, a resource group eviction, a strong affinity, or a Start method failure. In such cases, the SCHA_TARGET_NODES query returns an empty list.
The SCHA_TARGET_NODES query is called by a stopping method of a resource to determine the target node for a live migration. Note that the return value of an empty list indicates that the resource group is going offline but it does not necessarily imply that the resource group will remain offline. For example, in the case of a start failure or node evacuation of a single-mastered resource group, the SCHA_TARGET_NODES query returns an empty list but the resource group might still fail over to another node. As a result of this limitation, a data service might not be able to perform live migration for node evacuations or for failovers due to the failure of Start methods.
If a resource group is switching nodes due to a strong affinity only, the SCHA_TARGET_NODES query returns an empty list. For example, if RG1 declares a strong positive (++ or +++) affinity for RG2 and you switch RG2 from node1 to node2, RG1 is also switched from node1 to node2. However, a SCHA_TARGET_NODES query on RG1 will return an empty list, which would prevent live migration from being applied. If RG1 and RG2 are in the same global cluster or zone cluster, the Oracle Solaris Cluster administrator can work around this issue by using the clresourcegroup switch command to switch both RG1 and RG2 together, instead of relying on the strong positive affinity. Having both resource groups as operands of the clresourcegroup switch command allows the Target_nodes query to work correctly on both of them.
Example 7-1 C Form of the SCHA_TARGET_NODES Query
#include <scha.h>...
scha_err_t err;
scha_str_array_t *node_list;
scha_resourcegroup_t handle;
int ix;
char *rgname = "example_RG";
err = scha_resourcegroup_open(rgname, &handle);
err = scha_resourcegroup_get(handle, SCHA_TARGET_NODES, &node_list);
if (err == SCHA_ERR_NOERR) {
for (ix = 0; ix < node_list->array_cnt; ix++) {
printf("Group %s target node: %s\n", rgname,
node_list->str_array[ix]);
}
}
...
Example 7-2 CLI Form of the SCHA_TARGET_NODES Query
# scha_resourcegroup_get -G mygroup -O Target_nodes node2 #