Shulou(Shulou.com)06/01 Report--

In the new feature of HADR multi-standby machine, standby database is divided into two categories.

One is the main standby (Principal Standby).

The other is the auxiliary standby (Auxiliary Standby).

I. Catalog preparation

Mkdir-p / home/db2inst1/db2_backup

Mkdir-p / home/db2inst1/db2_archive

Mkdir-p / home/db2inst1/db2_log

Chmod-R 775 / home/db2inst1/db2_backup

Chmod-R 775 / home/db2inst1/db2_archive

Chmod-R 775 / home/db2inst1/db2_log

Chown-R db2inst1:db2inst1 / home/db2inst1/db2_backup

Chown-R db2inst1:db2inst1 / home/db2inst1/db2_archive

Chown-R db2inst1:db2inst1 / home/db2inst1/db2_log

Second, set up archiving and opening log reconstruction mode

Db2 update db cfg for hadb using logarchmeth2 disk:/home/db2inst1/db2_archive/

Db2 update db cfg for hadb using NEWLOGPATH / home/db2inst1/db2_log

III. Backup and archiving

Db2 force applications all

Db2 backup db hadb to / home/db2inst1/db2_backup/

Db2stop force;db2start

Db2 archive log for db hadb

III. Backup

Db2 backup db hadb to / home/db2inst1/db2_backup/

Scp / home/db2inst1/db2_backup/HADB.0.db2inst1.DBPART000.20180117141245.001 db2inst1@192.168.12.31:/home/db2inst1/db2_backup/

Let's start configuring HADR

1.2.6 backing up and restoring data

Offline backup of main library

Db2 backup database hadb to / home/db2inst3/

Reserve library restore

First restore the main library and the secondary library 1, and leave a secondary library 2 for dynamic addition

Db2 restore database hadb from "/ home/db2inst1/db2_backup/" taken at 20180117141245 replace history file

# on M5

Db2 "UPDATE DB CFG FOR MYDB USING

HADR_TARGET_LIST M4:DB2_db2insta_2nd | M3:DB2_db2insta_pri

HADR_REMOTE_HOST M3

HADR_REMOTE_INST db2insta

HADR_REMOTE_SVC DB2_db2insta_pri

HADR_SYNCMODE superasync

HADR_LOCAL_HOST M5

HADR_LOCAL_SVC DB2_db2insta_3rd "

2.1.1 configure the main library

Db2 "UPDATE DB CFG FOR HADB USING

HADR_TARGET_LIST 192.168.12.31 HADR_TARGET_LIST 55004 | 192.168.12.33 ip 55005Meltel-main standby ip and port, auxiliary standby ip and port

HADR_REMOTE_HOST 192.168.12.31-Primary standby ip and Port

HADR_REMOTE_SVC 55004Murray-main standby port

HADR_SYNCMODE sync

HADR_REMOTE_INST db2inst1- master slave instance

HADR_LOCAL_HOST 192.168.12.30 Murray-ip of the mainframe

HADR_LOCAL_SVC 55003 "- host port

Db2 "UPDATE DB CFG FOR mydb USING

HADR_TARGET_LIST 192.168.12.31 HADR_TARGET_LIST 55004 | 192.168.12.33 purl 55005

HADR_REMOTE_HOST 192.168.12.31

HADR_REMOTE_SVC 55004

HADR_SYNCMODE sync

HADR_REMOTE_INST db2inst1

HADR_LOCAL_HOST 192.168.12.30

HADR_LOCAL_SVC 55003 "

2.1.2 configure the main standby

# on M4

Db2 "UPDATE DB CFG FOR MYDB USING

HADR_TARGET_LIST M3:DB2_db2insta_pri | M5:DB2_db2insta_3rd

HADR_REMOTE_HOST M3

HADR_REMOTE_INST db2insta

HADR_REMOTE_SVC DB2_db2insta_pri

HADR_SYNCMODE sync

HADR_LOCAL_HOST M4

HADR_LOCAL_SVC DB2_db2insta_2nd "

# on host2

Db2 "UPDATE DB CFG FOR HADB USING

HADR_TARGET_LIST 192.168.12.30 HADR_TARGET_LIST 55000 | 192.168.12.33 Flux 55003

HADR_REMOTE_HOST 192.168.12.30

HADR_REMOTE_SVC 55000

HADR_LOCAL_HOST 192.168.12.31

HADR_LOCAL_SVC 55001

HADR_SYNCMODE sync

HADR_REMOTE_INST db2inst1 "

2.1.3 configure secondary standby 1

# on host3

Db2 "UPDATE DB CFG FOR HADB USING

HADR_TARGET_LIST 192.168.12.31 purl 55001 | 192.168.12.30 purl 55000

HADR_REMOTE_HOST 192.168.12.30

HADR_REMOTE_SVC 55000

HADR_SYNCMODE superasync

HADR_REMOTE_INST db2inst1

HADR_LOCAL_HOST 192.168.12.33

HADR_LOCAL_SVC 55003 "

2.2 start HADR

2.2.1 start the main standby

[db2inst3@kvm102 ~] $db2 START HADR ON DB HADB AS STANDBY

DB20000I The START HADR ON DATABASE command completed successfully.

[db2inst3@kvm102 ~] $db2pd-hadr-alldbs

2.2.2 start the auxiliary standby

2.2.3 start the main library

Db2 deactivate db hadb

