IBM DB2 High Availability Disaster Recovery (HADR) Simulator
Table of Contents
HADR (High Availability Disaster Recovery) is a DB2 feature that provides high availability and disaster recovery protection. When enabled, transaction log records from the primary database are shipped to the standby database in real time as the records are written to disk on the primary database. The standby database continuously replays the received logs, thus staying in synch with the primary database. Should the primary fail, the standby takes over to provide continued service.
HADR is easy to use. It is fully integrated in DB2. Setup only requires a few database configuration parameters. It uses standard TCP interface to connect the primary and standby databases. It requires no special hardware or software.
With IBM DB2 High Availability Disaster Recovery (HADR) Simulator, HADR planning and deployment is even easier. You can estimate HADR performance under various conditions without even starting any database. HADR simulator simulates DB2 log write and HADR log shipping. It can
The simulator helps the user to plan, measure and diagnose HADR quickly. The simulator is very light weight. It consists of one process running on the primary host and one process running on the standby host. No setup or installation is needed. All configuration is passed as command line argument. The simulator itself is a standalone executable. No installation of DB2 or any other software packages is needed. You can run it on any machine and get result in seconds, without even starting the database.
The simulator arguments closely match HADR configuration, using parameters like local host, local port, remote host, remote port, tcp socket send/recv buffer. Tuning result from the simulator can be straight forward applied to real HADR.
Together with DB2 Log Scanner and HADR Calculator, you can quantitatively compute HADR performance based on your workload. See step by step guide on using these tools for HADR performance tuning.
As of Db2 v11.5, the "HADR Toolkit" suite of tools including db2logscan (Db2 Log Scanner), simhadr (HADR Simulator), and hadrCalculator (HADR Calculator) are available as part of your Db2 installation sqllib/bin (db2logscan, simhadr) and sqllib/bin/samples (hadrCalculator.pl), and do not need to be downloaded separately.
The HADR simulator executable (simhadr) is stand-alone. It does not need any DB2 libraries. You can run it on machines without DB2 installation. Binaries for selected platforms are pre-built. The OS version listed here is the version where the binary is built. Generally, the binary can also run on newer OS versions, but not older versions. If you need the simulator on other platforms, email db2hadr@wwpdl.vnet.ibm.com
IBM DB2 HADR Simulator is provided free of charge to current and potential IBM customers. They are provided as is, with no explicit or implicit warranty. Read licensing terms at IBM Software License before you proceed. Download only if you agree on the license terms.
| File name | OS | OS version | Bit size | Architecture |
|---|---|---|---|---|
| simhadr_aix | AIX | 6.1 | 64 | powerpc |
| simhadr_aix53 | AIX | 5.3 | 64 | powerpc |
| simhadr_hpia | HP-UX | 11.31 | 64 | IA64 |
| simhadr_linux | Linux | 2.6 | 64 | x86_64 |
| simhadr_linux32 | Linux | 2.6 | 32 | x86 |
| simhadr_linux_z | Linux | 2.6 | 64 | s390x |
| simhadr_linuxppc | Linux | 2.6 | 64 | powerpc |
| simhadr_sun | SunOS | 5.10 | 64 | sparc |
| simhadr_sunx86 | SunOS | 5.10 | 64 | x86 |
| simhadr_win.exe | Windows | (N/A) | 32 | x86 |
| simhadr_win64.exe | Windows | (N/A) | 64 | x86 |
Running simhadr with no argument will return version number, bit size, and help messages.
This section describes how to run the simulator for various HADR configurations. For details on all command line options. See next section "Command line options".
On the primary host, run simhadr as primary via "-role primary" option. On the standby host, run with "-role standby". Starting either process first is fine. The two processes will connect to each other and start log shipping. You may use -n (number of flushes) or -t (number of seconds) on primary to specify the length of the run. You can also interrupt a run any time by sending an "interrupt signal" (SIGINT, usually sent via control-C on keyboard) to the primary process. Upon end of run (including interrupted runs), both primary and standby will print out performance statistics to stdout.
Simulator only accepts numerical port numbers. It does not accept service names. This applies to -lport and -rport options.
For -lhost and -rhost options, both host name and IP address (such as 1.2.3.4) are accepted, just like real HADR.
Example:
- primary host is portland.ibm.com, HADR port is 4000
- standby host is sanfrancisco.ibm.com. HADR port is 5000.
- Sync mode is ASYNC (default is NEARSYNC)
- Run length is 60 seconds (default is 4 seconds)
On primary host portland.ibm.com, run:
simhadr_linux -lhost portland.ibm.com -lport 4000 -rhost sanfrancisco.ibm.com -rport 5000 -role primary -syncmode ASYNC -t 60
On standby host sanfrancisco.ibm.com, run:
simhadr_linux -lhost sanfrancisco.ibm.com -lport 5000 -rhost portland.ibm.com -rport 4000 -role standby
To simulate multiple standbys (supported in DB2 starting V10.1), start multiple pairs of primary-standby concurrently, with all primary processes on the primary host. In real HADR, each standby is served by a dedicated thread in the primary database. So the simulation is realistic in terms of data flow. In simulator, the primary processes are independent of each other. Each must be assigned a different local port. The standbys can have the same port because they run on different hosts. In real HADR, only one primary thread listens on the hadr_local_svc port of the primary database. All standbys connect to this port. After connection, the listener thread passes the connection over to the dedicated HADR thread (this is common TCP server design).
It is important to run the pairs concurrently to test if the primary can ship logs to multiple standbys at the same time. It is possible that one pair gets a lot more share of network bandwidth than the other. You may use -target option to limit the bandwidth a pair uses.
Multiple standby example:
- primary host is portland.ibm.com, HADR port is 4000 and 4001
- standby 1 host is sanfrancisco.ibm.com. HADR port is 5000. Sync mode is NEARSYNC
- standby 2 host is newyork.ibm.com. HADR port is 6000. Sync mode is SUPERASYNC.
On primary host portland.ibm.com, run:
simhadr_linux -lhost portland.ibm.com -lport 4000 -rhost sanfrancisco.ibm.com -rport 5000 -role primary -syncmode NEARSYNC -t 60
and
simhadr_linux -lhost portland.ibm.com -lport 4001 -rhost newyork.ibm.com -rport 6000 -role primary -syncmode SUPERASYNC -t 60
On standby 1 host sanfrancisco.ibm.com, run:
simhadr_linux -lhost sanfrancisco.ibm.com -lport 5000 -rhost portland.ibm.com -rport 4000 -role standby
On standby 2 host newyork.ibm.com, run (note that it connects to port 4001 on primary):
simhadr_linux -lhost newyork.ibm.com -lport 6000 -rhost portland.ibm.com -rport 4001 -role standby
To simulate HADR on pureScale systems (supported in DB2 starting V10.5), start multiple pairs of primary-standby concurrently, with each primary processes on a pureScale member host and all standby processes on the standby replay member host. In real HADR, all primary members connect to the standby replay member, where a dedicated thread serves each primary member. This is like the reverse of multiple standbys (multiple standby: one to many log shipping. pureScale: many to one log shipping).
It is important to run the pairs concurrently to test if the standby can receive logs from multiple primary members at the same time. It is possible that one pair gets a lot more share of network bandwidth than the other. You may use -target option to limit the bandwidth a pair uses.
pureScale example:
- primary member 0 host is portland_0.ibm.com, HADR port is 4000
- primary member 1 host is portland_1.ibm.com, HADR port is 4000
- standby replay member host is sanfrancisco.ibm.com. HADR port is 5000 and 5001.
- Sync mode is ASYNC
On primary host portland_0.ibm.com, run:
simhadr_linux -lhost portland_0.ibm.com -lport 4000 -rhost sanfrancisco.ibm.com -rport 5000 -role primary -syncmode ASYNC -t 60
On primary host portland_1.ibm.com, run:
simhadr_linux -lhost portland_1.ibm.com -lport 4000 -rhost sanfrancisco.ibm.com -rport 5001 -role primary -syncmode ASYNC -t 60
On standby replay host sanfrancisco.ibm.com, run:
simhadr_linux -lhost sanfrancisco.ibm.com -lport 5000 -rhost portland_0.ibm.com -rport 4000 -role standby
and
simhadr_linux -lhost sanfrancisco.ibm.com -lport 5001 -rhost portland_1.ibm.com -rport 4000 -role standby
DB2 HADR simulator can be compiled into either 32 or 64 bit applications. The bit size is shown in simhadr help message. Normally, there is little performance difference between the bit sizes. For best result, it is recommended that you run simhadr with the same bit size as your DB2 installation.
Real HADR requires the primary and standby host machines to be of the same OS type and machine architecture. The simulator has no requirement on OS type, or machine architecture (primary and standby can be on machines of different endian). This allows you to experiment on mixed platforms.
Flush size, Sync mode, Disk speed, Send and receive buffer sizes, etc.
See HADR simulator parameters
Together with DB2 Log Scanner and HADR Calculator, you can quantitatively compute HADR performance based on your workload.
See step by step guide on using these tools for HADR performance tuning.