分类： DB2/Informix
2008-04-13 22:10:36
一，首先安装两台相同版本操作系统的服务器
二，服务器配置文件信息
主机名和ip地址信息
/etc/hosts
172.25.1.114 test01
172.25.1.115 test02
配置数据信任关系
/home/informix/.rhosts
test01
test02
三，配置操作系统rsh服务
四，安装数据库
informix的实例名配置如下：
ontest01 onsoctcp test01 6666
ontest02 onsoctcp test02 6666
数据库配置文件中主要的配置如下：
为了实现通过管道备份恢复，配置TAPEDEV和LTAPEDEV的值STDIO
企业复制的参数暂时按照默认设置
# Data Replication Variables
# DRAUTO: 0 manual, 1 retain type, 2 reverse type
DRAUTO 0 # DR automatic switchover
DRINTERVAL 30 # DR max time between DR buffer flushes (in sec)
DRTIMEOUT 30 # DR network timeout (in sec)
DRLOSTFOUND /home/informix/etc/dr.lostfound # DR lost+found file path
DRIDXAUTO 0 # DR automatic index repair. 0=off, 1=on
五，开始配置HDR
为了测试方便，在test01上面建立一个数据库做为主，test02服务器上的数据库做为从。
1，使用onmode -d 将test01的类型设置为主类型并指示相关联的辅助数据库服务器的名称（这个名称指的是从服务器的数据库的实例名）。
[informix@test01 informix]$ onmode -d primary ontest02
出现的日志信息为：
[informix@test01 informix]$ onstat -m
14:51:55 DR: Reservation of the last logical log for log backup turned on
14:51:55 DR: new type = primary, secondary server name = ontest02
14:51:55 DR: Trying to connect to secondary server = ontest02
14:51:55 DR: Cannot connect to secondary server
14:51:55 DR: Turned off on primary server
2，在test01上执行备份通过管道直接在test02上面执行物理恢复
[informix@test01 informix]$ ontape -s -L 0 -F | rsh test02 "ontape -p "
3，通过下面的日志信息可以看到test02上面的物理恢复已经完成
[informix@test02 informix]$ onstat -m
IBM Informix Dynamic Server Version 10.00.UC4 -- Fast Recovery -- Up 00:01:23 -- 229336 Kbytes
Message Log File: /home/informix/test02.log
14:54:02 DR: Reservation of the last logical log for log backup turned on
14:54:02 Data replication type and state information reset. To start DR, use
the 'onmode -d' command and wait for the pair to be operational,
before shutting down the database server
14:54:02 Dataskip is now OFF for all dbspaces
14:54:02 Restartable Restore has been ENABLED
14:54:02 Recovery Mode
14:54:04 Physical Restore of rootdbs started.
14:54:05 Checkpoint Completed: duration was 0 seconds.
14:54:05 Checkpoint loguniq 4, logpos 0x17c018, timestamp: 0xed4a
14:54:05 Maximum server connections 0
14:54:07 Physical Restore of rootdbs Completed.
14:54:07 Checkpoint Completed: duration was 0 seconds.
14:54:07 Checkpoint loguniq 4, logpos 0x17c018, timestamp: 0xed4e
14:54:07 Maximum server connections 0
[informix@test02 informix]$
4，在test02上执行：
[informix@test02 informix]$ onmode -d secondary ontest01
系统提示：
[informix@test02 informix]$ onstat -m
14:56:46 DR: Reservation of the last logical log for log backup turned off
14:56:46 DR: new type = secondary, primary server name = ontest01
14:56:46 DR: Trying to connect to primary server = ontest01
14:56:49 DR: Secondary server connected
14:56:49 DR: Secondary server needs failure recovery
5，此时数据库继续执行逻辑恢复，日志信息：
14:56:50 DR: Failure recovery from disk in progress ...
14:56:50 Logical Recovery Started.
14:56:50 10 recovery worker threads will be started.
14:56:50 Dynamically allocated new virtual shared memory segment (size 8192KB)
14:56:50 Start Logical Recovery - Start Log 4, End Log ?
14:56:50 Starting Log Position - 4 0x17c018
14:56:50 Clearing the physical and logical logs has started
14:56:51 Cleared 40 MB of the physical and logical logs in 0 seconds
14:56:56 DR: Secondary server operational
14:56:57 Checkpoint Completed: duration was 0 seconds.
14:56:57 Checkpoint loguniq 5, logpos 0x1018, timestamp: 0xedaa
14:56:57 Maximum server connections 0
而另外一台主服务器上面的日志信息为：
14:56:49 DR: Primary server connected
14:56:49 DR: Secondary server needs failure recovery
14:56:52 Logical Log 4 Complete, timestamp: 0xed84.
14:56:53 DR: Sending log 4, size 1000 pages, 38.30 percent used
14:56:53 DR: Sending log 5 (current), size 1000 pages, 0.00 percent used
14:56:55 DR: Sending Logical Logs Completed
14:56:56 DR: Primary server operational
从上面可以看到数据库之间的执行步骤。
6，此时数据库的状态为：
[informix@test02 informix]$ onstat -
IBM Informix Dynamic Server Version 10.00.UC4 -- Read-Only (Sec) -- Up 00:04:58 -- 237528 Kbytes
[informix@test02 informix]$
主服务器的数据库状态为：
[informix@test01 informix]$ onstat -
IBM Informix Dynamic Server Version 10.00.UC4 -- On-Line (Prim) -- Up 00:09:36 -- 229336 Kbytes
[informix@test01 informix]$
7，此时在test01上面执行的ontape -s -L 0 -F | rsh test02 "ontape -p " 命令还没有结束，在test02上面执行onmode -ky关闭数据库，然后重新启动，此时test01上面的任务完成退出。
8，在test01上面重新建立一个库，然后在test02上面查看是否有新的库，测试HDR是否成功。
HDR 中一些说明 ：
1, DRAUTO
值的范围：
0 表示 OFF = 不要再HDR环境中自动切换服务器类型
1 表示 RETAIN_TYPE = 在HDR故障期间自动从辅助切换到标准。在重新启动HDR时切换回辅助。
2 表示 REVERSE_TYPE = 在HDR故障时自动从辅助切换到标准。在重新启动HDR时到主要（并将换了的主要切换为辅助）。
在共享内存初始化时候生效
DRAUTO确定辅助数据库服务器如何响应HDR故障，在两个HDR服务器上，该参数的值应该相同。
如果DRAUTO设置为OFF，那么当发生HDR故障时，辅助数据库服务器将以只读方式保持为辅助数据库服务器。
如果DRAUTO设置为RETAIN_TYPE或者REVERSE_TYPE，那么当检测到HDR故障时，辅助数据库服务器将自动切换到标准类型。如果DRAUTO设置为RETAIN_TYPE，那么当HDR连接恢复时，原来的辅助数据库服务器将切换回辅助类型，如果DRAUTO设置为REVERSE_TYPE，那么当HDR连接恢复时，原来辅助服务器将切换到主要类型，而原来的主数据库服务器将切换到辅助类型。
2，DRINTERVAL，主数据库服务器将HDR缓冲区的内容同步或异步发送至复制服务器，ONCONFIG配置参数DRINTERVAL的值确定数据库父亲使用同步或异步更新。
DRINTERVAL指定高可用性数据复制缓冲区清仓之间的最大时间见隔（秒），要进行同步更新，则将参数设置为-1.
同步更新：
如果将DRINTERVAL设置为-1，则HDR同步发生。一旦主数据库服务器将逻辑日志缓冲区内容写入HDR缓冲区，它会将那些记录从HDR缓冲区发送至复制数据库服务器。仅当主数据库服务器接收到来自服务器数据库服务器的确认（已收到记录）之后，主数据库服务器的逻辑日志缓冲区才会完成。
使用同步更新时，如果发生故障，则在主数据库服务器上提交的事务不会任未提交或部分提交。
异步更新
如果将DRINTERVAL设置为除-1以外的任何值，则数据库复制将异步发生。主数据库服务器在将逻辑日志缓冲区内容复制到HDR缓冲区后清仓逻辑日志缓冲区。（与上述操作无关）当发生以下条件之一时，主数据库服务器在整个网络上发送ＨＤＲ缓冲区的内容
１，ＨＤＲ缓冲区满
２，自上次将记录发送至辅助数据库服务器以后，DRINTERVAL配置参数在主数据库服务器上指定的时间间隔已经过去。
该更新方法可以提供比同步更新更好的性能。但是，如下节所述，可能会丢失事务。
丢失和找到事务：
如果异步更新时，在主数据库服务器上提交的事务可能未在辅助数据库服务器上复制。如果在主数据库服务器将提交记录复制到HDR缓冲区之后但在主数据库服务器将该提交il发送至辅助服务器之前发生故障，就会产生这种情况。
如果在主数据库服务器故障后将赴沪数据库服务器更改为标准数据库服务器，它会回滚所有打开的事务。这些事务包括任何在主数据库服务器上提交但辅助数据库服务器未接受到的其体积记录的事务。因此，事务在主要数据库服务器上但未在辅助数据库服务器上提交。当您在故障后重新启动数据复制，则数据库服务器在主数据库服务器的逻辑恢复期间将丢失的事务中的所有逻辑日志记录放置在某文件(DRLOSTFOUND 配置参数指定）中。
如果在重新启动数据库复制后运行主数据库服务器的机器上出现丢失和找到文件，则表示已丢失了某事务。数据库服务器无法重新应用丢失和找到文件中的事务记录，因为在辅助数据库服务器充当标准数据库服务器时可能已发生有冲突的更新。
为了减少不用同步方式运行数据复制而丢失事务的风险，请为所有数据库事务为缓冲的日志记录。该方法减少了从主数据库服务器到辅助数据库服务器的写入和事务记录传送之间所需的时间量。
3，OFF_RECVRY_THREADS配置参数指定使用logrecvr线程数（用于处理HDR的线程）
HDR 在发生介质故障后恢复数据：
一，在主数据库服务器上发生介质故障后进行恢复
主数据库服务器上介质故障的各种情况
1，包含关键介质，无镜像(恢复方法--在关键数据损坏后重新启动)
要在关键介质故障后重新启动ＨＤＲ：
1),如果原始辅助数据库服务器已经更改为标准数据库服务器，可以将该数据库服务器(DRAUTO=0)变为静默方式，然后使用onmode -d 命令将类型恢复为辅助类型。
如果DRAUTO=1 (RETAIN_TYPE),则此步骤不适用。当您使主数据库服务器返回联机模式式，数据库服务器将自动执行逐渐关闭并切换回类型辅助
如果DRAUTO=2 (REVERSE_TYPE),则当旧的主服务器发生故障时（而非旧的主服务器重新启动时），在连接结束时，辅助数据库服务器将立刻成为主数据库服务器。
2),从最近的数据库空间备份恢复主数据库服务器。
3),使用onmode -d 命令设置主数据库服务器的类型并启动HDR
onmode -d命令从辅助是ujfuwq磁盘上的逻辑日志文件启动对主数据库服务器的恢复。如果因为您在原辅助数据库服务器上备份并释放逻辑日志文件而无法完成逻辑恢复，则至至您执行步骤4后，HDR才会开始。
4),从辅助数据库服务器将逻辑日志文件（这些文件已经备份到磁带） 应用到主数据库服务器。
如果需要进行这一步，主数据库服务器会发送消息，提示您从磁带恢复逻辑日志文件。该消息显示在消息日志中。当从磁带恢复了所有需要的逻辑日志文件时，辅助磁盘上的任何剩余逻辑日志文件也得以恢复。
2，包含关键介质，有镜像(恢复方法-复原镜像块)
3，不包含关键介质，无镜像
4，不包含关键介质，有镜像(恢复方法-复原镜像块)
辅助数据库服务器上介质故障的各种情况
1，包含关键介质，无镜像(恢复方法-HDR重建)
2，包含关键介质，有镜像(恢复方法-复原镜像块)
3，不包含关键介质，无镜像(恢复方法-HDR重建)
4，不包含关键介质，有镜像(恢复方法-复原镜像块)
复原镜像块
要开始对联机重的数据进行镜像，您必须恢复脱机块。
使用onspaces复原镜像块
使用onspaces -s 实用程序恢复脱机块。例如：要恢复具有路径名/dev/mirror_chk1和0千字节偏移量的块，可以发出一下命令：
onspaces -s db_act -p /dev/mirror_chk1 -o 0 -0
在关键数据损坏后重新启动
1，主数据库服务器上的关键介质故障
解决方法--在关键数据损坏后重新启动
2，辅助数据库服务器上的关键介质故障
解决方法--首次启动HDR
3，在两个数据库服务器上均发生介质故障
在最差的情况下，即运行复制对中的数据库服务器的两个计算机遇到可损坏根数据库空间以及包含逻辑日志文件或物理日志的数据库空间的故障，你就需要重新启动HDR
要在两个数据库服务器上均发生关键介质故障后重新启动HDR：
1，从存储空间和逻辑日志备份恢复主数据库服务器
2，在你恢复主数据库服务器后，就象处理磁盘上没有数据的服务器并且仿佛你正在首次启动HDR一样来处理另一发生故障的数据库服务器。
二，在关键数据未损坏时重新启动
如果两个磁盘上都没有关键数据受到损坏，可能有以下四种情况
1，发生网络故障
2，辅助数据库服务器发生故障
3，主数据库服务器发生故障，而辅助数据库服务器未更改为标准数据库服务器。
4，主数据库服务器发生故障，而且辅助数据库服务器更改为标准数据库服务器。
在网络故障后重新启动
在网络故障后，主数据库服务器处于联机方式，辅助数据库服务器处于只读方式。HDR在两个数据库服务器上都关闭（state=off）。在重新建立连接时，你可以通过在辅助数据库服务器上发出onmode -d secondary primary_name 来重新启动HDR。重新启动HDR可能是不必要的，因为主数据库服务器每10秒钟就尝试重新建立连接一次，并且每2分钟就显示关于无法连接的消息。你不必使用onmode 来重新启动连接。
在辅助数据库服务器发生故障时重新启动
如果您需要在辅助数据库服务器发生故障后重新启动HDR，在辅助服务器上oninit启动数据库服务器，如果您在消息日志中接受到一些消息：DR：start failure recovery from tape,继续运行ontape -l 恢复。这些步骤假设你自辅助数据库服务器发生故障后一直按需要备份主数据库服务器上的逻辑日志文件。
辅助数据库服务器未更改为标准数据库服务器
如果辅助数据库服务器未更改为标准服务器，而你需要在主数据库服务器发生故障后重新启动HDR，则只需要使用oninit将主数据库服务器恢复联机即可！
辅助数据库服务器已更改为标准数据库服务器
如果你需要在主数据库服务器发生故障后重新启动HDR，并且你已经将辅助数据库服务器更改为标准数据库服务器，请按照下面操作
1，辅助服务器 onmode -s
2，辅助服务器 onmode -d secondary prim_name
3，主服务器 oninit
4，主服务器 ontape -l
