What's new in HADR

List of HADR new features since original HADR release in DB2 V82. Sorted by most recent ones first.

Table of Contents

New in v11.5

  • HADR Reads on Standby new default behaviour – the availability of the standby database to perform SQL queries is significantly enhanced through the avoidance of the replay-only window.
  • Introduced DB2_HADR_STANDBY_KEEP_UNARCHIVED_LOGS regvar
    • Controls whether standby will keep log files when the corresponding log files on primary are not archived
    • Set to FALSE on standby, standby will delete log files when the corresponding log files on primary are not archived
    • DEFAULT: TRUE
  • HADR now respects SSL_CIPHERSPECS
    • Specifies the cipher suites that the server allows for incoming connection requests when using SSL protocol
    • Additionally, will now also specify the cipher suites used to communicate between primary and standby
  • Changes to logarchmeth1/2 on an HADR standby will take effect upon HADR startup/re-activation as well as during takeover.

New in v11.1

New in v11.1.4.4

  • In HADR Reads on Standby (ROS) environments, the availability of the standby database to perform SQL queries is significantly enhanced through the avoidance of the replay-only window. See DB2_HADR_ROS_AVOID_REPLAY_ONLY_WINDOW for details.
  • A new db2fmtlog tool can be used to extract and display information from transaction log files. Information extracted consists of encryption or compression status, log chain information, range of log records, and other metadata. This information is useful in problem determination scenarios. This information can also assist with identifying which log records can trigger 'replay only windows' in HADR Reads-on-Standby environments. For more information, see db2fmtlog – Format and display log file information command

New in v11.1.3.3

  • SSL support for the transmission of transaction log data between the HADR primary and standby database servers, previously limited to the Linux Amd64/Intel operating system, is now supported on all Unix and Windows operating systems, excluding Db2 pureScale environments. Setup instructions are available at Configuring SSL for the communication between primary and standby HADR servers .
  • In HADR Standby databases with Reads On Standby (ROS) enabled, diagnostic improvements allow for easier identification of operations which cause replay-only windows. For details on the new db2diag.log messaging see DB2_HADR_REPLAY_ONLY_WINDOW_DIAGLEVEL in Miscellaneous variables . For more information on the new transaction flag of db2pd -transactions , see db2pd - Monitor and troubleshoot Db2 database command .
  • In HADR environments, integrity checking of transaction log data during network transmission between the primary and standby database servers is improved. When an integrity check failure is detected, seamless retransmission of the log data is performed to auto-correct the condition, with no user intervention required.

New in v11.1.2.2

New in v11.1.1.1

  • For Db2 pureScale users who want to upgrade from supported Db2 Version 10.5 fix packs, or later, refer to the FAQ technote for supported V10.5 fix pack levels. High availability disaster recovery (HADR) environments can now be upgraded without the need to reinitialize the standby database after you upgrade the primary database.
  • SSL is now supported between the HADR primary and standby servers on Linux. However, this SSL support is only present in the Linux Amd64/Intel environment, not in the Linux PPCLE or Linux Z environment. Setup instructions are available at Configuring SSL for the communication between primary and standby HADR servers .
  • HADR Upgrade to Db2 11.1.1.1 from Db2 10.5 without having to reinitialize the standby with a new backup. Further information refer to High availability, backup, logging, resiliency, and recovery enhancements .

Older Releases

V10.5 fp4 Columnar data support

First available in V10.5 fp4 (Cancun release)
HADR is now supported on databases with columnar tables. Note that reads on standby still cannot query columnar tables.

V10.5 pureScale Support

First available in V10.5
HADR is now supported on pureScale clusters. See HADR in DB2 pureScale environments

V10.5  Monitor fields STANDBY_SPOOL_PERCENT and HADR_FLAGS

First available in V10.5
STANDBY_SPOOL_PERCENT reports spool usage, similar to STANDBY_RECV_BUF_PERCENT.
STANDBY_RECV_BLOCKED and STANDBY_LOG_DEVICE_FULL from HADR_FLAGS are very useful warning flags.
See also HADR monitoring and HADR flags monitor element

V10.1 Multiple standby

First available in V10.1
Up to 3 standbys are supported. Now you can provide HA and DR protection to your database with a single technology. See HADR multiple standby databases

V10.1  Enhanced HADR Monitoring

First available in V10.1
"db2pd -hadr" format is easier to parse. MON_GET_HADR table function available. New fields specifically for performance monitoring: LOG_HADR_WAIT_CUR, LOG_HADR_WAIT_ACCUMULATED, LOG_HADR_WAIT_RECENT_AVG. See also HADR monitoring

V10.1 Semi-dynamic HADR Configuration Parameters

First available in V10.1.
Static database configuration parameters for HADR will be refreshed on database startup and on HADR component startup. Therefore "stop HADR" followed by "start HADR" command on a primary database will pickup new values of HADR parameters. This allows initializing and reconfiguring HADR without downtime on the primary database. See also HADR Config - HADR Database Configuration Parameters

V10.1 Spooling

First available in V10.1
Spooling allows you to specify additional space where logs can be spooled on the standby. This helps avoid back-pressure on the primary caused by sudden spikes in logging activity. See HADR log spooling

V10.1  Delayed Replay

First available in V10.1
Delayed replay helps prevent data loss due to errant transactions. See HADR delayed replay

SuperAsync mode

First available in V95fp8 and V97fp5
In this new mode, transactions on primary database will never be slowed down or blocked. See SUPERASYNC mode

Inline XML and LOB object support for Reads on Standby

First available in V97fp5
Reads on standby can return inline XML and LOB objects. Queries on non-inline objects will still return error. This allows small LOB/XML objects to be returned by reads on standby.

Reads on Standby

First available in V97fp1 (Dec. 2009)
HADR standby database now accepts read-only queries. To enable this feature, set registry variable DB2_HADR_ROS to ON on the standby instance. For details, see Enabling reads on standby

Block Non Logged, BLOCKNONLOGGED

First available in V95fp4 and V97
When database parameter BLOCKNONLOGGED is set to YES (default NO), tables with "not logged initially" attribute or not logged LOB columns can not created, either by create table or alter table statement. See blocknonlogged - Block creation of tables that allow non-logged activity configuration parameter

HADR standby receive buffer usage reported in db2pd

First available in V8fp17, V91fp5, and V95fp2
Db2pd -hadr option will report percentage of HADR standby buffer used. If the percentage frequently hits 100%, consider increasing buffer size. If utilization is low, consider reducing buffer size. Buffer size can be set via registry variable DB2_HADR_BUF_SIZE. For more info, see db2pd - Monitor and troubleshoot DB2 database command

DB2_HADR_SOSNDBUF and DB2_HADR_SORCVBUF

First available in V8fp17, V91fp5, and V95fp2
Registry variable to tune socket buffer size for HADR connections. This allows tuning TCP window size for HADR connection without impact on other TCP connections on the system. For more info, see Miscellaneous variables

DB2_HADR_PEER_WAIT_LIMIT

First available in V8fp16, V91fp4, and V95fp1
Registry variable for maximal primary logging wait time. Prevents primary logging from blocking because of slow or blocked standby. For more info, see Miscellaneous variables

HADR peer window

First available in V95
Database configuration parameter hadr_peer_window allows takeover with no data loss when primary failed within peer window. For more info, see HADR peer window configuration parameter

DB2_HADR_NO_IP_CHECK

First available in V8fp15, V91fp3, and V95.
Registry variable to bypass IP address cross check in NAT (Network Address Translation) environment. This feature allows HADR to be deployed in NAT environment. For more info, see HADR and Network Address Translation (NAT) support