5.1.4 Synchronization modes for HADR

With HADR, you can choose the level of protection that you want from a potential loss of data by specifying one of three synchronization modes: synchronous, near synchronous, or asynchronous. The synchronization mode indicates how log writing is managed between the primary and standby databases. These modes apply only when the primary and standby databases are in peer state.

This mode provides the greatest protection against transaction loss, and using it results in the longest transaction response time amongst the three modes. In this mode, log writes are considered successful only when logs have been written to log files on the primary database and when the primary database has received acknowledgement from the standby database that the logs have also been written to log files on the standby database. The log data is guaranteed to be stored at both sites.

While this mode has a shorter transaction response time than synchronous mode, it also provides slightly less protection against transaction loss. In this mode, log writes are considered successful only when the log records have been written to the log files on the primary database and when the primary database has received acknowledgement from the standby system that the logs have also been written to main memory on the standby system. Loss of data occurs only if both sites fail simultaneously and if the target site has not transferred to nonvolatile storage all of the log data that it has received.

This mode has the highest chance of transaction loss if the primary system fails. It also has the shortest transaction response time among the three modes. In this mode, log writes are considered successful only when the log records have been written to the log files on the primary database and have been delivered to the TCP layer of the primary system's host machine. Because the primary system does not wait for acknowledgement from the standby system, transactions might be considered committed when they are still on their way to the standby.

Automatic Client Reroute (ACR) is another feature that was first introduced in DB2 UDB v8.2. If a database application loses communication with a DB2 database server, ACR reroutes that client application to an alternate database server so that the application can continue its work with minimal interruption. Rerouting is only possible when an alternate database location has been specified at the primary database server. ACR is only supported with the TCP/IP protocol.
xxxx