informix HDR原理及 DRAUTO 等参数总结

最新推荐文章于 2022-05-11 16:21:45 发布

cite7656271

最新推荐文章于 2022-05-11 16:21:45 发布

阅读量1k

点赞数

文章标签：数据库

Informix的HDR（High-Availability Data Replication）为应用提供了高可靠性的数据库服务，其实现的方法就是在单个Informix Server基础之上添加一套备用的Server，冗余的Server能够完全复制主Informix Server，这样，一旦主Server摊机，冗余的Server就可以保证业务不间断，数据也不会丢失。IIN的热双机组网使用的就是Informix HDR机制，本FAQ将阐述HDR的相关原理以及常见问题。

相关原理

本节简要描述一下HDR同步原理。

备机和主机数据同步利用的是逻辑日志，Informix的逻辑日志记录了所有事务的详细操作过程，利用逻辑日志，备机就可以完全同步主机上的所有操作，请看下图：

主用数据库上进行的任何操作都将已逻辑日志的方式记录在逻辑日志buffer中，这也是备用数据库同步主用数据库数据的唯一依据。主用数据库会按照一定的原则将逻辑日志buffer中的内容写入到DR buffer中，DR buffer中的日志也会被主用数据库发送到备用数据库，这样，备机就可以同步主用数据库上的数据了。当然，建立HDR的前提是数据库不能采用无日志方式。

上面描述的是主备数据库在正常工作时的同步方式，而最初在做DR时，备用数据库并非是按照这种方式进行同步的，做过DR的人都知道，首先必须在主用数据库上做一次0级备份，0级备份是以最近一次Check Point为基准点进行的，这也是个一致点，即硬盘上的数据和buffer中的数据是相同的。备用数据库使用主用数据库0级备份数据进行物理恢复，那么，物理恢复完成之后，备用数据库和主用数据库还不是同步的，此时，备用数据库会利用主用数据库的逻辑日志进行逻辑恢复，即将0级备份基准点之后的数据也同步过来，这一步完成之后，主备数据库才是真正的同步了。

1.1 DRAUTO参数

数据库在HDR模式下时，当主用数据库摊机时，DRAUTO参数决定了备用数据库的状态迁移规则。

1、 DRAUTO=0

这种模式被称为“manual”,即手工模式。当主用数据库变为不可用时，备用数据库的状态不会有任何改变，仍然处于Read Only状态，只能手工修改备用数据库的状态。

2、 DRAUTO=1

这种模式被称为“retain”，当主用数据库变为不可用时，备用数据库的状态自动变成标准模式On-Line。当备用数据库检测到主用数据库恢复正常之后，备用数据库又恢复成Read Only状态。

3、 DRAUTO=2

这种模式被称为“reverse”,当主用数据库变为不可用时，备用数据库的状态自动变成主用模式On-Line (Prim)，原来有故障的主用数据库恢复正常之后会自动变为备用数据库状态。

IIN在热备方式下，DRAUTO一定要配成2，否则双机切换时数据库会变成我们所不期望的状态。

1.2 DRINTERVAL参数

DRINTERVAL单位是秒，它约束了DR buffer中的数据传送到备机buffer中的最大时间间隔。

DRINTERVAL参数越大，主备数据库同步的频率越低，则处于不同步状态的数据在DR buffer中堆积可能越多，此时如果主用数据库异常摊机，则丢失的事务就会越多。

DRINTERVAL参数越小，主备数据库同步的频率越高，则处于不同步状态的数据在DR buffer中堆积可能越少，那么，主用数据库异常摊机时，丢失的事务也就越少，这样就有效的保证了主备数据库的一致性。特别的，当DRINTERVAL=-1时，主备数据库复制是同步的，没有任何等待。当然，同步的频率越高，整个数据库的性能就会越低，特别是当DRINTERVAL=-1时，性能消耗非常明显，比DRINTERVAL=1时的性能至少低10%。

IIN用户手册对于DRINTERVAL的推荐配置是1，也就是异步数据复制，此时，主用数据库上的逻辑日志一旦被记录就算是完成了，而不像同步数据复制那样，必须等到备用数据库返回确认消息才算完成。当数据库采用异步数据复制时，DR buffer中的数据传送到备用数据库的触发条件是下列三个条件之一：DR buffer满；DRINTERVAL超时；Check Point。其中，DR buffer大小和逻辑日志buffer大小相等，DR buffer大小没有配置项。

1.3 DRTIMEOUT参数

主备数据库在正常工作时是会有一些握手消息交互，以向对方表明自身状态正常。如果这种握手消息连续四次超过了DRTIMEOUT配置的值（单位：秒），则HDR关系就破坏了。此时，主用数据库状态不会迁移，只是记录了和备用数据库处于断连状态，而备用数据库由于检测不到主用数据库，则认为主用数据库已异常，状态自动迁移成主用状态，这时，两个数据库服务器都是主用状态，是一种异常情况。

另外，如果主用数据库是被onmode –ky命令杀掉的，则备用数据库不必等到DRTIMEOUT超时才会变成主用状态，因为，这种停数据库的方法是一种正常的方法，在主用数据库停下之前，会向备用数据库发送自己停机的消息，备用数据库检测到这个消息之后，就知道主用已经异常，会立即变为主用状态。因此，DRTIMEOUT超时通常都表明网络异常，或者oninit进程被直接kill掉。

