MarkLogic 9 Product Documentation
Database Replication Guide — Chapter 4

Checking Database Replication Status

This chapter describes how to check replication status for a Master cluster. This chapter includes the following sections:

This chapter includes the following sections:

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

Checking the State of the Replica Forests

This section describes how to check the state of each Replica forest on the Replica cluster.

Access the Admin Interface on the bootstrap host in the Replica cluster. Navigate to the Replica database in the left-hand menu:
Select the Status tab:
The current state of each Replica forest appears near the top of the page.

The possible states related to Database Replication are listed in the table below.

State	Description
Open Replica	The Replica forest is currently receiving replicated data in the form of journal frames from the Master forest. This is the normal state for Database Replication.
Syncing Replica	The Replica forest is bulk synchronizing with the Master forest. This occurs when a Master database containing documents is initially configured for Database Replication, after the Master and Replica have been detached for a sufficiently long period of time that journal replay is no longer possible, or following a local-disk failover. Once the Master and Replica databases are synchronized, the state is reset to Open Replica. While in this state, the status page will report that the database forests are in an error state. There is nothing wrong with the forests and they will appear as normal when the database returns to the Open Replica state.

State

Description

Open Replica

The Replica forest is currently receiving replicated data in the form of journal frames from the Master forest. This is the normal state for Database Replication.

Syncing Replica

The Replica forest is bulk synchronizing with the Master forest. This occurs when a Master database containing documents is initially configured for Database Replication, after the Master and Replica have been detached for a sufficiently long period of time that journal replay is no longer possible, or following a local-disk failover. Once the Master and Replica databases are synchronized, the state is reset to Open Replica.

While in this state, the status page will report that the database forests are in an error state. There is nothing wrong with the forests and they will appear as normal when the database returns to the Open Replica state.

Checking the Journal Frames Received from the Master

This section describes how to check the current journal frames received by each Replica forest from the Master.

On the bootstrap host in the Replica cluster, navigate to the Replica database in the left-hand menu and select Database Replication:

Select the Summary tab:

Field	Description
Foreign Precise Time	The point in time the foreign Master forest asserted itself as a Master. If local-disk failover isn't configured on the Master, this is the time the forest was created, last cleared, last rolled back, and so on. If the foreign Master has local-disk failover configured, in addition to the previously mentioned events, this could be the time of the last failover.
Foreign FSN	The ID of the last journal frame received from the foreign Master. The ID is simply the current count of journal frames.

Checking the Update Lag on the Master

As described in Replication Lag, the Replica cluster sends an acknowledgement to the Master cluster when a replicated journal frame has been received and stored. The Lag Limit you set in your Master cluster configuration specifies that transactions on the Master will be stalled if the Master 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, new transactions that access the Master database are stalled.

If the XDQP timeout value set for the Replica cluster is exceeded, the Replica cluster is assumed to have failed. In this event, the Master cluster will detach from the Replica and transactions will continue normally on the Master. When the Replica cluster is available again, Database Replication will resume and the Replica database will resynchronize with the Master 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 do the following:

On the bootstrap host in the Master cluster, navigate to the Master database in the left-hand menu and select Database Replication: