Member WAITING_FOR_FAILBACK, alert, corresponding host is in ACTIVE state without alert
The output of the db2instance -list command shows that at least one member is in the WAITING_FOR_FAILBACK state with an alert and that one or more corresponding hosts are in the ACTIVE state without alerts.
This is a sample output from the db2instance
-list command where there are three members and
two cluster caching facilities:
ID TYPE STATE HOME_HOST CURRENT_HOST ALERT PARTITION_NUMBER LOGICAL_PORT NETNAME
-- ---- ----- --------- ------------ ----- ---------------- ------------ -------
0 MEMBER STOPPED hostA hostA NO 0 0 -
1 MEMBER WAITING_FOR_FAILBACK hostB hostC YES 0 1 -
2 MEMBER STARTED hostC hostC NO 0 0 -
128 CF CATCHUP hostB hostB NO - 0 -
129 CF PRIMARY hostC hostC NO - 0 -
HOSTNAME STATE INSTANCE_STOPPED ALERT
-------- ----- ---------------- -----
hostC ACTIVE NO NO
hostB ACTIVE NO NO
hostA ACTIVE NO NOMember 1
shows that an ALERT has occurred. Running db2cluster -cm -list -alert provides
information about the alert, as the following output example shows:
1.
Alert: Db2 member '1' is currently awaiting failback to its home host 'coral18'.
The cluster manager has restarted the Db2 member in restart light mode on another
host. The home host for the member is available however automatic failback to home
has been disabled.
Action: In order to move the member back its home host, the alert must be manually
cleared with the command: 'db2cluster -cm -clear -alert' (AIX) or 'db2cm -clear -alert' (Linux).
Impact: Db2 member '1' will not be able to service requests until this alert has
been cleared and the Db2 member returns to its home host.When hostB is available, the state for the host is set to ACTIVE. At this point, the default behavior with the best practice configuration of autofailback is for the restart light member to failback to its home host automatically without any user intervention. However, based on the previous output, the failback did not occur due to the disablement of the autofailback feature. To manually force the failback of the restart light member back to its home host, simply clear the alert on the host.
To restore the best practice configuration with autofailback enabled, issue
the following command on AIX:
db2cluster -cm -set -option autofailback -value on db2cm -set -option autofailback -value on The instance must be restarted for the setting of the previous command to become effective. To
verify this, run the following command on
AIX:
db2cluster -cm -list autofailbackdb2cm -list autofailback