Starting a cluster caching facility

A cluster caching facility (CF) is started as part of a global db2start or an individual db2start CF command. This task focuses on starting a single cluster caching facility.

About this task

On a global db2start, the cluster manager attempts to start the primary role (also known as the PRIMARY state) on the preferred primary cluster caching facility, and the other cluster caching facility will be started in the secondary role (also known as PEER state).

If one cluster caching facility is already started and running in the PRIMARY state, the next cluster caching facility that you start (the secondary cluster caching facility) will enter a CATCHUP phase which ensures that the secondary cluster caching facility has a copy of all pertinent information from the primary cluster caching facility in its memory before it transitions into PEER state.

Note: The CATCHUP phase persists until the process of copying data from the primary CF begins, after a database activation.

Procedure

To start a specific cluster caching facility:

Issue the command:

db2start CF CF-identifier

Example

John, a DBA, has added a second cluster caching facility to a Db2® pureScale® instance as described in Adding new members or an additional CF. He queries the status of all the cluster caching facilities in the instance at this point, using

SELECT ID,  
       varchar(CURRENT_HOST,10) AS CUR_HOST,
       varchar(STATE,17) AS STATE,
       ALERT
FROM SYSIBMADM.DB2_CF

and gets the output:

ID     CUR_HOST     STATE      ALERT
------ ------------ ---------- -----
   128 so5          PRIMARY    NO
   129 so6          STOPPED    NO
   
     2 record(s) selected.

The cluster caching facility 128 is the only active cluster caching facility, so it is also in the PRIMARY state.

John issues db2start CF 129 and queries the status of the cluster caching facilities, using

SELECT ID,  
       varchar(CURRENT_HOST,10) AS CUR_HOST,
       varchar(STATE,17) AS STATE,
       ALERT
FROM SYSIBMADM.DB2_CF

and gets the output:

ID     CUR_HOST     STATE        ALERT
------ ------------ ----------   -----
   128 so5          PRIMARY      NO
   129 so6          CATCHUP(50%) NO
   
     2 record(s) selected.

The cluster caching facility 129 is now getting a copy of all pertinent information from cluster caching facility 128 so that it can take over as the primary cluster caching facility if cluster caching facility 128 fails.

He queries the status of all the cluster caching facilities, using

SELECT ID,  
       varchar(CURRENT_HOST,10) AS CUR_HOST,
       varchar(STATE,17) AS STATE,
       ALERT
FROM SYSIBMADM.DB2_CF

and gets the output:

ID     CUR_HOST     STATE      ALERT
------ ------------ ---------- -----
   128 so5          PRIMARY    NO
   129 so6          PEER       NO
   
     2 record(s) selected.

Now that cluster caching facility 129 is in PEER state, it is available to take over as the primary cluster caching facility if the current primary fails.