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

Master-slave parameters:

Modify date:ntpdate asia.pool.ntp.org

Master-slave configuration communication port:

Db2h_erpinst1 70000/tcp

Master library configuration:

Db2 update db cfg for erpdb using hadr_local_host PrimaryNode-1

# Local server host

Db2 update db cfg for erpdb using hadr_local_svc db2h_erpinst1

# Local service name

Db2 update db cfg for erpdb using hadr_remote_host PrimaryNode-2

# remote server host

Db2 update db cfg for erpdb using hadr_remote_svc db2h_erpinst1

# remote server name

Db2 update db cfg for erpdb using hadr_remote_inst db2inst1

# HADR instance name of the remote server

Db2 update db cfg for erpdb using logindexbuild on

# Index Settings (set the logindexbuild database configuration parameter to ON to ensure that complete information is recorded for index creation, recreation, and reorganization. Although this means that index building on the primary system may take longer and more log space, the index will be rebuilt on the standby system during HADR log replay, and the index will still be available in the event of a failover)

Db2 update db cfg for erpdb using indexrec restart

# Index rebuild (then it will take a long time to restart the database due to re-creating the index, but once the database is back online, normal processing will not be affected)

Db2 update db cfg for erpdb using hadr_syncmode SUPERASYNC # Super Asynchronous

# HADR synchronization of log writes in peer-to-peer state to determine how primary log writes are synchronized with standby log writes when the system is in a peer-to-peer state

1. SYNC synchronization mode

This method provides the strongest protection against transaction loss, but the transaction response time is long. In this way, log writes are considered successful only when the log has been written to the log file on the primary database, and the primary database has received a reply from the standby database, and it is determined that the log has also been written to the log file on the standby database. Ensure that log data is stored in both places at the same time. (only when the slave database is written to the log successfully, the data master and slave databases exist at the same time, and the safest transaction time is long)

2. NEARSYNC near-synchronization mode

This approach provides slightly less protection against transaction loss, but the transaction response time in NEARSYNC mode is shorter than that in SYNC mode. In this way, log writes are considered successful only when the log records have been written to the log file on the primary database, and the primary database has received a reply from the standby system, and it is determined that the log has also been written to the primary storage on the standby system. Data loss occurs only when two failures occur at the same time and the target location does not transfer all received log data to non-volatile memory. (only when the slave database is written to the log successfully, the data master and slave database fails at the same time, the data will be lost, and the transaction time will be short)

3. ASYNC asynchronous mode

Compared with SYNC and NEARSYNC, ASYNC has shorter transaction response time, but if the primary database fails, the transaction is more likely to fail. In this way, log writes are considered successful only if the log record has been written to the log file on the primary database and has been passed to the TCP layer of the primary system host. Because the primary system does not wait for a reply from the standby system, when the transaction is still in the process of being passed into the standby system, it may be considered that the transaction has been implemented (the log is written to the master and passed to the tcp layer, successful, without waiting for a reply from the standby database, it is easy to lose the transaction)

4. SUPERASYNC Super Asynchronous Mode

This approach has the shortest transaction response time, but if the main system fails, then the transaction is most likely to fail. This is useful when you do not want transactions to be blocked or experience long response times due to network outages or congestion. In this way, the HADR pair is never in the peer state or disconnected from the peer state. Log writes are considered successful only if the log records have been written to the log file on the primary database. Because the primary system does not wait for a reply from the standby system, when the transaction is still in the process of being passed into the standby system, it may be considered that the transaction has been implemented (the transaction time is the shortest, and the log is written to the primary database successfully. Do not wait for the standby database reply)

From the library configuration:

Db2 update db cfg for erpdb using hadr_local_host PrimaryNode-2

Db2 update db cfg for erpdb using hadr_local_svc db2h_erpinst1

Db2 update db cfg for erpdb using hadr_remote_host PrimaryNode-1

Db2 update db cfg for erpdb using hadr_remote_svc db2h_erpinst1

Db2 update db cfg for erpdb using hadr_remote_inst db2inst1

Db2 update db cfg for erpdb using logindexbuild on

Db2 update db cfg for erpdb using indexrec restart

Db2 update db cfg for erpdb using hadr_syncmode SUPERASYNC

Register variable configuration:

Main library:

Db2set db2_HADR_ROS=ON

Db2set db2_STANDBY_ISO=UR

The reads on standby feature (HADR RoS) enables read-only applications to access the standby database. After setting it, the slave library must be restarted before it takes effect, which is only feasible if the reads on standby feature is enabled. With this feature, read / write applications can access the HADR primary database, and read-only applications can access the primary or standby database. This allows you to unload some read-only workloads running on the primary database to the standby database. Applications that connect to the standby database will not affect the availability of the standby database during failover)

From the library:

Db2set db2_HADR_ROS=ON

Db2set db2_STANDBY_ISO=UR

Start the master-slave database (for the first time):

From the library:

Db2start

Db2 start HADR on db erpdb as standby

Main library:

Db2start

Db2 start HADR on db erpdb as primary

(synchronize master-slave time) yum install ntp-y ntpdate cn.pool.ntp.org

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.