某省级机构 Db2 数据库 HADR 部署实施方案
目录
1、实施背景
2、建设需求
3、方案概述
4、HADR实施方案
4.1 环境要求（HADR）
4.1.1 操作系统
4.1.2 网络策略
4.1.3 文件系统要求
4.1.3 数据库要求
4.2 HADR环境搭建
4.2.1 standby端HADR环境准备
4.2.2 standby端数据库恢复
4.2.3 配置数据库参数
4.2.4 启停数据库及HADR服务
4.2.5 监控HADR
4.3 同步测试
4.4 应急切换
4.4.1 正常切换
4.4.2 强制切换
5.HADR常见问题
1、实施背景
某省机关单位下辖10多个地市的部门系统使用的DB2数据库，每个地市的应用系统及数据库均部署在本地。而此前各地市数据库均未部署容灾系统，因此就会有业务中断的风险。
目前为了建立健全面向全省系统的容灾系统运维体系，从组织、流程、资源配置等各个方面充分保障，逐步建立起容灾系统运维体系，以充分保障全省系统的业务连续性。以此为前提，对各地市系统进行灾备环境的搭建。
2.建设需求
目前省单位及市单位所部署的Db2数据库版本均为 V9.7。此次容灾环境的备机全部部署在省单位的容灾机房中，各地市单位通过网络专线连接到容灾机房中。容灾系统规划图如下：
容灾建设要求，主库数据必须及时传到备库中，主备库数据差异不超过10分钟。
主库发生故障无法提供服务后，备库需要在十分钟内完成接管。
3、方案概述
根据客户的需求，此次容灾环境将采用DB2的容灾高可用方案采用HADR技术进行部署。
Db2的（High Availability Disaster Recovery, HADR）是数据库级别的高可用性数据复制机制，当主数据库中发生事务操作时，会同时将日志文件通过TCP/IP协议传送到备用数据库服务器，然后备用数据库对接受到的日志文件进行重放（Replay），从而保持与主数据库的一致性。
当主数据库发生故障时，备用数据库服务器可以接管主数据库服务器的事务处理。此时，备用数据库服务器作为新的主数据库服务器进行数据库的读写操作。当原来的主数据库服务器被修复后，又可以作为新的备用数据库服务器加入HADR。通过这种机制，Db2 UDB实现了数据库的灾难恢复和高可用性，最大限度的避免了数据丢失。下图为Db2 HADR的工作原理图：
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 文件系统要求
以下文件系统规划均与主库保持一致。
4.1.4 数据库要求
对全省各地市数据库数据量进行重新统计收集。
在配置HADR前，primary端和standby端需要准备的资源如下：
需要系统为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” 技术主题 ，将会不断更新优质资料、文章，您也可以前往提出疑难问题，与同行切磋交流。
下载 twt 社区客户端 APP
与更多同行在一起
高手随时解答你的疑难问题
轻松订阅各领域技术主题
浏览下载最新文章资料
长按识别二维码即可下载
或到应用商店搜索“twt”
*本公众号所发布内容仅代表作者观点，不代表社区立场