HADR Commands
Table of Contents
HADR role change
As shown in the diagram below, the start/stop/takeover HADR commands change database role among standard (non-HADR), primary, and standby.
Notes:
- "Start HADR ... as primary" command changes the role of a database from standard to primary.
- The database can be offline or online when the command is issued.
- "Start HADR ... as standby" command changes the role of a database from standard to standby.
- The database must be offline when the command is issued.
- The database must be in rollforward pending or in-progress state when the command is issued.
- "Start HADR" command (as primary or as standby) brings the database online if it is offline.
- "Stop HADR" command changes the role of a database from primary or standby to standard.
- When issued on a primary database, the database can be offline or online when the command is issued.
- When issued on a standby database, the database must be offline when the command is issued.
- When issued on a standby database, the database is changed back into standard role with rollforward pending state set.
- Non forced takeover command switches role of primary and standby
- Forced takeover (failover) command only changes the standby to primary
- After a failover, the old primary can be converted into a new standby via the "start HADR ... as standby" command. This is known as "primary reintegration". See HADR takeover for more info on takeover and primary reintegration.
HADR role is persistent. Once set to primary or standby role, a database will perform log shipping and log replaying according to the role. Database activation/deactivation does not change the role. Only the HADR commands can change the role. A database can repeatedly go through role change using the commands.
The current role is reported by HADR monitoring. If the database is offline, the role can still be shown through the "HADR database role" field from "db2 get db cfg for <dbname>" output.
Start/stop HADR can be issued on the primary dynamically (while database is online). This means you can enable/disable HADR without down time on the primary. Starting in DB2 V10.1, dynamic start on HADR also picks up updated HADR database configuration parameters. See section "Refreshing HADR configuration" in HADR config for more info.
Start/stop HADR can only be issued on the standby while database is offline. A standard database must be in rollforward pending or in-progress state to allow "start HADR as standby". When "stop HADR" changes the database back into standard role, the database is marked as rollforward pending, so that it can allow the next "start HADR as standby".
Regular "rollforward" command can be used to replay logs on a standard database before "start HADR as standby", or after "stop HADR". Rollforward does not preclude the next "start HADR as standby", as long as the rollforward does not end (no "stop") and database stays in rollforward pending or in progress state. However, it is recommended to always let HADR manage log shipping and log replay. Mixed rollforward and HADR replay is not recommended.
If you would like to convert a standby database into normal state to accept client connections, run "rollforward to end of logs and stop" after "stop HADR". The database is then no longer in rollforward state. However, the database can not be converted back into a standby.
HADR database startup/shutdown
An HADR primary database can be started by one of the following methods:
- "Activate db" command
- Client connection
- "Start HADR ... as primary" command
An HADR standby database can be started by one of the following methods:
- "Activate db" command
- "Start HADR ... as standby" command
Client connection cannot start a standby database, even if reads on standby is enabled.
Once an HADR primary or standby database is started (by any means), database activation flag is set, as if the database was started by the "activate db" command. Database does not shut down when the last client disconnects. Explicit "deactivate db" command is needed to shutdown HADR databases (primary or standby).
Use "activate db" and "deactivate db" command to activate and deactivate primary and standby, even though "start hadr" command implicitly activates a database. Use "start hadr" command only if you need HADR specific functionality such as changing role, or starting primary by force. Avoiding unnecessary use of HADR commands minimizes the risk of unintentional role change.
"Stop hadr" command does not deactivate database. In fact, it is not even allowed on an online standby database. On a primary database, it stops HADR operations, changes role to standard, but leave the database online. There is no impact to client transactions.
Split brain prevention
When a primary database starts, it waits for up to hadr_timeout seconds for the standby to connect to it. If no standby connects, it will timeout and startup will fail. This is intended to prevent split brain. If the standby has taken over and become a new primary, it won't connect to the old primary, then the old primary couldn't come up. In a multiple standby system, the primary only waits for the principal standby. So if any auxiliary standby takes over, the old primary can still come up. Thus in multiple standby environment, user must ensure that the old primary is down and remains down when failing over to an auxiliary standby.
The "by force" option on "start hadr as primary" command allows a primary to start without connection to the standby. This is useful when you know that the standby is offline or primary/standby network is not functioning.
Primary/standby startup and shutdown order
Standby database startup does not wait for a connection to the primary. Thus it is recommended to start the standby first, then the primary.
It is recommended to shutdown primary database first, then the standby database, so that all primary data will be replicated to the standby.