某省高级法院Db2数据库HADR部署实施方案

字数 9539阅读 8821评论 8赞 15

1、实施背景	3
2、建设需求	3
3、方案概述	4
4、HADR实施方案	5
4.1 环境要求（HADR）	5
4.1.1 操作系统	5
4.1.2 网络策略	5
4.1.3 文件系统要求	5
4.1.3 数据库要求	5
4.2 HADR环境搭建	6
4.2.1  standby端HADR环境准备	6
4.2.2  standby端数据库恢复	9
4.2.3 配置数据库参数	9
4.2.4 启停数据库及HADR服务	11
4.2.5 监控HADR	12
4.3 同步测试	13
4.4 应急切换	13
4.4.1 正常切换	13
4.4.2 强制切换	14
5.HADR常见问题	14

# 1、实施背景
某省高级法院下辖15个地市的中级法院的法院系统使用的DB2数据库，每个地市的应用系统及数据库均部署在本地。而此前各地市中院的数据库均未部署容灾系统，因此就会有业务中断的风险。
目前为了建立健全面向全省法院系统的容灾系统运维体系，从组织、流程、资源配置等各个方面充分保障，逐步建立起容灾系统运维体系，以充分保障全省法院系统的业务连续性。以此为前提，对全省各地市系统进行灾备环境的搭建。

# 2.建设需求
目前省高院及市中院所部署的Db2数据库版本均为 V9.7。此次容灾环境的备机全部部署在省高院的容灾机房中，各地市中院通过网络专线连接到容灾机房中。容灾系统规划图如下：
 ![ex6c8ai8cti](/home/attachment/201904/02/935507_155418873091711.jpg)

容灾建设要求，主库数据必须及时传到备库中，主备库数据差异不超过10分钟。
主库发生故障无法提供服务后，备库需要在十分钟内完成接管。
# 3、方案概述
根据客户的需求，此次容灾环境将采用DB2的容灾高可用方案采用HADR技术进行部署。
Db2的（High Availability Disaster Recovery, HADR）是数据库级别的高可用性数据复制机制，当主数据库中发生事务操作时，会同时将日志文件通过TCP/IP协议传送到备用数据库服务器，然后备用数据库对接受到的日志文件进行重放（Replay），从而保持与主数据库的一致性。
当主数据库发生故障时，备用数据库服务器可以接管主数据库服务器的事务处理。此时，备用数据库服务器作为新的主数据库服务器进行数据库的读写操作。当原来的主数据库服务器被修复后，又可以作为新的备用数据库服务器加入HADR。通过这种机制，Db2 UDB实现了数据库的灾难恢复和高可用性，最大限度的避免了数据丢失。下图为Db2 HADR的工作原理图：
![667tizi2n33](/home/attachment/201904/02/935507_155418876785337.gif)

HADR实施的要求：
HADR是通过日志前滚方式的方式来把primary端的数据同步到standby 端的。因此数据库的日志模式要求是归档日志模式，数据库的操作要求是记录日志的。不记录日志的操作不能同步到standby端。如load操作，not logged initialize 的操作都不能同步到standby端。此外实例参数、数据库参数的修改操作也不会进行同步，但可以在主备库同时修改参数。在做HADR之前，需要检查数据库的归档方式，业务是否使用不记录日志的操作等。
配置完HADR参数后需要重启实例才能生效。。
# 4、HADR实施方案
##4.1 环境要求（HADR）
###4.1.1 操作系统
灾备环境主机操作系统应与各地市操作系统相同。

###4.1.2 网络策略
 双向开通主备库的数据库端口50000、HADR端口50010、50011。
### 4.1.3 文件系统要求
以下文件系统规划均与主库保持一致。
![sg288jx5r5k](/home/attachment/201904/02/935507_155418912318688.jpg)

