DB2 purescale集群HADR环境联机升级

1、 DB2 purescale 集群 HADR 环境联机升级 从DB2 V10.5开始，DB2 pureScale集群支持HADR容灾解决方案和联机安装修订包。本文主要通过实际环境操作，介绍如何在DB2 pureScale集群HADR环境滚动联机升级补丁包：升级前所需要做的准备工作，升级步骤，升级检查等。Db2 pureScale集群HADR特性介绍Db2 pureScale功能为数据库提供了本地高可用的集群架构。在本地高可用的基础上，Db2的HADR功能能够满足企业远程灾备的需要。从Db2 V10.5开始，HADR功能与pureScale功能开始结合在一起，共同为数据库提供了本地高可用加远程灾

2、备的解决方案。在pureScale架构里面，多个成员共同为一个数据库服务。每个成员都会记载各自的日志。所以在Db2 pureScale集群架构里面，Db2生成了多个日志流。基于这种多日志流，Db2 HADR功能会去合并日志流，然后重放，从而达到同步的功能。Db2 pureScale集群HADR容灾架构在Db2 pureScale集群HADR容灾架构的体系中，主备站点都是Db2 pureScale集群。对于所有在主集群的成员产生的日志流，备集群会在其中一个成员节点上接受所有的日志流，合并并重放，从而达到同步的目的。图1. Db2 pureScale HADR架构Db2 pureScale集群HA

3、DR功能也能很好的应用pureScale集群的高可用特性。如果主集群的成员出现故障，其他成员节点可以帮助传输日志到备集群，因为存储是共享的，所以所有日志流都是集群内部节点都可见的。如果是备集群的HADR回放节点出现故障，其他健康的成员节点也可以自动接管回放的工作。总之一切都是为了高可用，零宕机。Db2 pureScale集群环境联机修订包升级特性介绍Db2 pureScale集群最大的特点之一就是本地高可用性。无论是意外宕机还是计划的停机维护，pureScale集群都能够通过滚动维护的方式，完成维护工作的同时，保证数据库提供服务不中断。但是对于升级数据库修订包这样的工作，因为是对集群本身进行维

4、护，就需要停止整个集群。如果数据库对服务可用性要求特别高，缺少升级的时间窗口，那么修订包的升级就会成为企业很大的难题。Db2 pureScale集群环境联机修订包升级从Db2 V10.5开始，pureScale集群管理引入了新的功能：联机升级修订包。首先需要了解的是Db2为了做到这一点，在Db2 发行版里面引入了体系结构级别和代码级别这两个概念。联机修订包的升级就是关于这两个级别的升级。在 Db2 pureScale 实例中，所有成员和 CF 都在同一体系结构级别运行，该级别称为当前有效体系结构级别 (CEAL)。此外，所有成员和 CF 都在同一代码级别运行，该级别称为当前有效代码级别 (CE

5、AL)。Db2 pureScale实例的升级，就是升级和关注体系结构级别，代码级别，当前有效体系结构级别和当前有效代码级别。只有落实了当前有效体系结构级别和当前有效代码级别已经升级到了预期级别，修订包的升级才算最终成功。检查实例各项级别使用db2pd工具可以查看当前实例的各项级别。如下面的清单所示：清单 1. 检查Db2 pureScale实例修订包级别在这个案例里面，当前Db2 pureScale实例是一个2+2的结构。两个member和两个CF的级别信息都同时反映了出来。在这个输出里面，体系结构级别（Architecture Level），代码级别（Code Level），当前有效体系结构

6、级别（CEAL）和当前有效代码级别（CECL）都是“V:10 R:5 M:0 F:0 I:0”，也就是10.5.0.0，是GA版本。Db2 pureScale集群HADR环境联机修订包升级Db2 pureScale集群HADR环境相对要更复杂一些。因为牵扯到同步的问题，新的修订包会兼容老的修订包产生的日志，但是反之则不一定。所以在HADR环境，用户需要在先完成HADR备站点的升级，再完成HADR主站点的升级。实战升级环境描述本次案例将介绍如何在Db2 pureScale集群HADR环境，联机升级修订包。本次实战环境是一套配置了HADR远程灾备的pureScale集群环境。有A B两个主备站点。

