Values for member and cluster caching facility states and alerts
Many of the table functions, administrative
views, and commands that you can use to query the status of components
in a DB2® pureScale® environment
return state and alert information.
The state of a host, member or cluster caching facility (also
known as a CF)
reflects its operational status. An alert for
a host, member or CF is
an indication that a problem exists that might require investigation
or intervention.
States for hosts, members and cluster caching facilities
State 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:Component | Possible states | Description |
---|---|---|
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 backup CF is
initially started, it does not contain any information from the primary CF.
During CATCHUP state, the backup CF is
in the process of obtaining a copy of all relevant information from
the primary CF.
This information that enables it to assume the role of primary CF if
the primary CF fails.
n% indicates how far along the backup CF is
in the process of copying information from the primary CF.
When this copying process is complete, the backup CF moves
into PEER state. Note: When you view the status of the non-primary 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 backup CF is ready to take over the responsibilities of the primary CF in the event of a primary CF failure. Duplexing continues while the backup CF is in PEER state. | |
ERROR | DB2 cluster
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. |
|
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. |