### 4.1.4 数据库要求
对全省各地市数据库数据量进行重新统计收集。
在配置HADR前，primary端和standby端需要准备的资源如下：
![xc6bl9lvn3](/home/attachment/201904/02/935507_155418915974218.jpg)

需要系统为primary分配一个50010端口号用于HADR。为standby端分配2个端口号，分别用于数据库服务（SVCENAME）的50000端口以及HADR的50011端口。
数据库的磁盘空间至少是DB2软件安装的磁盘需求，一般5G可够，加上primary端的现有数据库的大小。依据数据的增长情况可为DB2预留更多的空间。
## 4.2 HADR环境搭建
### 4.2.1  standby端HADR环境准备
在备库中安装DB2 V9.7版本软件（与主库版本保持一致），使用root用户安装。
1.解压缩安装介质：
```
#gzip –d db2exc_971_LNX_x86.tar.gz
# tar -xvf db2exc_971_LNX_x86.tar
```
2.安装db2软件：
```
#cd server
#./db2_install
```
3.注册license
/opt/IBM/db2/V8.1/adm/db2licm –a  /[证书名]
/opt/IBM/db2/V8.1/adm/db2licm -l

创建实例用户组与实例用户名。防护用户组和用户名。这里一般与primary端保持一致。
```
# groupadd -g 501 db2iadm
# groupadd -g 502 db2fadm
# useradd -g db2iadm -u 1001 -d /db2home/db2inst1 -m -s /bin/sh db2inst1
# useradd -g db2fadm -u 1002 -d /home/db2fenc -m -s /bin/sh db2fenc
```
设置实例密码：
```
#passwd db2inst1
#passwd db2fenc
```

创建实例并配置参数，参数需要与主库保持一致。
1.创建Db2的实例，使用root用户
 /opt/ibm/db2/V9.7/instance/db2icrt -u db2fenc db2inst1
2.查询当前主机的所有实例
/opt/ibm/db2/V9.7/instance/db2ilist

实例创建完成后则需要配置相关参数，所配置的参数值需要与主库保持一致。
1.配置注册变量参数
db2set Db2_HADR_BUF_SIZE= 25600
db2set Db2_HADR_PEER_WAIT_LIMIT=120  
db2set Db2COMM=TCPIP 
db2set Db2_HADR_ROS=ON
db2set Db2COUNTRY=86
db2set Db2CODEPAGE=1386

参数说明：
Db2_HADR_BUF_SIZE  备机接收事务日志的缓冲池大小，一般配置为主库日志缓冲池大小的两倍
Db2_HADR_PEER_WAIT_LIMIT  主备库传输日志若被堵塞、则HADR处于断开连接的对等状态的时间。
Db2_HADR_ROS=ON  指定standby端数据库为READ ONLY STANDBY状态，则开启备库只读功能，这样应用就可以连接到备库进行查询操作，减轻主库的压力。
Db2_STANDBY_ISO=UR 指定standby 端数据库的隔离级别为UR。
 
配置实例参数，相关参数值需要与主库的实例参数值保持一致。
2.配置实例参数
db2 update dbm cfg using SVCENAME 50000
db2 update dbm cfg using DFT_MON_BUFPOOL on DFT_MON_LOCK on DFT_MON_SORT on DFT_MON_STMT on DFT_MON_TABLE on DFT_MON_UOW on HEALTH_MON off dft_mon_timestamp on

至此，standby端的db2安装与实例配置完毕，接下来则需要在standby端进行数据库的恢复。

### 4.2.2  standby端数据库恢复
由客户对主库进行一次数据库完全备份。备份完成后将备份介质传到备机的临时目录db2tmp下并用chown更改备份介质的属主。然后就可在备库进行数据库恢复，因备库中的文件系统规划与主库保持一致，因此无需进行重定向恢复。
1.启动实例
db2start

2.进行数据库恢复
db2 restore database FYDB from /db2tmp taken at 20190309233001  ON /db2data into FYDB

3.备份完成后检查实例中的数据库
db2 list db directory

