Db2 数据库 HADR 部署实施 17 个疑难问题解答 | 进阶技巧

Db2数据库高可用采用HADR（High Availability Disaster Recovery ）技术，是数据库级别的高可用性数据复制机制，为部分和整个站点故障提供高可用性解决方案。HADR 可以将源数据库（称为主数据库）中数据的修改复制到目标数据库（称为备用数据库）中来防止数据丢失。

但是，如何通过HADR来实现业务需求，对于数据库架构师和管理员来说，比较复杂并存在众多难题。例如：如何提高HADR的同步效率和性能；如何选择HADR同步方式；HADR备机无法访问；HADR接管方式的选择等。  

为了帮助大家更详细了解HADR，社区特别邀请专家撰写了最佳实践文章：《某省级机构 Db2 数据库 HADR 部署实施方案》（点击标题可回顾），同时组织了交流答疑，解答大家在HADR方面的各种疑难问题。以下由专家tongshuai将交流内容梳理汇总，供大家参考。

Q1：主机宕掉了，检查什么，才能衡量是否能强制切换成功？

答：主机宕掉了执行了强制切换，首先就看是切换命令是否提示切换成功，然后再新主库上检查HADR状态：db2pd -d DBNAME -hadr，检查当前数据库角色是否为primary。然后通过业务访问数据库，是否正常连接，是否可以执行增删改查等操作。

Q2：Db2 HADR环境，做 Db2版本升级（10.5 ——> 11.1）时，为减少停机时间，进行primary、standby 交替升级的方法步骤是怎样的？

答：https://www.ibm.com/support/knowledgecenter/zh/SSEPGG_11.1.0/com.ibm.db2.luw.qb.upgrade.doc/doc/t0070029.html ，可以参考这个官方文档。

Q3：1.HADR的典型最佳实践案例？2.切换方式与案例？同步时延，基础环境条件（网络带宽、数据量、交易并发量）？3.如果故障交易从主机切至备机，那同步机制如何变化？以及如何切换后回切？

答：

1、相关实践案例可以参考：http://www.talkwithtrend.com/Article/243929，这个方案。

2、HADR切换方式分为正常切换及强制切换，正常切换适用于主备库均正常情况下进行的主备切换，强制切换适用于主库已经宕库情况下执行强制切换。

3、主库切换至备库后，同步机制不变，后续可以根据需求进行正常主备库切换。

Q4：puresacle集群和HADR能否共存？还是只能独立？我见有些purescale集群也存在HADR?

答：这是两种不同架构，可以单独部署使用，也可以结合使用，没有冲突。

Q5：Db2 10.1 HADR 动态添加辅助备机，参数无法动态生效？

数据库版本:db2 10.1

操作系统版本:SUSE Linux Enterprise Server 11 SP4 (x86_64)

背景：目前是主备模式，采用NEARSYNC模式，现在想动态添加一个辅助备机，发现在主库添加动态参数HADR_TARGET_LIST 时被要求重启，据官方说明是不用重启的，求各位大佬解惑。

答：先connect to 连接到数据库再执行命令修改参数。

Q6：HADR主备自动切换问题？

对于业务来说，最重要的是在故障时能自动切换备机，从而不影响业务中断。

答：这个要考虑配置TSAMP。

Q7：HADR备库上发现有不可以用表后如何处理成正常？

在搭建完毕HADR备库后，有时候HADR主库进行了不记录日志操作，导致HADR备库对应的表不可用，这个时候不知道如果把HADR备库对应的表处理成正常的。重新搭建是可以，是否有其它好一点的办法呢？

答：像这种情况处理的话建议在主库中将表数据导出做个备份，然后将表drop掉，然后重新创建，再重新导入。

Q8：1.Db2里面怎么实现多租户完全隔离各个业务系统，另外可以针对每个租户动态划分内心吗？2.Db2怎么跟HANA实现转换 ？

答：Db2没有多租户概念，和多租户概念类似的是多数据库，每个数据库可以单独配置内存参数。Db2和hana分属不同数据库 这个需要相关的工具去实现的。