Db2 START HADR ON DB HADB AS PRIMARY

Db2 deactivate db sample

Db2 stop HADR ON DB HADB

Turn off the recommended order for HADR pairs

Warning:

Although you can use the STOP HADR command against the primary and / or standby databases to stop HADR, use it with caution.

If you want to stop the specified database, but still want to retain its HADR primary or standby database role, do not issue the STOP HADR command.

If you issue the STOP HADR command, the database becomes a standard database and may need to be reinitialized to continue to run as a HADR database. Issue the DEACTIVATE DATABASE command instead.

If you only want to turn off the HADR operation, here are the recommended ways to turn off the HADR pair:

Deactivate the primary database

Stop DB2 on the primary database

Deactivate the standby database

Stop DB2 on the standby database

When you start HADR, the opposite is true:

1. Start the slave database. If you enter local catchup,remote catchup pending after the slave database is started, you will always try to connect to the main database.

2. Start the main database and wait for the connection of the standby database to be received. If the connection of the standby database cannot be received at the specified time (hadr_timeout), the startup fails, so as to prevent brain split from brain fissure. Once the standby library is connected to the main library

Enter the remote catchup state. After replaying the logs sent from the main library, enter the peer state.

IV. Execution on the main database

Db2 "update db cfg for HADB using

HADR_TARGET_LIST 192.168.12.31 HADR_TARGET_LIST 55001 | 192.168.12.32 Fran 55002murmuri-auxiliary list

HADR_REMOTE_HOST 192.168.12.31-main and subsidiary

HADR_REMOTE_SVC 55002

HADR_LOCAL_HOST 192.168.12.30-main library

HADR_LOCAL_SVC 55001

HADR_SYNCMODE sync

HADR_REMOTE_INST db2inst1 "

Configure hosts and services files

Vi / etc/hosts

Vi / etc/Services

DB2_HADR_A 55000/tcp

DB2_HADR_B 55001/tcp

DB2_HADR_C 55003/tcp

1. Configure ROS and UR isolation of three standby devices

Db2set DB2_HADR_ROS=1

Db2set DB2_STANDBY_ISO=UR

2. Restore HADB database on standby

Db2 restore db HADB

ServerA: 192.168.1.105 host

ServerB: 192.168.1.106 active / standby

ServerD:192.168.1.104 backup 1

ServerE: 192.168.1.107 Supplementary 2

Execute on the main and standby database

Note that the first is the host IP address, followed by the IP address of secondary 1, and the IP address of secondary 2.

Db2 "update db cfg for HADB using HADR_TARGET_LIST 192.168.12.30 virtual 55001 | 192.168.12.32 55003

HADR_REMOTE_HOST 192.168.12.30-Master

HADR_REMOTE_SVC 55001

HADR_LOCAL_HOST 192.168.1.31 Murmuri-subsidiary

HADR_LOCAL_SVC 55002

HADR_SYNCMODE sync

HADR_REMOTE_INST db2inst1 "

Db2 "update db cfg for HADB using HADR_TARGET_LIST 192.168.12.30 virtual 55001 | 192.168.12.32 55003

HADR_REMOTE_HOST 192.168.12.30

HADR_REMOTE_SVC 55001

HADR_LOCAL_HOST 192.168.1.31

HADR_LOCAL_SVC 55002

HADR_SYNCMODE sync

HADR_REMOTE_INST db2inst1 "

Execute on the auxiliary library

Db2 "update db cfg for HADB using HADR_TARGET_LIST 192.168.12.31 virtual 55002 | 192.168.12.30 virtual 55001

HADR_REMOTE_HOST 192.168.12.30

HADR_REMOTE_SVC 55001

HADR_LOCAL_HOST 192.168.12.32

HADR_LOCAL_SVC 55003

HADR_SYNCMODE superasync

HADR_REMOTE_INST db2hadr "

State: the current state of the HADR. Including Local Catchup, Remote Catchup, Remote Catchup Pending, Peer, Disconnect Peer.

Local Catchup: if the slave is in this state, it indicates that the slave is reading the log file from the local disk and redoing the log; if the host is in this state, it is waiting for the slave to connect. The host of HADR does not read the log locally and redo it. The reason why we ask the host to display this status is to tell the user that the standby is redoing the local log through this status on the host.

Remote Catchup: the host of the HADR in this state is reading logs locally and sending them to the standby, while the standby receives logs from the host, writes them to its local disk, and redoes them.

Remote Catchup Pending: if the standby is in this state, it is trying to connect to the host. This state is usually due to the fact that the host does not exist or the host has not been fully started, resulting in an unsuccessful connection.

Peer: if the master / slave machine of HADR is in this state, it indicates that the network connection between the host and the slave is good. The log can be sent smoothly from the host to the standby machine.

Disconnect Peer: if the master / slave machine of the HADR is in this state, the network of the host and slave has been disconnected, but the disconnection time does not exceed the PEER_WINDOW. In this state, transactions on the host cannot be committed. If the network is restored and the connection between the host and slave is re-established, the master and slave will return to the PEER state; if both parties enter this state because the host fails, data loss will not occur when the takeover operation is performed on the slave. That is, there will be no situation in which the host commits a transaction, but the standby does not commit the transaction.

Disconnected: if the host is in this state, it indicates that the host has not received a connection from the standby. If the standby is in this state, it indicates that the standby cannot connect to the host.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.