4.检查数据库状态
db2 ROLLFORWARD DB  FYDB  QUERY STATUS
恢复完毕后数据库处于前滚暂挂状态。对于HADR的standby端来说，不需要做前滚操作。

### 4.2.3 配置数据库参数
standby端数据库恢复接下来需要配置数据库参数。因为standby端数据库是通过primary端的备份来恢复的，备库的参数与主库是一致，因此只需修改与HADR相关的参数即可，其它参数可以不修改。主备库的HADR相关参数都需要修改。
配置primary和standby端的HADR参数
1.配置primary端数据库参数
db2 "UPDATE DB CFG FOR FYDB USING HADR_LOCAL_HOST 146.76.1.10"
db2 "UPDATE DB CFG FOR FYDB USING HADR_LOCAL_SVC 50010"
db2 "UPDATE DB CFG FOR FYDB USING HADR_REMOTE_HOST 146.231.1.20 "
db2 "UPDATE DB CFG FOR FYDB USING HADR_REMOTE_SVC 50011      "
db2 "UPDATE DB CFG FOR FYDB USING HADR_REMOTE_INST db2inst1       "
db2 "UPDATE DB CFG FOR FYDB USING HADR_SYNCMODE ASYNC "
db2 "UPDATE DB CFG FOR FYDB USING HADR_TIMEOUT 120"
db2 "UPDATE DB CFG FOR SAMPLE USING LOGINDEXBUILD ON"
db2 "UPDATE DB CFG FOR SAMPLE USING INDEXREC RESTART"

2.配置standby端数据库参数
db2 "UPDATE DB CFG FOR FYDB USING HADR_LOCAL_HOST 146.231.1.20"
db2 "UPDATE DB CFG FOR FYDB USING HADR_LOCAL_SVC 50011"
db2 "UPDATE DB CFG FOR FYDB USING HADR_REMOTE_HOST 146.76.1.10 "
db2 "UPDATE DB CFG FOR FYDB USING HADR_REMOTE_SVC 50010"
db2 "UPDATE DB CFG FOR FYDB USING HADR_REMOTE_INST db2inst1"
db2 "UPDATE DB CFG FOR FYDB USING HADR_SYNCMODE ASYNC "        
db2 "UPDATE DB CFG FOR FYDB USING HADR_TIMEOUT 120"
db2 "UPDATE DB CFG FOR SAMPLE USING LOGINDEXBUILD ON"
db2 "UPDATE DB CFG FOR SAMPLE USING INDEXREC RESTART"

参数说明
HADR_LOCAL_HOST  --本机IP或网络名
HADR_LOCAL_SVC   --本机HADR端口号
HADR_REMOTE_HOST  --HADR对端的机器IP或网络名
HADR_REMOTE_SVC   -- HADR对端的HADR端口号
HADR_REMOTE_INST   -- HADR对端的实例名
HADR_TIMEOUT  -- 主备机连接超时时间，因为这里的主备机为远程连接，因此设置大一些。
HADR_SYNCMODE   --HADR的日志同步模式，因为是远程连接方式，因此这里采用ASYNC模式。
LOGINDEXBUILD  --此参数指定是否要记录索引创建、重新创建或重组操作，以便可以在执行 DB2® 前滚操作或者高可用性灾难恢复 (HADR) 日志重放过程中重构索引。
至此主备库HADR相关的参数均已配置完成，注意HADR_LOCAL_SVC参数与HADR_REMOTE_SVC参数分别是本地与对端的端口。HADR_LOCAL_HOST参数与HADR_REMOTE_HOST参数分别是本地与对端的主机名或IP地址。
另外注意的是，在DB2 V9.7及之前的版本中，HADR相关参数需要重启数据库后才生效，在DB2 V10.1及以后的版本这些参数不需要重启数据库，只需直接启动HADR即可让参数生效，这样可以节省重启数据库这个步骤。

### 4.2.4 启停数据库及HADR服务