Q9：Db2 HADR 几种同步模式的在生产系统上的应用场景？企业如何选择HADR同步方式？

答：分几种情况：

一般的生产系统选择异步方式即可，既能保证数据安全性，又能减少HADR对主机的影响，一般银行的系统都是选择异步方式。

对于生产系统对性能要求极高的情况下，可以采用异步或超级异步模式，这个对主机性能基本没有影响，如券商的交易系统。

对于异地的灾备系统，建议采用超级异步模式，以避免广域网的不利影响。

Q10：HADR在什么情况下会无法切换，应该怎么解决？

答：HADR切换分为正常切换和强制切换。

在主备库均正常切HADR状态是peer的情况下进行主备切换就是正常切换。这样的切换一般是计划切换。

强制切换一般是由于主库异常宕掉，无法提供正常服务的情况进行切换，强制切换就是将原来的备库强制接管为主库提供服务，以保证业务。

Q11：HADR+HACMP／SUSE HA ；HADR环境升级？

目前需要对AIX和SUSE环境的单机Db2环境进行容灾搭建，有以下几个问题请教专家：

操作系统：AIX 7.1/SUSE 11 ， db2 v10.5fp9

在配置了虚拟IP／ACR 的 HADR环境中，HACMP／SUSE HA 的切换如何做到不影响 HADR ？

源端的架构为主库+历史库，通过CDC同步数据，建议如何对这套系统做容灾？要考虑切换。

对HADR环境做db2版本升级（10.5-11.1）时，如何做才能保证停机时间最短？是否备库一定要做restore？

答：

1、你这里的hacmp是否配置HADR一齐的，如果是那只需切换HADR就可以，hacmp可以自动切换。如果不是配合使用的，那就要考虑如何配置hacmp而不影响HADR了。

2、cdc也是Db2的一种容灾方式，如果目前运行正常，那可以不用改动。如果觉得这种方式满足不了需求那可以考虑改为HADR。

3、在HADR环境中可以考虑主备库交替升级的方式升级数据库，这样可以保持最少停库时间。

Q12：Db2如何实现对表级的数据库查询，变更做记录？想实现对库中某个表的访问记录，包含查询，插入，修改等

答：如果您的需求只是 “对某一张表的DML语句、SELECT语句做记录” 的话，有下面几种方案：

1. 开审计记录

2. 使用语句的 snapshot 快照接口筛选访问该表的 sql语句

3. 创建个 SQL语句的事件监视器， “CREATE EVENT MONITOR stmt1.env FOR STATEMENTS WHERE ....” 然后，从事件监视器的记录中搜索该表的sql语句。为了减少事件监视器记录的数据量和潜在的性能损耗，可以针对访问该表的应用程序名创建事件监视器。

4. 或者，使用 DB2v9.7以后提供的轻量级表函数 MON_GET_PKG_CACHE_STMT 直接从监视内存中检索访问该表的动态和静态sql 语句。

我比较喜欢第 4 种方法，将包含特定表的sql 语句抓到监控服务器，对数据库服务器的压力小。审计、事件监视器在数据库服务器上记录，会影响性能，不太喜欢。

Q13：我部打算部署Db2 purescale ,主中心采取x86的两台物理机部署purescale，灾备采取虚拟机部署，主备通过HADR部署连接，请问这种技术可行吗？推荐这么做吗？

答：这样是可以的，Db2支持hadr+purescale的，论坛也有相关的部署文档，你可以参考一下。

Q14：如何设置Db2 HADR 超时参数？

hadr_timeout 、hadr_peer_window 、DB2_HADR_PEER_WAIT_LIMIT 应该如何设置？

答：一般超时参数值在120到300之间，也就是2到5分钟之间，具体设置多少看实际要求，如果要保证数据一致，可以设置高一点，比如240或者300，但是这个会对事务性能有影响。