7、每个站点都是一套2+2的pureScale集群。 A站点主机分别是siteam1，siteam2，siteaf1和siteaf2。其中siteam1和siteam2是成员节点M0和M1，siteaf1和siteaf2是CF节点。与此对应的，B站点主机分别是sitebm1，sitebm2，sitebf1和sitebf2。其中sitebm1和sitebm2是成员节点M0和M1，siteaf1和siteaf2是CF节点。在实战过程中，A站点是主站点，应用一直在跑。B站点是备站点，一种通过HADR功能接受和回放日志，保持同步状态。这套环境原先安装的是Db2 V10.5的GA版本，将会被升级到Db2 V

8、10.5的FP1，也就是修订包1.实战过程中将验证升级的步骤，验证每一步的集群状态，HADR功能所受的影响，应用所受的影响等。升级补丁包前的准备工作在升级补丁包之前，需要确认系统是否满足修订包的升级。Db2在安装包里面提供了db2prereqcheck工具，可以用来检查当前系统是否满足安装要求。清单 2. 检查是否满足安装需求其中选项-i是检查最新的版本的要求，-p是检查使用到pureScale集群所需要的需求。如果检查结果中没有报错，则说明当前系统满足安装需求。如果有错误信息，一定要先解决的这些问题之后，才可以继续安装。系统需求确认完毕后，还需要考虑一下磁盘空间问题。因为Db2 pureSc

9、ale环境安装修订包并不是覆盖安装，而是需要先安装到一个单独的位置，升级完成后才可以删除以前的修订包。而安装的修订包的大小需要超过3个多G。所以安装目录一定要保证空余4G以上。最后检查当前集群状态，准备升级方案。升级Db2 pureScale集群HADR环境升级Db2 pureScale集群HADR环境的步骤可以初略分为四步: 滚动升级备集群节点, 滚动升级主集群节点, 备集群升级提交和主集群升级提交.滚动升级备集群备集群的滚动升级是指在尽量减少对HADR正常同步功能的影响的情况下,将备集群的所有节点的体系结构级别（Architecture Level），代码级别（Code Level）更新到

10、目标版本。升级之前，首先查看实例状态和HADR的状态是否正常。清单 3. 查看实例状态清单 4. 查看HADR状态检查结果中，HADR状态正常，处于PEER状态。其中主集群有两个member节点，分别是siteam1和siteam2，备集群的sitebm1节点是重放节点，负责接收主集群两个节点的日志流，合并并在当前节点重放。备集群的sitebm2处于空闲状态。清单 5. 查看实例级别备集群四个节点的所有级别都是10.5.0.0版本。本次实战的目标是升级到10.5.0.1版本。首先开始升级备集群的Secondary CF节点。清单 6. 更新secondary cf节点候需要选择一个不同的路径。

11、这里选择的新安装路径是/opt/IBM/db2/V10.5FP1。安装工具检测到目标修订包的体系结构级别（Architecture Level），代码级别（Code Level）都是10.5.0.1。修订包安装的过程中还检测了TSA和GPFS的当前版本和目标版本。其中TSA的当前版本和目标版本都是3.2.2.5。GPFS的当前版本和目标版本都是3.5.0.7。所以都不需要升级。在升级节点的过程中，这个节点的实例将会被重启并修改配置。这是非常重要的一点。Db2 pureScale修订包的联机升级是滚动式的联机。当前被维护的节点实例会关闭，但是得益于pureScale集群的高可用性，数据库的服务不

12、会因为单节点当机中断，所以整个集群是联机的。清单 7. 在更新CF的过程中，CF会被停掉清单 8. 安装完成后，CF会被重启现在再来查看一下实例的级别。清单 9. 查看实例级别从db2pd的输出里面可以看到，节点128磁盘上的的体系结构级别（Architecture Level），代码级别（Code Level）都是10.5.0.1。该CF节点已经安装介质已经升级成功。在此过程中，HADR一直正常工作，不受影响。两个成员节点都处于同步状态。清单 10. 查看HADR状态下面开始更新成员1节点。成员0节点是回放节点，1节点是空闲节点。现在先升级非回放节点。清单 11. 更新member 1节点（

