DB2 HADR 监控详解1

HADR 简介

HADR( 高可用性灾难恢复 ) 是 DB2 数据库的一个组件,是 DB2 提供给用户的一种高可用性和灾难恢复的解决方案。组成 HADR 需要一对机器,一个主机和一个备机。它的基本原理是主机将数据库产生的日志通过网络传输到备机,然后备机将这些日志重新应用,整个过程类似于前滚恢复。从而保证主机和备机数据库的一致。当主机发生意外停机以后,例如停电或者灾难等,备机可以很快的接替主机继续工作。从 DB2 V97FP1 开始,HADR 开始支持 ROS(Read On Standby),备机除了做备份数据库以外,还可以接收连接,执行读操作。



HADR 的监控

通过数据库参数获取 HADR 的配置信息

通过获取数据库配置信息,可以看到 HADR 的一些基本配置,如图 1,可以看到 HADR 的角色、同步方式、超时时间等等。


图 1. 通过获取数据库信息查看 HADR 配置

如果需要修改这些参数,可是使用”db2 update db cfg for dbname using CONFIG_PARAM value”命令对相应的参数进行修改。修改以后,需要重新启动数据库新的配置才生效。

通过数据库快照获取 HADR 的运行状况

DB2 的快照信息显示了某个时刻数据库的运行状况。从这些数据里面,也可以观察到 HADR 的运行情况。例如,从图 2 中,可以看到 HADR 的角色、状态、连接状况、当前正在操作的日志文件等等。


图 2. 通过获取数据库信息查看 HADR 的运行状况

通过 DB2PD 获取 HADR 运行状况

Db2pd 是一个很强大的工具。通过这个工具,可以看到 DB2 在运行时,内存里面的一些状况。所以通过 db2pd 看到的信息都是实时信息。

通过 db2pd – hadr 看到的信息是非常完整的,下面会对这些输出项目进行详细的解释。


图 3. 通过 DB2PD 获取 HADR 的运行状况

通过以上方式,可以看到如下监控项。

角色(Role):标志数据库是主数据库还是从数据库。

状态(State):HADR 当前的状态。包括 Local Catchup、Remote Catchup、Remote Catchup Pending、Peer、Disconnect Peer。

Local Catchup: 如果备机在这种状态下,表明备机这在从本地的磁盘上读取日志文件,并且对日志进行重新重做;如果主机在这种状态下,表明它正在等待备机的连接。HADR 的主机并没有从本地读日志并重做的过程,我们之所以让主机显示这个状态,就是通过主机上的这个状态告诉用户,备机正在做本地日志的重做。

Remote Catchup: 处于这个状态的 HADR 的主机正在从本地读日志,并且将这些日志发送给备机;而备机会从主机接受日志,并且将这些日志写入它本地的磁盘,并且对这些日志进行重做。

Remote Catchup Pending: 如果备机出于这种状态,表明它正在尝试连接主机。出现这种状态,一般是因为主机不存在或者主机还没有完全的启动起来,导致连接没有成功。

Peer: 如果 HADR 的主备机器处于这种状态,表明主机和备机的网络连接良好。日志可以顺利的从主机发送到备机。

Disconnect Peer: 如果 HADR 的主备机器处于这种状态,表明主机和备机的网络已经断开,但是连接断开的时间并没有超过 PEER_WINDOW。这个状态内,主机上的事务不可以提交。如果这个时候网络恢复,主机和备机重新建立连接,主备机器会重新回到 PEER 状态;如果双方进入这个状态的原因是主机出现了故障,当在备机上做接管(takeover)操作时,不会发生数据丢失。就是说不会出现主机提交了某个事务,但是备机没有提交这个事务的情况。

Disconnected: 如果主机处于这种状态,表明主机没有收到来自备机的连接。如果备机处于这种状态,表明备机不能连接到主机。

同步方式(SyncMode):HADR 传输日志的三种方式,同步模式,近同步模式,异步模式。由于这三种方式对 HADR 来说特别重要,笔者在这里将详细介绍这三种方式。

1. 同步模式:这种模式下,主机首先将日志写入本地磁盘,然后发送给备机。备机收到这些日志以后,首先将这些日志写入本地磁盘以后,然后向主机发送一个回应。当主机收到这个回应以后,事务才可以提交。


图 4. 同步模式示意图

这种模式下,因为当事务提交时,相应的日志已经保存在了备机的磁盘上。所以主机在任何时间下发生故障,备机切换以后可以保证不丢失数据。

2. 近同步模式:在这种模式下,主机在将日志写入磁盘的同时将日志发送到备机。当备机收到日志以后,就会向主机发送回应消息。主机收到这条回应消息以后,事务才可以提交。

也就是说,当主机收到回应消息时,刚才发送备机的日志不一定写到了备机的磁盘上,而有可能还在备机的内存里。如图 5 所示:


图 5. 近同步模式示意图

这种模式下,因为主机发送的日志已经保存在了备机的内存中。只有当主机和备机同时出现故障停机的时候,才会丢失数据。

3. 异步模式:与近同步模式类似,在这种模式下,主机也是写日志到磁盘的同时发送日志到备机。与近同步模式不同的是,在异步模式下,主机并不会等备机的回应消息。而是日志发送成功以后,事务就可以提交。在这里,日志发送成功并不代表主次一定收到了这条消息,这条消息也可能保存在了主机的 TCP 发送缓冲区里面。


图 6. 异步模式示意图

这种模式下,因为日志有可能仍然在主机的 TCP 缓冲区里面,如果这个时候主机出现故障停机,这些数据就会丢失。但是和另两种模式相比,异步模式网络上的开销减小了,这种模式对数据库性能影响是最小的。

以下文章点击率最高

Loading…

     

如果这文章对你有帮助,请扫左上角微信支付-支付宝,给于打赏,以助博客运营

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注