一、DRAUTO=1的测试

1.关闭primary服务器：
$onstat -c|grep DRAUTO
DRAUTO 1
$onmode -ky

2.检查secondary服务器状态:
$ onstat -c|grep DRAUTO
DRAUTO 1
$onstat -
IBM Informix Dynamic Server Version 11.70.UC1IE — On-Line — Up 00:02:33 — 152348 Kbytes

3.开启primary服务器：
$oninit
$onstat -
IBM Informix Dynamic Server Version 11.70.UC1IE — On-Line (Prim) — Up 00:00:41 — 144156 Kbytes

4.检查secondary服务器状态：。
$onstat -

IBM Informix Dynamic Server Version 11.70.UC1IE — Updatable (Sec) — Up 00:04:53 — 152348 Kbytes

可以看到，当DRAUTO=1 时，主服务器恢复以后仍能保持主服务器的地位，具体如下：

关闭主服务器：onmode – ky
辅助服务器自动完成以下状态变化：Updatable (Sec) > Fast Recovery (Sec) > On-Line
对于连接到 HDR对的应用在一个超时以后就可以自动平滑过渡到辅助服务器
重启主服务器，重启主服务器 IDS 实例：oninit – vy，主服务器自动完成以下状态变化：Fast Recovery (Prim) > Quiescent (Prim) > On-Line (Prim)
同时，辅助服务器自动完成以下状态变化：On-Line > Shutting Down > Updatable (Sec)
上面毕竟操作过慢，这些过程状态没有没有抓住，只抓住了最后的结果状态。

二、DRAUTO=2的测试

1.关闭primary服务器：
$onstat -c|grep DRAUTO
DRAUTO 2
$ onmode -ky
2.检查secondary服务器状态:
$onstat -c|grep DRAUTO
DRAUTO 2
$ onstat -
IBM Informix Dynamic Server Version 11.70.UC1IE — On-Line (Prim) — Up 00:02:41 — 152348 Kbytes

3.开启primary服务器：
$oninit
$onstat -
IBM Informix Dynamic Server Version 11.70.UC1IE — Updatable (Sec) — Up 00:00:25 — 152348 Kbytes

4.检查secondary服务器状态：。
$onstat -
IBM Informix Dynamic Server Version 11.70.UC1IE — On-Line (Prim) — Up 00:04:28 — 152348 Kbytes

可以看到当DRAUTO=2 时，主服务器恢复以后只能退为辅助服务器的地位
关闭主服务器：onmode – ky
辅助服务器自动完成以下状态变化：Updatable (Sec) > Fast Recovery (Sec) > On-Line (Prim)
对于连接到HDR对的应用在一个超时以后就可以自动平滑过渡到辅助服务器
重启主服务器，重启主服务器 IDS 实例：oninit – vy，主服务器变为新的辅助服务器，状态为：Updatable (Sec)
同时，辅助服务器状态保持：On-Line (Prim)

HDR使用过程中应该注意的问题

1.1 HDR不能重新建立

当HDR关系被破坏之后，或者发生主备数据库切换之后，有可能出现DR关系不能重新建立的情况，此时，通常的做法就只有手工重建DR了。这种DR关系不能自动重新建立的情况通常都是由于操作不当造成的，后面对一些关键的操作顺序做了些介绍。

1.2 启停数据库的顺序

停止数据库的顺序：先停备用数据库，后停主用数据库。

启动数据库的顺序：先将主用数据库拉起，等主用数据库变成On-Line (Prim)状态之后，再启动原备用数据库。当然，如果DR关系已经被破坏或者停数据库的顺序不当，则按照这种方法有可能还是不能使数据库DR关系建立起来。

1.3 数据库的主备切换

当主用数据库停掉之后，备用数据库就会变成主用数据库，在最初的的一段时间之内，虽然新的主用数据库状态已经变成On-Line (Prim)，但是如果此时立刻将被停掉的数据库拉起，则很有可能导致DR关系破裂，此时最有可能出现的情况就是两个数据库Server都变成主用状态。要避免出现这种情况，最好在切换之后，等一段时间再将停掉的数据库拉起，以便让新的主用数据库确立自己的主用地位，等待的时间最好在3分钟以上。如果要确信是否可以拉起被停掉的数据库，可以查看新的主用数据库online.log日志末尾是否有如下的日志记录：

18:00:24 DR: Cannot connect to secondary server

18:00:24 DR: Turned off on primary server

如果出现这两条记录，则表明此时可以安全地将停掉的数据库拉起。

informix的一个BUG

INFORMIX数据库HDR切换后，原来的主在重启恢复成备的过程中会判断数据库0级备份和1级备份（不限于1级）的时间戳，若1级备份执行的时间比0级备份执行的时间晚，则数据库认为数据不可信，启动异常而退出，无法恢复DR关系。目前的解决办法是在双机切换前将备份路径指向空，做一次虚的0级备份（需要的话可以做真实的），然后双机切换，再恢复就不存在问题了。或者在恢复出现问题时，重做DR。也就是说以后在局点的日常维护中不建议做1级以上的备份，否则可能引起双机切换后，恢复不成功，需要重做DR。