由于这里的DB2为V9.7版本，要使HADR参数生效需要重启数据库。主备库重启数据的都一样，区别在于standby端启动实例后无需激活数据库。
重启数据库
1.关停primary端数据库
db2 force applications all
db2 deactivate db FYDB
db2stop force

2.启动primary端数据库
db2start
db2 activate db FYDB

3.检查数据库的diag日志
db2diag

4.关停standby端数据库
db2stop force

5.启动standby端数据
db2start

主备库数据库重启后即可启动HADR服务，重启步骤为：先启动standby端再启动primary端。
这里有个地方需要注意，备库的恢复和主库的备份之间相隔有一段时间，这期间可能会产生大量的归档日志，在启动HADR后需要花费大量的时间来同步这些日志，可以提前将这些归档日志传送到备库的事务日志目录中，这样启动HADR后备库就可以直接复用本地的日志文件，这样可以节省大量的时间。
1.启动Standby端HADR
db2 start hadr on database FYDB  as standby
2.启动primary端HADR
db2 start hadr on  database  FYDB  as primary
3.检查HADR状态，主备库均可执行相同的命令
db2pd -d FYDB -hadr

### 4.2.5 监控HADR
HADR运行后，对HADR的监控就成为了一个重要的工作，通过db2pd工具可以监控当前的HADR情况。命令如下
db2pd -d FYDB  -hadr
监控项比较多，下面对重点关注的监控项进行说明：
HADR_ROLE   HADR的角色，主库为：PRIMARY，备库则为：STANDBY
HADR_STATE  HADR状态，PEER则为正常状态，
HADR_CONNECT_STATUS  HADR主备库间的连接状态，CONNECTED为正常状态
PRIMARY_LOG_FILE,PAGE,POS  主库中当前的事务日志文件号、页号、偏移量，这三个参数可以表示主库中当前事务日志的位置。
STANDBY_LOG_FILE,PAGE,POS  备库中当前接收的事务日志文件号、页号、偏移量，这三个参数可以表示主库中当前事务日志的位置
HADR_LOG_GAP   主备库间事务日志大小差量，单位为字节，备库接收的日志偏移量减去主库的日志偏移量。如果这个数值太大，说明了备库接收的日志与主库生成的日志差异比较大，一般是因为网络慢导致，这个需要重点排查网络性能。
STANDBY_REPLAY_LOG_FILE,PAGE,POS  备库中正常重放的日志文件号、页号、偏移量，
STANDBY_RECV_REPLAY_GAP  备用日志接收位置与备用日志重播位置之间的平均差，单位为字节。如果这个值长时间的差异比较大，说明备库的重放性能比较差，这里就要考虑是不是备库的主机性能不足。
STANDBY_RECV_BUF_PERCENT  备库日志重放缓冲池的使用率，这个值一般比较低，如果长时间数值都比较高的话，说明备库的重放性能比较差，这里就要考虑是不是备库的主机性能不足。
上面就是db2pd工具监控HADR需要重点关注的监控项，关于其它的监控项可以参考IBM官方文档。另外也可以查询数据库的编目视图“SYSIBMADM. SNAPHADR”来获取相关的监控项数值。

## 4.3 同步测试
 HADR启动后对同步效果进行测试，分别在主库执行进行DDL、DML、索引、自增列操作，然后监控HADR状态，若为peer，则登录到备库中查询相关的执行结果。
## 4.4 应急切换
首先介绍HADR运行过程中可能处于的状态：
RemoteCatchupPending: 备机完成了对本地日志的前滚，尝试与主机建立通讯以获得后续的日志文件。
RemoteCatchup: 备机已经与主机成功建立了连接并正在接受新的日志用于前滚。
NearlyPeer: 备机已经完成了所有日志文件的前滚操作，处于等待主机完成暂挂日志写入和读取磁盘上日志进行处理的操作。
Peer: 根据HADR的同步模式选择，备机和主机处于对等状态.

