HDR reproduces updates to the primary database server on the secondary database server by having the primary database server send all its logical-log records to the secondary database server as they are generated. The secondary database server receives the logical-log records generated on the primary database server and applies them to its dbspaces.
As shown in Figure 76, when the primary database server starts to flush the contents of the logical-log buffer in shared memory to the logical log on disk, the database server also copies the contents of the logical-log buffer to a data-replication buffer on the primary database server. The primary database server then sends these logical-log records to the secondary database server.
The secondary database server receives the logical-log records from the primary database server into a shared-memory reception buffer (which the database server automatically adjusts to an appropriate size for the amount of data being sent). The secondary database server then applies the logical-log records through logical recovery.
The HDR buffers are part of the virtual shared memory that the primary database server manages. The HDR buffers hold logical-log records before the primary database server sends them to the secondary database server. The HDR buffers are the same size as the logical-log buffers. Figure 76 shows this concept.
The primary database server sends the contents of the HDR buffer to the secondary database server either synchronously or asynchronously. The value of the ONCONFIG configuration parameter DRINTERVAL determines whether the database server uses synchronous or asynchronous updating. For more information on DRINTERVAL, see the chapter on configuration parameters in the IBM Informix Administrator's Reference.
If you set DRINTERVAL to -1, HDR occurs synchronously. As soon as the primary database server writes the logical-log buffer contents to the HDR buffer, it sends those records from the HDR buffer to the secondary database server. The logical-log buffer flush on the primary database server completes only after the primary database server receives acknowledgment from the secondary database server that the records were received.
With synchronous updating, no transactions committed on the primary database server are left uncommitted or partially committed on the secondary database server if a failure occurs.
If you set DRINTERVAL to any value other than -1, data replication occurs asynchronously. The primary database server flushes the logical-log buffer after it copies the logical-log buffer contents to the HDR buffer. Independent of that action, the primary database server sends the contents of the HDR buffer across the network when one of the following conditions occurs:
This method of updating might provide better performance than synchronous updating. However, as the following section explains, transactions can be lost.
With asynchronous updating, a transaction committed on the primary database server might not be replicated on the secondary database server. This situation can result if a failure occurs after the primary database server copies a commit record to the HDR buffer but before the primary database server sends that commit record to the secondary database server.
If the secondary database server is changed to a standard database server after a failure of the primary database server, it rolls back any open transactions. These transactions include any that were committed on the primary database server but for which the secondary database server did not receive a commit record. As a result, transactions are committed on the primary database server but not on the secondary database server. When you restart data replication after the failure, the database server places all the logical-log records from the lost transactions in a file (which the DRLOSTFOUND configuration parameter specifies) during logical recovery of the primary database server. Figure 77 illustrates the process.
If the lost-and-found file appears on the computer that is running the primary database server after it restarts data replication, a transaction has been lost. The database server cannot reapply the transaction records in the lost-and-found file because conflicting updates might have occurred while the secondary database server was acting as a standard database server.
To reduce the risk of a lost transaction without running data replication in synchronous mode, use unbuffered logging for all the databases. This method reduces the amount of time between the writing and transfer of the transaction records from the primary database server to the secondary database server.
Home | [ Top of Page | Previous Page | Next Page | Contents | Index ]