Delayed application of log records
To aid in disaster recovery scenarios, you can configure RS secondary servers to wait for a specified period of time before applying logs received from the primary server.
By delaying the application of log files you can recover quickly from erroneous database modifications by restoring the database from the RS secondary server. You can also stop the application of logs on an RS secondary server at a specified time.
For example, suppose a database administrator wants to delete certain rows from a table based on the age of the row. Each row in the table contains a timestamp that indicates when the row was created. If the database administrator inadvertently sets the filter to the wrong date, more rows than intended might be deleted. By delaying the application of log files, the rows would still exist on the RS secondary server. The database administrator can then extract the rows from the secondary server and insert them on the primary server.
Now suppose a database administrator is required to perform changes to the schema by renaming a table, but types the wrong command and drops the table orders instead of changing the table name to store_orders. If an RS secondary server is configured to delay application of logs, the database administrator can recover the orders table from the secondary server.
- Apply the staged log files after a specified time interval
- Stop applying log files at a specified time
You enable the delayed application of log files by setting configuration parameters in the onconfig file of the RS secondary server. You must specify the directory in which log files are staged by setting the LOG_STAGING_DIR configuration parameter before enabling the delayed application of log files. After specifying the LOG_STAGING_DIR configuration parameter, you configure the DELAY_APPLY or STOP_APPLY configuration parameters either by editing the onconfig file or dynamically using onmode -wf commands.
Where log records are stored
The server
creates additional directories named ifmxlog_## in
the directory specified by LOG_STAGING_DIR, where ## is
the instance specified by SERVERNUM. The directories are used to store
the logical logs and are also used during the recovery of the RS secondary
server. If recovery of the RS secondary server becomes necessary,
and the logs have wrapped on the primary server, then the logs in ifmxlog_## can
be used to recover the server. The files within ifmxlog_## are
purged when no longer required.
Conditions that trigger delays
The time values in the BEGIN WORK, COMMIT WORK, and ROLLBACK WORK log records are used to calculate how to delay or stop the application of log files. The time values are calculated before passing the log pages to the recovery process.
When a BEGIN WORK statement is issued, the BEGIN WORK log record is not written until the first update activity is performed by the transaction; therefore, there can be a delay between the time that the BEGIN WORK statement is issued and when the BEGIN WORK log is written.
Interaction with secondary server updates
You must consider the interaction between secondary server updates and delayed application of log files. If updates are enabled, and the secondary server is updated, the updates are not applied until after the amount of time specified by DELAY_APPLY. Disabling secondary server updates, however, also disables Committed Read, which guarantees that every retrieved row is committed in the table at the time that the row is retrieved.
To retain the Committed Read isolation level, consider enabling secondary server updates using the UPDATABLE_SECONDARY configuration parameter, but removing the RS secondary server used for delayed application of log files from the Connection Manager service-level agreement list. Alternatively, consider moving the RS secondary server to a new SLA.
See Database updates on secondary servers and HCL OneDB™ Administrator's Reference for more information.