### 4.4.1 正常切换
当primary发生了故障时，或者其他原因需要暂时切换到standby上，把原来的primary变为standby，把原来standby变为primary。
进行接管时，需要先保证primary和standby HADR处于HADR_STATE = PEER状态。通过db2pd –d FYDB –hadr 检查HADR的状态。如果状态为“peer”，则可以执行主备切换操作，操作如下：
1.在standby端上执行下面切换：
db2 takeover HADR on database FYDB
2.切换完成后检查HADR状态
db2pd -d FYDB -hadr
确保原来的standby变为primary，原来的primary变为standby，同时HADR状态为“peer”。

### 4.4.2 强制切换
如果HADR的状态一直都不能处于PEER状态，或者takeover的时候接管不过来。可以考虑强制接管。但是强制切换有可能由于primary端和standby端的数据不一致而导致primary端一备机的身份加入HADR失败，这是也就不存在高可用性互备了。通讯故障和用户强制切换都将迫使HADR把备机切换成主机，故障修复后。有可能导致两个机器都已primary的模式运行。这时HADR无法保证两端数据一致。也就没有达到灾难互备。具体切换成功与否可以通过db2pd –d FYDB –hadr命令查看原来primary是否成功变为standby。是否一段时间后HADR状态恢复peer。
1.在备库中执行强制切换
db2 takeover HADR on database FYDB by force

2.切换完成后检查HADR状态
db2pd -d FYDB -hadr

# 5.HADR常见问题
针对本方案，我总结了以下几个HADR常见的问题，供大家参考。
一、问：HADR模式应该怎么选择。
答：DB2 HADR同步日志有四种模式：SYNC、NEARSYNC、ASYNC 和 SUPERASYNC，数据安全性从高到低，性能则从低到高。对部署的条件要求也有不同。如果要保证数据的绝对安全，那就选择SYNC，但这个模式一般要求主备机在同机房，HADR的连接网络最好使用专用连接，保证网络不成为性能瓶颈，主备机的性能保证一致。
NEARSYNC，这种模式是主备库同机房最常用的模式，原因是在保证数据安全和保持性能方面可以达到均衡。
ASYNC ，这种模式一般用在主备库同城异地的环境中。当然在不同城但网络性能比较高的环境也可以用这种模式。
SUPERASYNC，这种模式一般用在主备库是不同城环境中，或者多备机环境中。

二、问：部署HADR对主备机有什么要求
答：HADR部署要求主备机架构需要一致，比如都是linux、unix或者AIX，数据库大版本也要一致，小版本最好也保持一致。

三、问：启动HADR遇到“SQL1768N  Unable to start HADR. Reason code = "5"”错误怎么办？
答：这个错误一般是因为HADR端口参数有问题导致，在配置HADR端口参数时记得不要配置为实例参数“svcename”值或者参数值+1，比如实例参数值为：50000，那HADR的端口参数不能配置为“50000”以及“50001”。

四、问：HADR环境有哪些限制
答：HADR目前有以下几个比较重点的限制
1、HADR不支持DPF架构，也就是数据库多分区环境无法部署HADR
2、HADR中不能对备库进行备份，只能备份主库。
3、HADR中只归档主库的日志，备库的日志不归档，备库重放完日志且这些日志文件已在主库中归档成功后会自动删除。
4、HADR主库中的load操作不能再备库中重放，也就是主库中通过load操作插入到表的数据不能同步到备库，因为load不记录日志。如果需要在备库同步通过load操作插入的数据，可以在主库执行load命令时加入 copy yes参数，然后指定一个主备库均可访问的目录，这样备库就可以执行load命令从目录中插入数据到表中。
 5、HADR主库中如果对表启用了‘NOT LOGGED’，则备库中该表会置为无效。此时可以在主库中删除该表且不启用‘NOT LOGGED’。

部署实施 Db2 方案设计 HADR

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！