DB2 10.5 for Linux, UNIX, and Windows

hadr_target_list - HADR target list database configuration parameter

This parameter specifies a list of target host:port pairs that represent HADR standby databases. You must set the hadr_target_list parameter to enable multiple standby databases or to set up HADR in a DB2® pureScale® environment.

Configuration type

Database

Applies to

Database server with local and remote clients
Database server with local clients

Parameter type

Configurable online if the environment does not use the DB2 pureScale Feature, subject to the restrictions later in this topic

Default

NULL

Upgrade Note

If you are upgrading from a DB2 Version 9.8 Fix Pack 4 pureScale environment or earlier, the value of hadr_target_list is set to the value on member 0.

The host:port pairs that you specify for the hadr_target_list configuration parameter for a primary determine which hosts act as standbys for that primary. The host:port pairs in the target list of a standby identify the standby hosts to be used if this standby takes over as the new HADR primary database.

As with the hadr_remote_host and hadr_local_host database configuration parameters, you can specify a host for the hadr_target_list configuration parameter with either a host name or an IP address. A host name can contain alphanumeric characters, dashes, and underscores only. As with the hadr_remote_svc and hadr_local_svc configuration parameters, you can specify a port for the hadr_target_list configuration parameter with either a port number or a service name. A service name can consist of any characters. A host name is mapped to an IP address, and a service name is mapped to a port number. The values that you specify for the hadr_target_list configuration parameter can be a combination of host names, host IP addresses, service names, and port values.

Separate the host:port pairs with the vertical bar (|), as shown in the following example:

host1:port1|host2:port2|host3:port3

To differentiate the IP part from the port part, you must enclose Numerical Internet Protocol version 6 (IPv6) addresses in square brackets: []. An example follows:

[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:4000

In a DB2 pureScale environment, you specify a group of member hosts for the standby cluster in braces: {}. The braces are required in DB2 pureScale environment, even if only one address is listed for a cluster. In other environments, it can be omitted if there is only one address for a database. An example follows:

{host1:1000|host2:1000|host3:1000}

In the target list for a standby cluster, only a subset of the cluster's members are required. In an extreme case, only one member's address is listed. However, this is not a best practice because it creates a single point of failure. If the listed member is offline, the cluster cannot be reached. For a small cluster (such as one with four members), it is recommended that you list all members. For large clusters, list the members that are most likely to be online. It is strongly recommended that you list the preferred replay member.

Note: Currently for DB2 pureScale setups, you can specify only one cluster in the target list.

The first database in the target list of an HADR database is designated as theprincipal HADR standby database, and any other entries are called auxiliary HADR standby databases. You can configure the primary-principal standby HADR pair to use any synchronization mode supported in the DB2 environment (in a DB2 pureScale environment, only ASYNC and SUPERASYNC modes are supported) by using the hadr_syncmode configuration parameter on the primary. The synchronization mode of the auxiliary standby targets is always SUPERASYNC. When you start HADR on the primary, the values for the hadr_remote_host and hadr_remote_svc configuration parameters are automatically set to those of the principal standby unless you set the DB2_HADR_NO_IP_CHECK registry variable to ON.

There is no requirement for reciprocal principal standby settings. For example, database A can designate database B as its principal standby, and database B can designate database C as its principal standby. However, general primary-standby reciprocal setting is required. For example, if database B is listed in the target list of database A, database A must be listed in the target list of database B. This ensures that after a role switch, the old primary is still accepted as the new standby of the new primary. For example, the following configuration is acceptable; however, database C is only valid standby if database B is the primary:

On database A: hadr_target_list contains database B
On database B: hadr_target_list contains database C and A
On database C: hadr_target_list contains database B

Although you can update the value of the hadr_target_list parameter and have the changes take effect while the database is online, there are some restrictions if HADR is active:

You cannot change the principal standby of the primary without first stopping HADR on the primary.
You cannot remove a standby from the list if it is connected to the primary. To disconnect a standby, deactivate it. Then you can remove it from the primary's target list.
You cannot dynamically update the hadr_target_list configuration parameter for a standby unless you enabled the HADR reads on standby feature.
You cannot remove the primary database from the target list of a standby if the standby is connected to the primary.
The target list must contain IP addresses that are either IPv4 or IPv6, but not a combination of the two.
You can not dynamically update the hadr_target_list configuration parameter if you are using the DB2 pureScale Feature.