Checking Database Replication Status

This section describes how to check the replication status for a primary cluster:

• Checking the State of the Replica Forests
• Checking the Journal Frames Received from the Primary
• Checking the Update Lag on the Primary

Checking the State of the Replica Forests

Follow these steps to check the state of each replica forest on the replica cluster:

1. Access the Admin Interface on the bootstrap host in the replica cluster. Navigate to the replica database in the left menu tree:

   

2. Select the Status tab:

   

3. The current state of each replica forest appears near the top of the page:

   

These are the possible states related to database replication:

Checking the Journal Frames Received from the Primary

Follow these steps to check the current journal frames received by each replica forest from the primary:

1. On the bootstrap host in the replica cluster, navigate to the replica database in the left menu tree, and select Database Replication:

   

2. Select the Summary tab, and check these table columns:

   

   Column	Description
   Foreign Precise Time	The point in time that the foreign primary forest asserted itself as a primary. If local-disk failover is not configured on the primary, then this is the time that the forest was created, last cleared, last rolled back, or some other relevant time. For example, if the foreign primary has local-disk failover configured, then, in addition to the previously mentioned events, this time could be the time of the last failover.
   Foreign FSN (Frame Sequence Number)	The ID of the last journal frame received from the foreign primary. This ID is simply the current count of journal frames.

Checking the Update Lag on the Primary

As described in Replication Lag, the replica cluster sends an acknowledgement to the primary cluster whenever a replicated journal frame has been received and stored. The Lag Limit that you set in your primary cluster configuration specifies that transactions on the primary will be stalled if the primary does not receive an acknowledgement from the replica within the number of seconds specified by the Lag Limit. If the Pending Lag value exceeds the Lag Limit, then new transactions that access the primary database are stalled.

If the XDQP timeout value set for the replica cluster is exceeded, then the replica cluster is assumed to have failed. In this event, the primary cluster detaches from the replica, and transactions continue normally on the primary. When the replica cluster becomes available again, then database replication resumes, and the replica database resynchronizes with the primary database.

You can check for lagging updates at the bottom of the database status page. For example, to check the database replication status of the Documents database, follow these steps:

1. On the bootstrap host in the primary cluster, navigate to the primary database in the left menu tree, and select Database Replication:

   

2. Select the Summary tab, and compare the Pending Lag to the Lag Limit in the last two columns of the Foreign Replicas forest table. The following table describes these columns:

   

   Column	Description
   Master Forest (Primary)	The name of the primary forest.
   Replica Forest	The name of the replica forest.
   Pending Frames	The number of unreplicated journal frames.
   Pending Bytes	The number of unreplicated bytes.
   Pending Lag	The number of seconds since the last journal frame was replicated.
   Lag Limit	The current lag limit in seconds set for this database. For details on the lag limit, see Replication Lag.