DB2 parameter Master-slave configuration parameters

Master/Slave Parameters:

Modified Date:ntpdate asia.pool.ntp.org

Master/Slave Configuration communication port:

Db2h_erpinst1 70000/tcp

Main Library configuration:

DB2 Update DB CFG for erpdb using Hadr_local_host PrimaryNode-1

#本地服务器主机

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

#远程服务器名称

DB2 Update DB CFG for erpdb using Hadr_remote_inst db2inst1

# The HADR instance name of the remote server

DB2 Update DB CFG for erpdb using Logindexbuild on

#索引设置 (Set the logindexbuild Database configuration parameter toon to ensure that the complete information is logged for the creation, re-creation, and reassembly of the index. Although, this means that indexing on the primary system may take longer and more log space, but during the HADR log replay, the index is rebuilt on the standby system and the index is still available when failover occurs)

DB2 Update DB CFG for erpdb using Indexrec restart

#索引重建 ( the time it takes to restart the database will be longer because the index is re-created, but normal processing will not be affected once the database is back online )

DB2 Update DB CFG for erpdb using Hadr_syncmode SUPERASYNC # Super Async

# The HADR synchronization of the log write operation in peer state, Determining how the primary log write operation synchronizes with the standby log write operation when the system is in a peer state

1. Sync sync mode

This approach provides the strongest protection against transaction loss, but the transaction response time is longer. in this way, log writes are considered successful only if the log has been written to the journal file on the primary database, and the primary database has received an answer from the standby database to determine that the log has also been written to the log file on the standby. Ensure that log data is stored in both places. (The repository write log is successful, the data master and slave libraries exist, the most secure transaction time is long )

2, nearsync   near-synchronous mode

this way The protection provided to prevent transaction loss is slightly less than that, however, compared to the SYNC mode, the Nearsync mode . ( )

3. Async Async Mode

TheASYNC mode has a shorter transaction response time than the SYNC and Nearsync methods, but if the primary database fails, the likelihood of a transaction failure is greater. 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 the record has been passed to the TCP layer of the Master System host. Because the primary system does not wait for an answer from the standby system, when the transaction is still in the process of being passed in to the standby system, it may be assumed that the transaction has been implemented (the log is written to the primary and passed to the TCP layer, succeeds, does not wait for the standby to be answered, and easily loses the transaction )

4. SUPERASYNC Super Async mode

This approach has the shortest transaction response time , but if the primary system fails, the likelihood of a transaction failure is also greatest . This is useful when you do not want transactions to be blocked due to network outages or congestion or to experience longer response times. in this way, the HADR pair will never be in a peer state or disconnected 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 an answer from the standby system, when the transaction is still in the process of being passed in to the standby system, it may be assumed that the transaction has been implemented (the transaction time is minimal, the log is written to the main library successfully, and no standby is waiting for a repository answer )

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

( reads on standby feature (HADR RoS) supports read-only application access to the standby database set to take effect when the fallback library must be restarted, This is only possible if the reads on standby feature is enabled. With this feature, the read/write application can access the HADR primary database, and read-only applications can access the primary or standby database. This allows you to offload some read-only workloads running on the primary database to the standby database. Applications that connect to the standby database do not affect the availability of the standby database when the failover occurs)

From library:

Db2set Db2_hadr_ros=on

Db2set Db2_standby_iso=ur

Start master/Slave database (first boot):

From library:

Db2start

DB2 start HADR on DB erpdb as standby

Main Library:

Db2start

DB2 start HADR on DB erpdb as primary

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

This article is from the "arvin_0213" blog, make sure to keep this source http://arvin0213.blog.51cto.com/2455782/1929596

DB2 parameter Master-slave configuration parameters