13、非回放节点）升级成员节点的过程中，数据库实例也会被重启。重启完成后，集群还是正常状态。清单 12. 查看实例状态因为这个是非回放节点，所以不会影响HADR功能的正常工作。清单 13. 查看HADR状态现在再次查看实例级别，观察升级成员与升级CF之间的区别。清单 14. 查看实例级别在这份报告里里面，相对于CF节点，成员节点中多出了当前有效体系结构级别（CEAL）和当前有效代码级别（CECL）这两项。其中CEAL和CECL的值还是10.5.0.0。而磁盘和内存中的体系结构级别（Architecture Level）和代码级别（Code Level）都已经是10.5.0.1。也就是说刚才的升级还没

14、有最终落实。而最终落实是在整个集群的体系结构级别（Architecture Level）和代码级别（Code Level）都升级完成之后。下面开始升级回放节点。从前面的结果可以看到，升级的过程中实例都是会重启的。所以当前节点的HADR回放功能必然会受到影响。清单 15. 更新member 0节点（回放节点）更新完成后member被重启。清单 16. 查看实例状态现在来看看关注的HADR状态是什么样的。清单 17. 查看HADR状态显然HADR已经停掉了。重新激活数据库来启动HADR。清单 18. 激活数据库，启动HADR清单 19. 查看HADR状态HADR恢复正常，两个member节点的赶到

15、了同步的状态。所以可以看到HADR的功能在升级的过程中受到了影响，但是对于数据库服务并没有影响。毕竟只是备集群的HADR功能被停止了。重新启动即可，不会造成数据损失。清单 20. 查看实例级别成员0的当前有效体系结构级别（CEAL）和当前有效代码级别（CECL）还是10.5.0.0。而磁盘和内存中的体系结构级别（Architecture Level）和代码级别（Code Level）都已经是10.5.0.1。结果和升级成员1是一样的。最后升级主CF节点。清单 21. 更新Primary CF节点更新Primary CF的过程中，实例的重启会造成CF角色的转换。清单 22. 更新过程中CF被停，

16、CF角色切换清单 23. 更新完成后CF重新加入为Secondary更新Primary CF的过程中，CF角色的转变并不会影响HADR功能。清单 24. 查看HADR状态HADR状态没有受到影响。至此HADR备集群的所有节点都已经升级完。清单 25. 查看实例级别至此HADR备集群的所有节点都已经升级完，只是还没有落实下来。在落实之前，可以先检查一下修订包是否可落实。清单 26. 检查可升级状态结果表明当前集群可以被落实到10.5.0.1版本。但是现在先不要落实更新。因为更新落实之后，理论上是不会影响HADR。因为新的修订包通常都会兼容回放以前修订包的日志，但是如果有特殊情况，就有可能影响HA

17、DR的同步功能。如果真的会出现这种影响，那用户一定希望将这种影响控制到最小。所以先不落实更新，而是开始滚动升级主集群。滚动升级主集群主集群的滚动升级是指在尽量减少对业务正常工作影响的情况下,一个一个的更新主集群的所有节点。在升级的过程中，需要关注Db2 pureScale集群是否正常提供数据库服务，HADR的同步有没有受到影响等。清单 27. 检查db2level主集群的数据库介质安装路径是/opt/IBM/db2/V10.5， 当前版本是Db2 v10.5.0.0。 和备集群的升级一样，新的Db2安装包将被安装到/opt/IBM/db2/V10.5FP1路径下。清单 28. 查看实例状态HA

18、DR的状态之前检查已经是PEER的状态。实例检查也处于正常工作的状态。成员都是STARTED，CF也处于PEER状态。下面准备升级集群。清单 29. 查看实例级别Secondary CF在升级过程中被重启，但是并不会影响当前数据库提供服务。成员节点的数据库连接不会被中断。清单 31. 查看实例状态HADR在此过程中也一直正常工作。清单 32. 查看HADR状态清单 33. 查看实例级别CF节点129的体系结构级别（Architecture Level）和代码级别（Code Level）都已经升级到了10.5.0.1。下面升级Primary CF节点（这里与升级备集群的顺序稍有差别，是先升级完所

