DB2高可用性灾难恢复思路与方法

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,以使该数据库日志记录方式改为存档日志。
1

2

UPDATE DB CFG FOR SAMPLE USING LOGRETAIN ON

UPDATE DB CFG FOR SAMPLE USING TRACKMOD ON

  1. 修改索引日志记录参数
1

2

UPDATE DB CFG FOR SAMPLE USING LOGINDEXBUILD ON

UPDATE DB CFG FOR SAMPLE USING INDEXREC RESTART

注:这一步并不是必须的。

  1. 备份数据库SAMPLE
1 BACKUP DB SAMPLE TO /database/dbbak

其中”/database/dbbak”是笔者用来存放数据库备份文件的目录,你完全可以指定任何一个db2inst1有写入权限的其他目录。

备份完成之后,在/database/dbbak目录下我们会看到数据库备份映像文件:

1 SAMPLE.0.db2inst1.NODE0000.CATN0000.20050726122125.001

注:你所得到的文件名的时间标志部分肯定和我的不一样,在下面的恢复数据库命令中要注意做相应的修改。

  1. 将得到的数据库映像文件复制到DB2SERV2对应的目录下(/database/dbbak)。
  2. 在DBSERV2上恢复数据库SAMPLE:
1

2

RESTORE DATABASE SAMPLE FROM “/database/dbbak” TAKEN AT

20050726122125 REPLACE HISTORY FILE WITHOUT PROMPTING

阅读更多

DB2 锁问题分析与解释

DB2 锁问题分析与解释

DB2 应用中经常会遇到锁超时与死锁现象,那么这种现象产生的原因是什么呢。本文以试验的形式模拟锁等待、锁超时、死锁现象,并给出这些现象的根本原因。

试验环境:

DB2 v9.7.0.6

AIX 6.1.0.0

采用默认的隔离级别CS

STUDENT表的DDL与初始内容

————————————————

— DDL Statements for table “E97Q6C  “.”STUDENT”

————————————————

 

CREATE TABLE “E97Q6C  “.”STUDENT”  (

“AGE” INTEGER ,

“NAME” CHAR(8) )

IN “USERSPACE1” ;

$ db2 “select * from student”

AGE         NAME

———– ——–

3 xu

5 gao

2 liu

1 gu

试验1:验证insert操作与其他操作的锁等待问题

session 1中发出insert操作,在session 2中观察insert,update,delete操作是否会锁超时。

session 1

———

$ db2 +c “insert into student values(4, ‘miao’)”

DB20000I  The SQL command completed successfully.

session 2

———

$ db2 “insert into student values(6, ‘mu’)”

DB20000I  The SQL command completed successfully.

$ db2 “update student set name=’gu’ where age=1”

DB20000I  The SQL command completed successfully.

$ db2 “delete from student where age=2”

DB20000I  The SQL command completed successfully.

—————————————————————————-

结论1:当session 1对表作insert操作时,session 2对该表的insert及其他行的update,delete操作都不会有问题

 

—————————————————————————-

试验2:验证update操作与其他操作的锁等待问题

session 1中发出update操作,在session 2中观察insert,update,delete操作是否会锁超时。

————–

session 1

———

$ db2 commit

$ db2 “select * from student”

AGE         NAME

———– ——–

3 xu

5 gao

6 mu

4 miao

1 gu

5 record(s) selected.

$ db2 +c “update student set name = ‘qing’ where age=4”

DB20000I  The SQL command completed successfully.

session 2

———

阅读更多