在 DB2 的高可用性(HA,High Availability)技术中,Standby 是其中之一(还有 snapshot 和 mirror)。它的原理跟在 Oracle 的 Data Guard 相似,都是提供一种待机模式,让另外一台服务器接收来自 "主" 系统的日志,并更新至待机数据库中,以达到数据同步的目的。
DB2 提供了两种切换选项给用户,即
在传输日志的方式中,DB2 提供了三种模式:
DB2 HADR 与 Oracle dataguard 有几分类似,这里实验采用手动切换主备,同时日志传送采用 NEARSYNC 的模式。
DB2 HADR 概述
High Availability Disaster Recovery (HADR) 是数据库级别的高可用性数据复制机制,最初被应用于 Informix 数据库系统中,称为 High Availability Data Replication(HDR)。IBM 收购 Informix 之后,这项技术就应用到了新的 DB2 发行版中。一个 HADR 环境需要两台数据库服务器:主数据库服务器(primary)和备用数据库服务器(standby)。当主数据库中发生事务操作时,会同时将日志文件通过 TCP/IP 协议传送到备用数据库服务器,然后备用数据库对接受到的日志文件进行重放(Replay),从而保持与主数据库的一致性。当主数据库发生故障时,备用数据库服务器可以接管主数据库服务器的事务处理。此时,备用数据库服务器作为新的主数据库服务器进行数据库的读写操作,而客户端应用程序的数据库连接可以通过自动客户端重新路由(Automatic Client Reroute)机制转移到新的主服务器。当原来的主数据库服务器被修复后,又可以作为新的备用数据库服务器加入 HADR。通过这种机制,DB2 UDB 实现了数据库的灾难恢复和高可用性,最大限度的避免了数据丢失。下图为 DB2 HADR 的工作原理图:
注:处于备用角色的数据库不能被访问。
下面我们首先从一个配置实例入手来了解 DB2 HADR 环境的基本配置过程,然后再对 HADR 环境涉及到的一些技术要点展开讨论。
快速实例上手
要进行这个实例配置过程,你必须拥有 DB2 UDB Enterprise Server Edition (ESE),笔者使用的是 DB2 ESE v8.2.2 for Linux 32bit(在 v8.2 的基础上打了 Fixpack9a)。如果您没有这个版本,可以到 IBM 官方网站下载试用版(可能需要花点时间填写一些信息),下载链接:https://www14.software.ibm.com/webapp/iwm/web/preLogin.do?source=db2udbdl。
另外,笔者使用的是两台 DELL PowerEdge 2850 作为数据库服务器,安装 Redhat linux Enterprise Server v4.0。这两台机器的主机名和 IP 地址分别为:DBSERV1(192.168.1.162)和 DBSERV2(192.168.1.163)。在下面的配置过程中我们将 DBSERV1 作为主数据库服务器,其实 HADR 配置好之后,这两台服务器的角色是可以转换的。为简单起见,我们就采用 DB2 的样本数据库 SAMPLE 作为配置对象。
配置过程(以下命令均在 DB2 CLP 中执行):
1. 在 DBSERV1 和 DBSERV2 上安装 DB2,并创建缺省实例 db2inst1,服务端口:50000,我们使用缺省的实例所有者用户 db2inst1,密码:db2inst1
2. 使用 db2sampl 命令在 DBSERV1 上创建样本数据库 SAMPLE
3. 修改 SAMPLE 数据库配置参数 LOGRETAIN 为 ON,以使该数据库日志记录方式改为存档日志。
|
4. 修改索引日志记录参数
|
注:这一步并不是必须的。
5. 备份数据库 SAMPLE
|
其中 "/database/dbbak" 是笔者用来存放数据库备份文件的目录,你完全可以指定任何一个 db2inst1 有写入权限的其他目录。
备份完成之后,在 / database/dbbak 目录下我们会看到数据库备份映像文件:
|
注:你所得到的文件名的时间标志部分肯定和我的不一样,在下面的恢复数据库命令中要注意做相应的修改。
6. 将得到的数据库映像文件复制到 DB2SERV2 对应的目录下(/database/dbbak)。
7. 在 DBSERV2 上恢复数据库 SAMPLE:
|
8. 配置自动客户端重新路由:
在主数据库服务器(DBSERV1)上:
|
在备用数据库服务器上(DBSERV2):
|
9. 配置 HADR 服务和侦听端口
用 vi 编辑 / etc/services 文件(需要切换到 root 用户),加入下面两行:
|
对于 Windows,编辑 %SystemRoot%\system32\drivers\etc\services。
注:这一步不是必须的,因为在下面配置 HADR_LOCAL_SVC 和 HADR_REMOTE_SVC 数据库参数的时候您可以直接使用端口号来替代服务名。
10. 修改主数据库(DBSER1 - SAMPLE)的配置参数:
|
11. 修改备用数据库(DBSERV2 - SAMPLE)的配置参数:
|
12. 启动 HADR:
首先启动备用数据库服务器的 HADR:
|
然后启动主数据库服务器的 HADR:
|
注:如果你先启动主数据库服务器 HADR,那么你必须保证在 HADR_TIMEOUT 参数指定的时间内(单位为秒)启动备用数据库服务器 HADR。否则将启动失败。
OK,到目前为止,我们已经成功配置并启动了 DB2 HADR。在下一节中我们将对这个配置好的 HADR 环境进行一些测试来验证它是否能按照我们预期的方式工作。
HADR 测试
1. 连接到主数据库,创建测试表 HADRTEST,并插入几条测试数据:
|
2. 使用备份数据库接管主数据库
|
观察数据库主数据库和备用数据库的状态:
|
新的主数据库(原备用数据库):
备用数据库(原主数据库):
3. 连接到新的主数据库,并查询 HADRTEST 表:
显然,我们的 HADR 环境已经可以正常工作了。读者可以自己再针对数据的修改、删除等进行一些测试。自动客户端重新路由(Automatic Client Reroute)功能也留给读者自己测试。
HADR 管理操作汇总
1. 启动和停止 HADR
使用 START HADR 命令启动主数据库和备用数据库的 HADR。启动主数据库使用 AS PRIMARY 子句,启动备用数据库使用 AS STANDBY 子句。如果想以其他用户启动 HADR,可以通过 USER user-name USING password 子句指定用户名和密码:
例子:
|
在启动主数据库的 HADR 时,如果在数据库 HADR_TIMEOUT 所指定的时间内未能建立与备用数据库 HADR 的连接,启动将失败。这时候,你可以等排除故障并成功启动备用数据库 HADR 后再启动主数据库 HADR,也可以通过指定 BY FORCE 子句强行启动主数据库。
例如:
|
使用 STOP HADR 停止主数据库和备用数据库的 HADR。
如果在活动的主数据库上发出此命令,所有的数据库连接都被断开,数据库恢复为标准数据库(我们称没有启用 HADR 的数据库为标准数据库),并保持联机状态。
如果在活动的备用数据库上发出此命令,将停止失败。你必须先使用 DEACTIVATE DATABASE 命令取消激活,然后再停止 HADR。
2. 查看 HARD 的配置及运行状态
HADR 连接状态:
当备用数据库的 HADR 启动时,它首先进入本地同步更新状态。并根据本地日志路径配置参数及日志归档方法的设置检索本地系统中的日志文件并重放。当本地日志文件重放完毕,备用数据库进入远程同步暂挂状态。当与主数据库建立连接之后,备用数据库进入远程同步更新状态。即主数据库将自己的日志文件通过 TCPIP 协议发送给备用数据库,备用数据库接收到日志文件并重放,直到所有日志文件都重放完毕,备用数据库和主数据库进入对等状态。见下图:
通过 GET SNAPSHOT 命令观察主数据库和备用数据库的连接状态。
通过 GET DB CFG 命令可以查看 HADR 的配置情况,即 HADR 相关的几个数据库参数值。
3. 接管 / 故障转移
当主数据库发生故障时,备用数据库可以接管主数据库的服务,成为新的主数据库(称为故障转移)。当原主数据库修复后,又可以作为备用数据库加入 HADR 对。即使主数据库服务器没有故障,我们通过接管命令(TAKEOVER)切换主数据库和备用数据库的角色。接管命令只能用在备用数据库上。
HADR 提供两种接管方式:
紧急接管:
当主数据库发生故障时,可以在备用数据库上使用紧急接管,使备用数据库成为新的主数据库。紧急接管必须指定 TAKEOVER 命令的 BY FORCE 子句,例如:
|
普通接管:
普通接管就是没有使用 BY FORCE 子句的接管,例如:
|
这种接管必须在主数据库和备用数据库都正常运行的情况下使用。如果主数据库发生故障,普通接管将失败,这时候必须使用上面的紧急接管。
4. 同步方式
在上面的配置实例中我们将主数据库和备用数据库的 HADR_SYNCMODE 参数值设置为 NEARSYNC,当主数据库和备用数据库处于对等状态时,HADR 采用 NEARSYNC(接近同步)同步方式管理日志写入。DB2 提供了三种日志同步方式:
SYNC(同步):
采用 SYNC 方式时,仅当主数据库日志写入成功,并收到备用数据库的应答,确保备用数据库的日志也成功写入的情况下,才认为日志写入成功。
这种方式下的事务响应时间最长,但最大限度的确保不发生事务丢失。
NEARSYNC(接近同步):
采用 NEARSYNC 方式时,当主数据库日志写入成功,并收到备用数据库的应答,确定备用数据库已经接收到日志时,即认为日志写入成功。也就是说,备用数据库接收到的日志并不一定能成功写入持久存储设备上的日志文件。
这种方式下的事务响应时间比 SYNC 方式短,且仅当两台服务器同时发生故障时,才会发生事务丢失。
ASYNC(异步):
采用 ASYNC 方式时,当主数据库日志写入成功,并将日志发送出去之后,即认为日志写入成功。此方式并不保证备用数据库能收到日志,这要依赖于 TCP/IP 网络情况。
这种方式下的事务响应时间最短,但产生事务丢失的可能性也最大
5. 自动客户端重新路由(Automatic Client Reroute)
要配置自动客户端重新路由,使用 UPDATE ALTERNATE SERVER 命令设置备用数据库信息(使用方法参考上面的配置实例),这些信息将被存放在数据库的系统目录中。请注意:必须使用此命令来设置备用数据库,而不是 HADR_REMOTE_HOST 和 HADR_REMOTE_SVC 数据库配置参数,自动客户端重新路由不使用这两个参数。
当客户端与数据库建立连接时,备用数据库的配置信息(主机 / IP 及 端口号)也同时被发送给 DB2 客户端。当客户端与主数据库的连接被中断时,客户端就使用这些信息连接到备用数据库,从而最小限度的降低了数据库故障所造成的影响。需要强调的是,这个过程由 DB2 客户端自动完成,不需要用户用程序干涉。见下图:
通过 LIST DB DIRECOTRY 命令可以查看系统数据库目录中自动客户端重新路由的配置。
6. 使用控制中心管理 HADR
在上面的讨论中我们主要通过 DB2 CLP 命令来创建和管理 DB2 HADR。实际上 DB2 的控制中心也提供了创建和管理 HADR 的图形界面,例如:工具 -〉向导 -〉设置高可用性灾难恢复(HADR)数据库。这些功能使用起来都非常简单,在这里我们就不详细讨论了。但是,笔者强烈建议尽量多使用 DB2 CLP 命令来管理 DB2(不仅仅是针对 HADR),不要过于依赖 DB2 控制中心,因为很多服务器环境都不安装控制中心,这时候你如果没有掌握 DB2 CLP 命令,那可就麻烦大了。
7. 关于索引日志记录
索引的创建、重建、重组也是 HADR 环境中需要考虑的一个方面,DB2 通过数据库配置参数 LOGINDEXBUILD 和 CREATE TABLE 或 ALTER TABLE 语句中的 LOG INDEX BUILD 选项来控制是否对索引的相关操作进行详细的日志记录。我们在上面的 HADR 配置实例中将 LOGINDEXBUILD 数据库参数配置为 ON,意为让 DB2 记录索引创建、重建、重组的完整日志。这显然会降低主数据库的运行效率并占用更多的日志空间。但因为备用数据库可以通过重放日志来重新构建索引,所以当主数据库发生故障,备用数据库的索引仍然可用。
用户可以通过 CREATE TABLE 或 ALTER TABLE 语句的 LOG INDEX BUILD 选项来对单个表设定索引日志记录级别。LOG INDEX BUILD 选项有三个可选参数:
如果表选项 LOG INDEX BUILD 设置为 OFF,或者 LOG INDEX BUILD 设置为 NULL 但数据库配置参数 LOGINDEXBUILD 设置为 OFF,DB2 将不记录这些表的索引维护日志,备用数据库也就无法重放索引维护操作,致使这些索引在备用数据库上变为无效状态。当主数据库发生故障,备用数据库切换为新主数据库后,这些无效的索引必须重建才能被使用。DB2 通过数据库配置参数 INDEXREC 来指定在什么时候检查并重建无效索引。INDEXREC 参数有三个可选值:
在上面的配置实例中,我们将 INDEXREC 的值设为 RESTART,备用数据库将在接管为新的主数据库时检查并重新构建所有无效索引。
DB2 HADR 的使用限制
结束语
你也可以通过一些专门的 HA 软件来实现高可用性和灾难恢复,但这些 HA 软件一般都很昂贵,而 DB2 HADR 是包含在 DB2 ESE 里的,不需要额外的费用,另外,DB2 HADR 配置和管理也很简单,而且功能也很不错,所以笔者一直喜欢将它推荐给客户。
(转) DB2 HADR
来源: http://www.bubuko.com/infodetail-2276613.html