Values for member and cluster caching facility states and alerts
States for hosts, members and cluster caching facilitiesState information is returned by many of the table functions, administrative views, and commands that you can use to query the status of the components of a Db2 pureScale environment. The possible values for the state of each component are shown in Table 1:
|Host||ACTIVE||Host is available for use. This means that the host system is running and can respond to operating system or networking commands, such as the TCP/IP ping command.|
|INACTIVE||Host is not available for use. This means that the host system is not running, not available or not responding to system commands. The reasons for being in this state can range from a power loss at the host to connection or networking issues.|
|cluster caching facility (CF)||STOPPED||CF has been manually stopped using the db2stop command as part of a normal shutdown by the administrator.|
|RESTARTING||CF is in the process of starting, either from the db2start command, or after a CF failure.|
|BECOMING_PRIMARY||Once a CF has started, it attempts to take on the role of the primary CF in the instance if no other CF already has this role.|
|PRIMARY||The CF is operating normally as the primary CF.|
|CATCHUP (n%)||When a secondary
CF is initially
started, it does not contain any information from the primary CF. During CATCHUP state,
the secondary CF
is in the process of obtaining a copy of all relevant information from the primary CF. This information
enables the secondary CF to assume the role of
primary CF if
the primary CF
fails. The CATCHUP n% value indicates how far along in the process that the secondary CF is, of copying
information from the primary CF. When this copying
process is complete, the secondary CF moves into PEER state.
The secondary CF
returns to CATCHUP state if a new database activation occurs, and returns to PEER state once the
synchronization is complete.
Note: When you view the status of the secondary CF using the command db2instance -list, it will be in CATCHUP state until a connection is made to the database. Once the first connection is made, the process of copying data from the primary CF begins.
|PEER||The secondary CF is ready to take over the responsibilities of the primary CF in the event of a primary CF failure. Duplexing continues while the secondary CF is in PEER state.|
services could not automatically restart the CF. When the CF reflects an ERROR
state, the ALERT field is always set to YES, indicating intervention and
investigation is required by the administrator. Db2 cluster
services no longer attempts to restart the CF once it is in the
ERROR state unless the alert has been cleared.
The ERROR state can also occur if a connection to a CF cannot be established to query its state. In this case, the ALERT field is not set to YES because the problem might be temporary. Rerun the db2instance -list command for a couple of iterations with some delay in between to check if the CF state changes to a healthy state, or if the ALERT field changes to YES.
|Member||STARTED||Member is started in the instance and operating normally. All databases are consistent and member is ready to accept or is already accepting connections to databases. If a member failed and started again, it is possible that the process model has started, but that crash recovery of the database is not yet complete. Use the LIST UTILITIES command with the SHOW DETAIL option from any member to monitor the recovery progress.|
|STOPPED||Member has been manually stopped using the db2stop command as part of a normal shutdown by the administrator.|
|RESTARTING||Member is in the process of starting or restarting. If the current host is the same as the home host, then a local member restart is taking place. If current host is different from the home host, then a member has failed over to the current host, and is restarting in light mode.|
|WAITING_FOR_FAILBACK||The process model for this member has successfully restarted on the current host in light mode. The member is waiting for its home host to become available, and which point, it will fail back on the home host. Use the LIST UTILITIES command with the SHOW DETAIL option from any active member to monitor recovery progress, and to see if crash recovery is complete for all databases. The member does not accept any new connections, nor does it process any transactions. Indoubt transactions might still exist.|
|ERROR||Db2 cluster services could not automatically restart the member, either on its home host or on any other host in the Db2 pureScale instance. When the member reflects an ERROR state, the ALERT field is always set to YES, indicating intervention and investigation is required from the administrator. Db2 cluster services no longer attempts to restart the member once it is in the ERROR state unless the alert has been cleared.|
Alerts for hosts, members and cluster caching facilities
In addition to returning state information, the commands that query the status of the components in a Db2 pureScale environment also return alert information. The possible values for alerts for all components is either YES or NO. Generally speaking, an alert value of NO is an indication that things are running normally. An alert value of YES indicates that there is a problem that might require manual intervention. In some cases, the alert conditions are temporary, and the alert field might clear itself, such as when a host is rebooted. In other cases, the alert field remains set. Proceed to use db2cluster -list -alert command to display the alerts in detail, attempt to resolve them first. There are some alerts that require administrators to manually reset the alert field using the db2cluster command with the -clear -alert options. If the alerts persist or if you are unable to resolve them, engage Db2 support.