tongshuai
作者tongshuai2019-04-02 15:23
技术支持, 上海新炬网络技术有限公司

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

字数 8851阅读 4505评论 7赞 14

目录

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

ex6c8ai8cti

容灾建设要求,主库数据必须及时传到备库中,主备库数据差异不超过10分钟。
主库发生故障无法提供服务后,备库需要在十分钟内完成接管。

3、方案概述

根据客户的需求,此次容灾环境将采用DB2的容灾高可用方案采用HADR技术进行部署。
Db2的(High Availability Disaster Recovery, HADR)是数据库级别的高可用性数据复制机制,当主数据库中发生事务操作时,会同时将日志文件通过TCP/IP协议传送到备用数据库服务器,然后备用数据库对接受到的日志文件进行重放(Replay),从而保持与主数据库的一致性。
当主数据库发生故障时,备用数据库服务器可以接管主数据库服务器的事务处理。此时,备用数据库服务器作为新的主数据库服务器进行数据库的读写操作。当原来的主数据库服务器被修复后,又可以作为新的备用数据库服务器加入HADR。通过这种机制,Db2 UDB实现了数据库的灾难恢复和高可用性,最大限度的避免了数据丢失。下图为Db2 HADR的工作原理图:
667tizi2n33

667tizi2n33

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

sg288jx5r5k

4.1.4 数据库要求

对全省各地市数据库数据量进行重新统计收集。
在配置HADR前,primary端和standby端需要准备的资源如下:
xc6bl9lvn3

xc6bl9lvn3

需要系统为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’。

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

14

添加新评论7 条评论

#xukaishi系统工程师, 广西集成商
2019-10-30 09:12
感谢分享!
#skysong9999软件开发工程师, cscc
2019-09-25 15:57
太好了
#Hejf技术经理, Ghac
2019-04-26 09:47
感谢分享,不错的资料。
#zsk19872010信息技术经理, 时代
2019-04-08 22:13
好资料,谢谢分享
#冯岩数据库管理员, 银行
2019-04-08 15:00
多谢兄台分享!
#michael1983技术经理, 某证券
2019-04-07 21:06
谢谢分享
#wuwenpin软件开发工程师, 南京
2019-04-03 19:31
感谢分享!
Ctrl+Enter 发表

本文隶属于专栏

最佳实践
不同的领域,都有先行者,实践者,用他们的最佳实践来加速更多企业的建设项目落地。

关于TWT  使用指南  社区专家合作  厂商入驻社区  企业招聘  投诉建议  版权与免责声明  联系我们
© 2019  talkwithtrend — talk with trend,talk with technologist 京ICP备09031017号-30