如果要求对事务不能有太大的影响那就设置低一点，比如60或者120。我们一般是设置为120，也就是2分钟。

Q15：HADR清理大量历史数据的问题？

HADR 架构，由于系统最初设计和规划，并没有合理及时的数据清理策略，在数据量达到一定程度后，想要进行数据清理，但是发现要清理的数据已经上T ，在HADR架构下，主机清理掉大量数据，那么备机要重放大量的日志，尤其是当主机使用大量并发删除时，备机重放日志明显和主机日志差值较大。此时高可用方案不能达到真正的""灾难时高可用""，因为如果主备切换后，日志replay就需要一个长的时间。如何给出一个方案，能达到高效清理，并又达到切换时延短。

答：一般在HADR环境里，主备库的性能都一样的，因此很少有主机产生日志速度超过备库重放日志速度的情况。不过如果想你担心的那样，主库大量删除数据，备库有可能存在日志重放速度跟不上的情况。那建议：

1.如果是要删除整张表，那用truncate清空表的方式，这种方式速度快，产生日志量少。

2.如果是删除表中的历史数据，那建议在业务繁忙时候小并发来操作，而可以在业务不繁忙时段，比如凌晨使用大并发来删除。

Q16：有哪些方法可以避免或者降低主库大量写入带来的同步延迟问题？

答：在Db2 HADR高可用环境中，影响同步性能的最大瓶颈一般是在网络，所以要想降低同步延迟，优先做的就是优化主备库的同步网络，优化方法建议：

1、可以使用专用的网络来配置HADR环境主备库的连接。

2、如果主机有多网卡的话可以考虑绑定多网卡，充分利用多张网卡的速度来提高网络性能。

另外在数据库层面可以考虑启用日志假脱机。

日志假脱机：如果主库产生事务日志比备库重做日志的速度快，则有可能会导致备库中的重做日志缓冲池满，从而导致备库无法再接收主库传过来的日志，导致事务阻塞。如果启用日志假脱机，则在备库的重做日志缓冲池满之后，主库传送过来的日志暂时保存在备库磁盘中，等缓冲池中的日志重做完成后再将暂存在磁盘的日志读取到缓冲池中进行重做。这样就不会导致主库事务阻塞。

将数据库配置参数‘hadr_spool_limit’配置为非0.

Q17：大数据量的核心OLTP库，如何快速删除大表？

HADR的10.1版本中，一主一备的环境下，power 750小机,2T的内存，大约10T的数据库，核心业务库，7*24小时有业务，有张大表，数据量2t左右，

不能drop 的方式（业务特殊），在这样的环境下，如何快速删除这个表里的数据？

答：“核心业务 OLTP”，“7x24”，“2T/10T” 等于说一个OLTP的核心业务 20%的数据（2TB）全在一张普通表上，这张表大概率是记录业务日志的，且没有进行分区和历史数据归档。

糟糕的系统设计问题导致的后期运维难题！！！如果这张表不能离线脱机维护，那只能在业务空闲期间，小批量地在线delete，分批在线删除历史数据，对新数据入表影响不大！HADR需要根据测试实际情况设置足够大的 DB2_HADR_BUF_SIZE 或者临时启用 hadr log spooling！如果这张表有离线运维窗口的话，创建该表的分区表 T1，然后，用“rename table”语句对表名进行互换。当然，这种不大适合你们的场景。

以上内容由 tongshuai、atpeace331、yhl71等数据库专家和社区高手参与分享

文章地址：

http://www.talkwithtrend.com/Article/244025

推荐阅读：

欢迎点击阅读原文关注社区  “高可用” 技术主题 ，将会不断更新优质资料、文章，您也可以前往提出疑难问题，与同行切磋交流。

下载 twt 社区客户端 APP

与更多同行在一起

高手随时解答你的疑难问题

轻松订阅各领域技术主题

浏览下载最新文章资料

长按识别二维码即可下载

或到应用商店搜索“twt”

长按二维码关注公众号

*本公众号所发布内容仅代表作者观点，不代表社区立场