19、有CF之后再升级成员节点）。清单 34. 更新Primary CF节点与更新备集群的时候一样，更新Primary CF节点会重启该节点实例，所以CF角色会发生转变。清单 35. 查看实例状态但是这种角色转变是联机的，不会影响数据库服务，同样也不会影响到HADR。清单 36. 查看HADR状态上述报告中能看到HADR状态正常。清单 37. 查看实例级别至此在整个主集群里面，两个CF的体系结构级别（Architecture Level）和代码级别（Code Level）都已经升级到了10.5.0.1。下面开始升级主集群的成员服务器。清单 38. 更新member 1节点在成员节点升级的过程中，实例

20、会被重启。所以当前节点的应用会被断掉。如果客户端启用了工作负载均衡或者客户端偏好设置的功能，那么应用会自动感知到集群其他健康的成员节点，断掉的连接会重新连接到其他成员节点上去。此成员节点的HADR也会收到影响，与此相关的高可用性功能会触发，从而满足HADR的不间断同步。在升级的过程中，查看HADR状态。清单 39. 查看更新过程中HADR状态从db2pd工具执行结果中可以看到，成员节点0的日志是正常被传送到备集群并同步的。这个节点的HADR状态是PEER。但是成员节点1， 也就是当前被升级的节点，是ASSISTED_REMOTE_CATCHUP状态，简称ARCU。为什么会发生这样的状态呢？这里

21、就要介绍到在pureScale集群下的HADR具备的特殊功能。因为Db2 pureScale集群使用的是GPFS共享文件系统，所有节点的日志都是存放在这个文件系统上的。一旦有节点出现故障，只要GPFS共享文件系统没有故障，其他的健康节点都可以读取到这个出现故障节点所产生的日志，也就能够帮助去恢复日志里面记载的数据，这也就是所谓的成员故障恢复（MCR）。同样的道理，HADR功能也是基于日志传送的，即便当前节点出现故障，其他节点也能够访问到该节点的日志，就可以帮助这个节点传动日志到备集群服务器。所以HADR功能并不会被中断，依旧可以正常运行，只是HADR的状态会变成ARCU状态。在这个状态下，HA

22、DR还是可以做普通takeover的。等到升级完成之后，当前节点实例被重启，HADR能够检测到成员又恢复正常，那么传送日志的任务又会漂移回当前节点，HADR又能够恢复PEER状态。清单 40. 查看实例级别成员1的CEAL和CECL的值还是10.5.0.0。而磁盘和内存中的体系结构级别（Architecture Level）和代码级别（Code Level）都已经是10.5.0.1。最后升级成员0.清单 41. 更新member 0节点更新成员0和更新成员1的结果是一样的。更新过程中成员0的HADR状态会变成ARCU的状态，更新完成后又全部恢复正常。清单 42. 查看实例状态最后查看一下主集群

23、全部升级完成后当前的实例级别。清单 43. 查看实例级别至此HADR主集群的所有节点都已经升级完，只是还没有落实下来。在落实之前，可以先检查一下修订包是否可落实。清单 44. 检查可升级状态结果表明主集群也可以被落实到10.5.0.1版本。落实更新备集群在主备集群的安装路径都升级到10.5.0.1之后，本着向前兼容的原测，先落实备集群的更新。清单 45. 落实更新备集群落实更新是联机完成的。现在查看更新之后的实例界别。清单 46. 查看实例级别落实更新之后，所有磁盘的，内存中的CECL和CEAL都升级到了10.5.0.1。升级成功。现在查看落实更新对HADR的影响。清单 47. 查看HADR状

24、态HADR功能在此过程中，没有收到影响。Db2 V10.5修订包1的HADR功能也能完美兼容Db2 V10.5 GA版本的日志。这是预期的效果。因为落实更新所需的时间比较短，所以即便是出现不兼容的情况，HADR同步受影响的时间也会比较短。所以这是为什么要在这个阶段落实更新。最后查看一下备集群的数据库级别。清单 48. 检查db2level产品的安装路径已经指向了新位置/opt/IBM/db2/V10.5FP1。实例的级别也是升级到了Db2 v10.5.0.1版本。落实更新主集群备集群的更新已经落实。最后落实主集群的更新，整套HADR环境就算是全部升级完成。清单 49. 落实更新主集群主集群的更新落实也是联机的。在此过程中，数据库服务没有中断。清单 50. 查看实例状态HADR状态也