Replication of primary-server data to secondary servers

All secondary server types use logs to replicate primary-server replicate data. The primary server sends its entire logical log to HDR and RS secondary servers, but only the log page's position to SD secondary servers.

Index page logging can be used by all secondary servers, but is required for replication to RS secondary servers.

Databases must use transaction logging to be replicated.

Warning: If the primary server and secondary server disconnect from each other, and are allowed to independently run as standard servers or primary servers, then high-availability data replication might have to be reestablished.

Replication to HDR secondary servers

There are three synchronization modes that the primary database server can use to replicate data to an HDR secondary server:
  • Fully synchronous mode, where transactions require acknowledgement of completion on the HDR secondary server before they can complete.

    Data integrity is highest when you use fully synchronous mode, but system performance can be negatively affected if client applications use unbuffered logging and have many small transactions.

  • Asynchronous mode, where transactions do not require acknowledgement of being received or completed on the HDR secondary server before they can complete.

    System performance is best when you use asynchronous mode, but if there is a server failure, data can be lost.

  • Nearly synchronous mode, where transactions require acknowledgement of being received on the HDR secondary server before they can complete.

    Nearly synchronous mode can have better performance than fully synchronous mode and better data integrity than asynchronous mode. If used with unbuffered logging, SYNC mode, which is turned on when DRINTERVAL is set to -1, is the same as nearly synchronous mode.

The synchronization mode is controlled by the combination of DRINTERVAL configuration parameter value, HDR_TXN_SCOPE configuration parameter value, and database logging type.
The following two figures illustrate replication from a primary server to an HDR secondary server.
Figure 1: How data replicates from a primary to HDR secondary server

This figure shows that HDR buffers hold logical log buffers before the primary database server sends the buffers to the secondary database server.
Figure 2: Threads that manage data replication

The paragraph that follows this figure describes the content of the figure.

The contents of the primary server's logical-log buffer are copied to the shared-memory data-replication buffer and flushed to disk. If the primary server is using fully synchronous or nearly synchronous mode, it must receive an acknowledgement from the HDR secondary server before it can complete the logical-log flush. The primary server starts a drprsend thread to transmit the data-replication buffer across the network to the secondary server's drsecrcv thread, which then writes the data into the shared-memory reception buffer. The drsecapply thread copies the reception buffer to the recovery buffer. Both HDR and RS secondary servers use logrecvr threads to apply logical-log records their dbspaces. You can adjust the number of logrecvr threads by changing the value of the OFF_RECVRY_THREADS configuration parameter.

The drprping and drsecping threads send and receive messages to monitor the connection between two servers.

Replication to RSS secondary servers

Because checkpoints between a primary server and an RS secondary server are asynchronous, RS secondary servers require index page logging.

The following figure illustrated replication from a primary server to an RS secondary server.
Figure 3: Threads that manage data replication for RS secondary servers

The paragraph before this figure describes the content of the figure.

If the primary server can verify that it is connected to an RS secondary server, the RSS_send thread copies a page from either the disk or the logical-log buffer to the data-replication buffer. The RSS_Send thread uses a Server Multiplexer Group (SMX) connection to send the data-replication buffer to the RS secondary server's RSS_recv thread. The RSS_recv thread then writes the data into the reception buffer. The RSS_apply thread copies the reception buffer to the recovery buffer.

Unlike with HDR fully synchronous mode or nearly synchronous mode, the primary server does not require acknowledgment from the secondary server before sending the next buffer. The primary server sends up to 32 unacknowledged data-replication buffers before the RSS_send thread waits for the RSS_Recv thread to receive an acknowledgment from the RS secondary server.

Replication to SD secondary servers

SD secondary servers read logical log pages from disk and then apply the data to their memory data buffers.