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
-
- Default [range]
- DB2® pureScale® environments
- ASYNC [ASYNC, SUPERASYNC]
- Other environments
- NEARSYNC [SYNC, NEARSYNC, ASYNC, SUPERASYNC]
- Upgrade Note
- If
you are upgrading from a DB2 Version 9.8 Fix Pack 4 pureScale environment
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.
- 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.
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)
- 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 when you have
not configured the hadr_target_list parameter.
DB2 10.5 for Linux, UNIX, and Windows