There are a number of considerations for database configuration
in a multiple HADR standby setup.
Automatic reconfiguration of HADR parameters
- Reconfiguration after HADR starts
In multiple standby mode, the configuration parameters that
identify the primary database for the standbys and identify the principal
standby for the primary are automatically reset when HADR starts if
you did not correctly set them; however, an initial non-NULL value
is required. This behavior applies to the following configuration
parameters:
- hadr_remote_host
- hadr_remote_inst
- hadr_remote_svc
Tip: Even though this automatic reconfiguration occurs,
you should always try to set the correct initial values because that
reconfiguration might not take effect until a connection is made between
a standby and its primary. In some HADR deployments, those initial
values might be needed. For example, if you are using the IBM® Tivoli® System Automation for Multiplatforms software,
the value for the hadr_remote_inst configuration
parameter is needed to construct a resource name.
Note: If the DB2_HADR_NO_IP_CHECK registry
variable is set to ON, the hadr_remote_host and hadr_remote_svc are
not automatically updated.
Reconfiguration
is predicated on the values of the hadr_target_list configuration
parameter being correct; if anything is wrong in a target list entry,
you must correct it manually.
On the primary, the reconfiguration
occurs in the following manner:
- If the values for the hadr_remote_host and hadr_remote_svc configuration
parameters do not match the host:port pair
that is the first entry of the hadr_target_list configuration
parameter (namely, the principal standby), the hadr_remote_host and hadr_remote_svc configuration
parameters are updated with the values from the target list.
- If the value for the hadr_remote_inst configuration
parameter does not match the instance name of the principal standby,
the correct instance name is copied to the hadr_remote_inst configuration
parameter for the primary after the principal standby connects to
it.
On a standby database, the reconfiguration occurs in the
following manner:
- When a standby starts, it attempts to connect to the database
that you specified for its hadr_remote_host, hadr_remote_inst,
and hadr_remote_svc configuration parameters.
- If the standby cannot connect to the primary, it waits for the
primary to connect to it.
- The primary attempts to connect to its standbys using addresses
listed in its hadr_target_list parameter. After
the primary connects to a standby, the hadr_remote_host, hadr_remote_inst,
and hadr_remote_svc configuration parameters
for the standby are updated with the correct values for the primary.
- Reconfiguration during and after a takeover
In a non-forced takeover, the values for the hadr_remote_host, hadr_remote_inst,
and hadr_remote_svc configuration parameters
on the new primary are automatically updated to its principal standby,
and these parameters on the standbys listed in the new primary's hadr_target_list are
automatically updated to point to the new primary. Any database that
is not listed in the new primary's hadr_target_list is
not updated. Those databases continue to attempt to connect to the
old primary and get rejected because the old primary is now a standby.
The old primary is guaranteed to be in the new primary's target list
because of the requirement of mutual inclusion in the target list.
In a forced takeover, automatic update on the new primary
and its standbys (excluding the old primary) work the same way as
non-forced takeover. However, automatic update on the old primary
does not happen until it is shut down and restarted as a standby for
reintegration.
Any database that is not online during the takeover
will be automatically reconfigured after it starts. Automatic reconfiguration
might not take effect immediately on startup, because it relies on
the new primary to periodically contact the standby. On startup, a
standby might attempt to connect to the old primary and follow the
log stream of the old primary, causing it to diverge from the new
primary's log stream and, making that standby unable to pair with
the new primary. As a result, you must shut down the old primary before
takeover to avoid that kind of split brain scenario.
Lack of standby control of the synchronization mode
and peer window
In multiple standby mode, only the settings
of the
hadr_syncmode and
hadr_peer_window configuration
parameters of the current primary are relevant. The standby databases
either have the settings for those parameters defined by the primary,
in the case of the principal standby, or by their role as an auxiliary
standby.
- Synchronization mode
In multiple standby mode, the setting for the hadr_syncmode configuration
parameter do not have to be the same on the primary and standby databases.
Whatever setting you specify for the hadr_syncmode configuration
parameter on a standby is considered its configured synchronization
mode; this setting has relevance only if the standby becomes
a primary. The standby is assigned an effective synchronization
mode. For any auxiliary standby, the effective synchronization
mode is always SUPERASYNC. For the principal standby, the effective
synchronization mode is the setting for the hadr_syncmode configuration
parameter for the primary. For a standby, the monitoring interfaces
display the effective synchronization mode as the synchronization
mode.
- Peer window
- In multiple standby mode, the setting for the hadr_peer_window configuration
parameter does not have to be the same on the primary and standby
databases. In fact, any setting for the hadr_peer_window configuration
parameter on the auxiliary standbys is ignored because peer window
functionality is incompatible with SUPERASYNC mode. The principal
standby uses the peer window setting of the primary, which is applicable
only if the value of the hadr_syncmode configuration
parameter for the standby is SYNC or NEARSYNC,
just as with single standby mode.
DB2 Version 10.1 for Linux, UNIX, and Windows