InixHDR配置.doc

informix HDR 相关 informix HDR 配置 一，首先安装两台相同版本操作系统的服务器二，服务器配置文件信息主机名和ip地址信息/etc/hosts172.25.1.114 test01172.25.1.115 test02配置数据信任关系/home/informix/.rhosts test01test02三，配置操作系统rsh服务四，安装数据库informix的实例名配置如下：ontest01 onsoctcp test01 6666 ontest02 onsoctcp test02 6666数据库配置文件中主要的配置如下：为了实现通过管道备份恢复，配置TAPEDEV和LTAPEDEV的值STDIO企业复制的参数暂时按照默认设置# Data Replication Variables# DRAUTO: 0 manual, 1 retain type, 2 reverse typeDRAUTO 0 # DR automatic switchoverDRINTERVAL 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 pathDRIDXAUTO 0 # DR automatic index repair. 0=off, 1=on五，开始配置HDR为了测试方便，在test01上面建立一个数据库做为主，test02服务器上的数据库做为从。1，使用onmode -d 将test01的类型设置为主类型并指示相关联的辅助数据库服务器的名称（这个名称指的是从服务器的数据库的实例名）。informixtest01 informix$ onmode -d primary ontest02出现的日志信息为：informixtest01 informix$ onstat -m14:51:55 DR: Reservation of the last logical log for log backup turned on14:51:55 DR: new type = primary, secondary server name = ontest02 14:51:55 DR: Trying to connect to secondary server = ontest0214:51:55 DR: Cannot connect to secondary server14:51:55 DR: Turned off on primary server2，在test01上执行备份通过管道直接在test02上面执行物理恢复informixtest01 informix$ ontape -s -L 0 -F | rsh test02 ontape -p 3，通过下面的日志信息可以看到test02上面的物理恢复已经完成informixtest02 informix$ onstat -mIBM Informix Dynamic Server Version 10.00.UC4 - Fast Recovery - Up 00:01:23 - 229336 KbytesMessage Log File: /home/informix/test02.log14:54:02 DR: Reservation of the last logical log for log backup turned on14:54:02 Data replication type and state information reset. To start DR, usethe onmode -d command and wait for the pair to be operational,before shutting down the database server14:54:02 Dataskip is now OFF for all dbspaces14:54:02 Restartable Restore has been ENABLED14:54:02 Recovery Mode14: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: 0xed4a14: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: 0xed4e14:54:07 Maximum server connections 0 informixtest02 informix$ 4，在test02上执行：informixtest02 informix$ onmode -d secondary ontest01系统提示：informixtest02 informix$ onstat -m14:56:46 DR: Reservation of the last logical log for log backup turned off14:56:46 DR: new type = secondary, primary server name = ontest01 14:56:46 DR: Trying to connect to primary server = ontest0114:56:49 DR: Secondary server connected14:56:49 DR: Secondary server needs failure recovery5，此时数据库继续执行逻辑恢复，日志信息：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 0x17c01814:56:50 Clearing the physical and logical logs has started14:56:51 Cleared 40 MB of the physical and logical logs in 0 seconds14:56:56 DR: Secondary server operational14:56:57 Checkpoint Completed: duration was 0 seconds.14:56:57 Checkpoint loguniq 5, logpos 0x1018, timestamp: 0xedaa14:56:57 Maximum server connections 0 而另外一台主服务器上面的日志信息为：14:56:49 DR: Primary server connected14:56:49 DR: Secondary server needs failure recovery14:56:52 Logical Log 4 Complete, timestamp: 0xed84.14:56:53 DR: Sending log 4, size 1000 pages, 38.30 percent used14:56:53 DR: Sending log 5 (current), size 1000 pages, 0.00 percent used14:56:55 DR: Sending Logical Logs Completed14:56:56 DR: Primary server operational从上面可以看到数据库之间的执行步骤。6，此时数据库的状态为：informixtest02 informix$ onstat -IBM Informix Dynamic Server Version 10.00.UC4 - Read-Only (Sec) - Up 00:04:58 - 237528 Kbytesinformixtest02 informix$ 主服务器的数据库状态为：informixtest01 informix$ onstat -IBM Informix Dynamic Server Version 10.00.UC4 - On-Line (Prim) - Up 00:09:36 - 229336 Kbytesinformixtest01 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 命令设置主数据库服务器的类型并启动HDRonmode -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，辅助数据库服务器上的关键介质故障解决方法-首次启动HDR3，在两个数据库服务器上均发生介质故障在最差的情况下，即运行复制对中的数据库服务器的两个计算机遇到可损坏根数据库空间以及包含逻辑日志文件或物理日志的数据库空间的故障，你就需要重新启动HDR要在两个数据库服务器上均发生关键介质故障后重新启动HDR：1，从存储空间和逻辑日志备份恢复主数据库服务器2，在你恢复主数据库服务器后，就象处理磁盘上没有数据的服务器并且仿佛你正在首次启动HDR一样来处理另一发生故障的数据库服务器。二，在关