hadr_syncmode - HADR synchronization mode for log writes in peer state configuration parameter

This parameter specifies the synchronization mode, which determines how log writes on the primary are synchronized with log writes on the standby when the systems are in peer state.
Configuration type
Database
Applies to
  • Database server with local and remote clients
  • Database server with local clients
Parameter type
  • Configurable1
Default [range]
Db2® pureScale® environments
ASYNC [SYNC, NEARSYNC, ASYNC, SUPERASYNC]
Other environments
NEARSYNC [SYNC, NEARSYNC, ASYNC, SUPERASYNC]
Upgrade Note
  • If you are upgrading from Db2 version 9.8 Fix Pack 4 or earlier, the value of hadr_syncmode is set to the value on member 0.

Valid values for this parameter are as follows:

SYNC
This mode provides the greatest protection against transaction loss, but at a cost of higher transaction response time.
In this mode, log writes are considered successful only when both of the following conditions are met:
  • The log records were written to the log files on the primary database.
  • The primary database received acknowledgement from the standby database that the log records were also written to log files on the standby database.
The log data is guaranteed to be stored at both sites.
NEARSYNC
This mode provides somewhat less protection against transaction loss, in exchange for a shorter transaction response time than that of SYNC mode.
In this mode, log writes are considered successful only when both of the following conditions are met:
  • The log records were written to the log files on the primary database.
  • The primary database received acknowledgement from the standby database that the log records were also written to main memory on the standby system.
Loss of data occurs only if both sites fail simultaneously and if the standby site has not transferred to nonvolatile storage all the log data that it received.
ASYNC
Compared with the SYNC and NEARSYNC modes, the ASYNC mode results in shorter transaction response times but might cause greater transaction losses if the primary database fails.
In this mode, log writes are considered successful only when both of the following conditions are met:
  • The log records were written to the log files on the primary database.
  • The log records were delivered to the TCP layer of the primary system's host.
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.
Note: The hadr_syncmode configuration parameter cannot be set to ASNYC if peer window functionality is enabled (that is, if hadr_peer_window has a nonzero value).
SUPERASYNC
This mode has the shortest transaction response time but also has the highest probability of transaction losses if the primary system fails. This mode is useful when you do not want transactions to be blocked or experience longer response times due to network interruptions or congestion.
In this mode, the HADR pair can never be in peer state or disconnected peer state. The log writes are considered successful only when the log records were written to the log files on the primary database. 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.
Note: The hadr_syncmode configuration parameter cannot be set to SUPERASNYC if peer window functionality is enabled (that is, if hadr_peer_window has a nonzero value).
Figure 1 shows when the logs for transactions are considered successful based on the level of synchronization that you chose:
Figure 1. Synchronization modes for high availability disaster recovery (HADR)
Diagram showing when logs are considered successful for the HADR synchronization modes
Usage notes

Although you set the hadr_syncmode parameter on the primary and the standby databases, the effective synchronization mode is determined by the primary or by the standby's role. That is, auxiliary standbys (any standby that is not listed as the first entry in the primary's target list) automatically have their synchronization modes set to SUPERASYNC. Also, the principal standby (the standby that is listed as the first entry in the primary's target list) uses the synchronization mode that you set on the primary. The only exception to this is if you used the deprecated method of setting up HADR without using the hadr_target_list parameter. If you use this method, the settings for hadr_syncmode need to be identical on the primary and the standby.

1 Changes to this parameter take effect on database activation. If the database is already online, you can have changes take effect by stopping and restarting HADR on the primary database.