INFORMIXHDR 机制与事务丢失Word格式文档下载.docx
《INFORMIXHDR 机制与事务丢失Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《INFORMIXHDR 机制与事务丢失Word格式文档下载.docx（14页珍藏版）》请在冰点文库上搜索。
1.DRAUTO：
该参数确定辅助数据库服务器响应HDR失败的模式。
取值范围：
0，1，2
DRAUTO＝0表示OFF。
即在HDR失败时不自动切换服务器类型。
辅助数据库服务器将以只读方式继续保持辅助类型。
DRAUTO＝1表示RETAIN_TYPE。
即在HDR失败时辅助数据库服务器类型自动从辅助切换到标准。
而当HDR链接恢复时，原来的辅助数据库服务器将自动切换回辅助类型。
DRAUTO＝2表示REVERSE_TYPE。
即在HDR失败时辅助数据库服务器自动从辅助切换到主用。
当HDR链接恢复时，原来辅助数据库服务器仍为主用类型，而原来的主用数据库服务器将切换到辅助类型。
解析：
对于需要automaticfail-over的系统来说，DRAUTO＝2是唯一的选择。
2．DRINTERVAL：
该参数确定主数据库服务器将HDR缓冲区的内容同步或异步发送至辅助数据库服务器的发送模式。
－1，0～N
DRINTERVAL＝－1，表示同步更新模式。
DRINTERVAL＝1～N，表示异步更新模式，且指定了2次发送HDR缓冲区之间的最大时间间隔（秒）。
DRINTERVAL＝0，？
（1）当使用同步更新模式时，不管数据库的日志带不带缓冲，不管发生可控的HDR失败或不可控的HDR失败，辅助数据库服务器上的事务始终同主用数据库服务器上的保持一致，因为主用数据库服务器在发送HDR缓冲区内容以后，必须等到辅助数据库服务器的接收响应后才能将逻辑日志刷新到磁盘上去。
（2）当使用异步更新模式时，不管数据库的日志带不带缓冲，只要发生的是可控的HDR失败，则辅助数据库服务器上的事务始终同主用数据库服务器上的保持一致；
但如果发生的是不可控的HDR失败，则辅助数据库服务器就有可能丢失已在主用数据库服务器上提交的事务。
显然，在辅助数据库服务器切换为主用时，原已在主用数据库服务器上提交的事务就会在新主用数据库服务器上丢失，因为此时HDR缓冲区内容因HDR失败而没有被辅助数据库服务器接收到。
而丢失已提交事务的多少则由数据库的逻辑日志带不带缓冲的模式来决定：
如果数据库在创建时把日志配置成nobuffer，则丢失当前事务；
如果数据库在创建时把日志配置成buffer，则丢失批量事务（多少由HDR缓冲区大小决定）。
3．DRTIMEOUT（单位：
秒）：
该参数指定HDR对中2个数据库服务器各自ping进程的等待对方TCP/IP传输响应的时间长度，而最终确认双方通信网络已全部出现故障而导致HDR失败的最大等待时间为WAIT_TIME，即需要连续4次ping进程才能完成“HDR失败”的确认。
其计算公式为:
DRTIMEOUT=WAIT_TIME/4。
例如：
设WAIT_TIME＝120秒，则DRTIMEOUT＝120/4=30秒。
即HDR对的全部通信网络中断120秒后，HDR失败就发生了。
该HDR失败在online.log中报错的消息为“hh:
mm:
ssDR:
pingtimeout”。
DRTIMEOUT的值将直接影响到HDR的切换速度。
当HDR通信网络中断的这种HDR失败发生后，辅助数据库服务器将一直要等到DRTIMEOUT×
4的时间到达后才能接管。
4．DRLOSTFOUND：
该参数指定dr.lostfound文件的全路径名。
当不可控的HDR失败后，接管主用数据库的原辅助数据库服务器在逻辑恢复期间将回滚所有打开（未提交）的事务，并将其所对应逻辑日志记录写入该文件。
为确保该文件不被覆盖，HDR在每次生成的文件名后附上时间戳，即dr.lostfound.timestamp。
也就是说，如果出现该文件，即意味着切换前在原主用数据库服务器上已提交的事务在切换后新主用数据库服务器上已丢失。
解析：
如能解读该文件，则事后有可能恢复丢失的事务。
该文件为HDR双机热备系统提供了监控事务丢失的手段。
1．HDR的创建和启动
假设scp1（别名为scp1_net）为主用数据库服务器名，scp2（别名为scp2_net）为辅助数据库服务器名。
在主用机和辅助机上分别安装好数据库，并做好相关调整。
在主用机和辅助机上分别配置好onconfig，sqlhosts，services等文件。
以下为创建HDR的步骤：
（1）在主用机上启动数据库：
informix%oninit
（2）在主用机上做数据库0级备份：
informix%ontape–s–L0
（3）在主用机上将SCP1指定为主用数据库服务器，将SCP2指定为辅助数据库服务器：
informix%onmode–dprimaryscp2_net
（4）在辅助机上使用主用机数据库备份恢复数据库：
informix%ontape-p
（5）在辅助机上将SCP1指定为主用数据库服务器，将SCP2指定为辅助数据库服务器：
informix%onmode–dsecondaryscp1_net
当以上步骤都已成功完成后，HDR即已启动生效。
使用“onstat–”命令分别可在主用机和辅助机上看到HDR状态：
SCP1:
On-Line（Prim）
数据库可读可写，在HDR对中为主用
SCP2:
Read-Only（Sec）
数据库可读不可写，在HDR对中为辅助
有关informix数据库和HDR的安装，配置和启动等的详细信息，请参考厂商提供的安装手册。
三．HDR的数据复制过程与事务丢失
1．HDR如何工作
当HDR在工作时，主数据库服务器处于联机状态并接受更新和查询（如同标准数据库服务器一样）。
而辅助数据库服务器处于逻辑恢复方式，无法接受可导致对磁盘写入的SQL语句（排序和临时表除外）。
数据复制的过程见图1。
图1HDR的数据复制过程
其中：
（1）HDR缓冲区－》接收缓冲区的发送由主用数据库服务器的发送线程drprsend完成
（2）HDR缓冲区－》接收缓冲区的接收由辅助数据库服务器的接收线程drsecrcv完成
显然，在HDR对网络连接正常的情况下，双方各自判定发送进程或接收进程失效而导致HDR失败的最大等待时间应为DRINTERVAL。
（3）接收缓冲区－》恢复缓冲区的复制由线程drsecapply完成
（4）对恢复缓冲区中的内容执行逻辑恢复由线程logrecvr完成
（5）HDR对的网络链接是否完好的判定分别由线程drprping和线程drsecping独自完成。
显然，双方各自判定网络失效而导致HDR失败的最大等待时间为DRTIMEOUT×
4。
2．复制主用数据库服务器的更新
主用数据库服务器通过将其所有逻辑日志记录发送至辅助数据库服务器上复制对主数据库服务器的更新；
辅助数据库服务器通过接收主数据库服务器上的的逻辑日志记录并将其应用到它的数据库空间来完成数据复制。
（1）如何发送逻辑日志记录
如图1所示，当主数据库服务器将共享内存中的逻辑日志缓冲区的内容刷新到磁盘上的逻辑日志文件时，同时也将其写入到HDR缓冲区（HDR缓冲区的大小同逻辑日志缓冲区的大小一样），然后主用数据库服务器将HDR缓冲区的内容通过HDR对的通信网络将其发送至辅助数据库服务器。
辅助数据库服务器将来自主数据库服务器的逻辑日志记录接收到共享内存中的接收缓冲区（数据库服务器自动将接收缓冲区调节至适当的大小以适应正在发送的数据量）。
然后辅助数据库服务器在持续运行的逻辑恢复中应用此逻辑日志记录，使其数据库中的数据同主数据库保持一致。
（2）何时发送逻辑日志记录
主数据库服务器何时把HDR缓冲区中的逻辑日志记录发送至辅助数据库服务器，完全取决于数据库配置文件中的DRINTERVAL参数。
当DRINTERVAL被配置为-1时，则HDR数据复制模式为同步模式。
主数据库服务器在将逻辑日志缓冲区内容刷新到磁盘上的逻辑日志文件的同时将其写入HDR缓冲区，HDR相关线程就会将这些记录从HDR缓冲区发送至辅助数据库服务器。
仅当主数据库服务器接收到来自辅助数据库服务器的确认（已收到记录）之后，主数据库服务器上的逻辑日志缓冲区刷新才算完成。
这就意味着使用同步更新模式时，不管发生可控的HDR失败还是不可控的HDR失败，在主数据库服务器上已提交的事务不会在辅助数据库服务器上出现未提交或部分提交的情况。
两者保持完全一致。
当DRINTERVAL被配置为非－1时，则HDR数据复制模式为异步模式。
（1）当数据库的逻辑日志配置为nobuffer时，则主数据库服务器在事务提交后立即将该事务对应的逻辑日志写入到磁盘上的逻辑日志文件，同时将其写入HDR缓冲区，并立即向辅助数据库服务器发送。
显然，当发生不可控的HDR失败时，辅助数据库服务器将丢失已在主用数据库服务器上提交的当前事务。
在辅助数据库服务器切换为主用数据库服务器后，由于没有任何未提交的事务，故不需要做回滚操作。
（2）当数据库的逻辑日志配置为buffer时，则主数据库服务器在逻辑日志缓冲区满时将其内容刷新到磁盘上的逻辑日志文件，同时将其写入HDR缓冲区，并立即清除逻辑日志缓冲区。
当发生以下条件之一时，主数据库服务器在整个网络上发送HDR缓冲区的内容：
1.HDR缓冲区满。
2.自上次将记录发送至辅助数据库服务器以后，DRINTERVAL配置参数在主数据库服务器上指定的时间间隔已经过去。
显然，当发生不可控的HDR失败时，辅助数据库服务器将丢失在当前HDR缓冲区中的所有事务（在主用数据库服务器上提交和未提交的）。
在辅助数据库服务器切换为主用数据库服务器后，由于存在未提交的事务，故需要做回滚操作。
而回滚操作将把所有在辅助数据库服务器上未提交的事务记录在dr.lostfound.yyyymmddhhmmss文件中。
回滚操作过程见图2。
图2回滚操作产生了dr.lostfound文件
如果在HDR切换后新主用数据库服务器的机器上出现dr.lostfound文件，则表示已丢失了某些事务。
新主用数据库服务器无法重新应用dr.lostfound文件中的事务记录，因为在辅助数据库服务器在充当主用数据库服务器时可能已发生有冲突的更新。
将前面关于事务丢失的所有讨论归纳一下，即成表1。
序号
发送模式
日志缓冲与否
HDR失败可控与否
主辅事务一致性
对业务影响
对系统性能影响
1
同步
无关
一致
无
2
异步
日志无缓冲
可控
不可控
辅机丢失当前事务
小
3
日志有缓冲
辅机丢失批量事务
大
表1辅助数据库服务器丢失在主用数据库服务器上已提交事务的归纳
而现网应用系统典型的informix-HDR配置数据如下:
（InformixDynamicServerVersion7.31.UD6W5）
Database创建时配置带缓冲的日志（buffer）模式
DRAUTO=2（automaticfailover）
DRINTERVAL=1（异步更新，发送间隔时间＝1秒）
DRTIMEOUT=30（HDR对中的数据库服务器确定双方链接丢失的最大等待时间（秒）的1/4）
DRLOSTFOUND=/opt/informix/etc/dr.lostfound
即现网典型HDR配置数据在表中为第3项，即当不可控的HDR失败发生后，我们将不得不面对大量事务丢失的局面。
从上述HDR机制解析和表1中我们可以看出，尽管HDR提供了很好的系统高可用性（例：
双磁阵保证无单点故障，双机业务切换速度快等），但却在某些小概率事件发生时无法保证已提交的事务不被丢失。
而丢失事务的后果是显而易见的，它将对业务造成极大的混乱。
该扣费的没有扣，已充值的帐户又回到充值前的余额，该产生的话单没有产生等等。
因此，当在网用户数达到百万级时，我们将不得不提出以下一些初步想法：
1．如果维持目前的HDR配置和数据库日志模式，则：
（1）必须实时或定时监视HDR切换可能产生的dr.lostfound文件。
（2）必须能正确解读dr.lostfound文件，并将其转换为对应的MML批处理文件，以便在新主用数据库服务器上执行恢复。
（3）如果无法解读dr.lostfound文件，则需通过其他途径来产生类似的恢复文件。
（4）当主备双机在时间上同步以后，是否可通过某时点对2个数据库某些数据的统计得到一致或不一致的稽核报告。
（5）
2．如果将数据库改为不带缓冲的日志模式，则：
（1）需评估系统性能将会由此下降多少？
（2）需考虑丢失的当前事务能不能找到？
（3）此模式应用的案例分析报告？
（4）
3．如果将数据更新模式改为同步模式（INTERVAL=-1），则：
（2）除了影响系统性能外，该模式是否会带来其他问题？
五．HDR相关术语解释
1．HDR失败
HDR失败的定义就是HDR对中的2个数据库服务器之间的链接丢失。
（1）当连接HDR对的TCP/IP网络正常时，HDR失败的认定是由主数据库服务器上的drprsend线程和辅助数据库服务器drsecrcv线程各自独立完成的，即2个线程在INTERVAL设定的时间过后未收到对方的消息，就认定发生了HDR失败，并在online.log中报错（hh:
receiveerror）。
特别警示：
当这种HDR失败发生后，辅助数据库服务器将立即接管主用数据库服务器。
一般来说，这种情况的发生的原因是由于主用数据库服务器down所致。
但如果是其他未知原因导致这种情况的发生，则是非常危险的，因为未知原因不一定是CLUSTER事件，即可能会出现数据库服务器做了切换而主备机并没有切换的现象！
此观点需探讨。
（2）当连接HDR对的全部TCP/IP网络异常时，HDR失败的认定是由主数据库服务器上的drprping线程和辅助数据库服务器drsecping线程各自独立完成的，即2个线程在网络中断后最多连续向对方发出4次ping信号（每次时长为DRTIMEOUT值，单位为秒）后而没有收到1次响应，则认定HDR失效，并在online.log中报错（hh:
pingtimeout）。
如果在4次ping信号期间收到1次响应，则不认定HDR失效。
HDR链接自行恢复。
当这种HDR失败发生后，辅助数据库服务器将接管主用数据库服务器。
但如果在4次ping的确认过程中网络恢复了正常，则HDR失败就不会发生，辅助数据库服务器也不会接管主用数据库服务器。
但主机的主备网络全部中断作为CLUSTER事件会导致主备机做双机CLUSTER切换，而CLUSTER切换会把主用数据库服务器关闭。
所以较长的网络中断确认时间只适用于HDR，而不适用于HACMP+HDR。
因为较大的DRTIMEOUT值只会使辅助数据库服务器接管延迟，从而导致业务中断的时间增加。
2．可控的和不可控的HDR失败
（1）可控的HDR失效发生的场景：
（1）人工命令关闭主用数据库（例：
onmode-ky）
（2）人工命令做CLUSTER切换（例：
smitcluster
――takeover）
（3）其他能够正常关闭主用数据库的场景
当主用数据库被正常关闭时，主用数据库服务器的checkpoint被触发，主数据库服务器保证其物理一致性和逻辑一致性。
HDR保证将最后一个HDR缓冲区内容发送至辅助数据库服务器，并同辅助数据库服务器进行checkpoint同步。
此后，主数据库服务器才被正常关闭。
故在可控的HDR失败发生后，辅助数据库服务器上的数据同主用数据库服务器上的数据是一致的。
（2）不可控的HDR失效发生的场景：
（1）主用机宕机（软硬件原因，断电）
（2）主用数据库服务器宕掉（软件原因，误操作）
（3）网络故障导致HDR对连接全部中断
（4）数据库相关进程执行时间延迟过长
（5）其他非正常关闭主用数据库的场景
当主用数据库被非正常关闭时，主数据库服务器的checkpoint已无法被触发，即主数据库服务器无法保证物理一致性（丢失物理日志缓冲区内容），无法保证逻辑一致性（丢失逻辑日志缓冲区内容）。
HDR无法保证将最后一个HDR缓冲区内容发送至辅助数据库服务器。
故在不可控的HDR失败发生后，辅助数据库服务器上的数据同主用数据库服务器上的数据可能不一致。
不一致的标志就是在新主用数据库服务器上出现了dr.lostfound.yyyymmddhhmmss文件。
3．物理一致性
对数据库所做的所有更新都已从共享内存页缓冲区同步到磁盘上的数据文件。
4．逻辑一致性
已向应用程序发出提交响应信号的事务在数据库中已真实完成。
5．Checkpoint发生时数据库服务器所做的操作
（1）阻止用户线程进入临界段
（2）将逻辑日志缓冲区写入磁盘当前逻辑日志文件
（3）将物理日志缓冲区写入磁盘物理日志文件
（4）将页缓冲区内容写入磁盘相应页（数据文件）中
（5）将Checkpoint完成记录写入逻辑逻辑日志文件
（6）清空物理日志缓冲区
在HDR正常工作时，checkpoint由主用数据库服务器发起，并与辅助数据库服务器同步，即需要得到辅助数据库服务器的确认响应。
如果在1个DRTIMEOUT时间内没有得到辅助数据库服务器的确认响应，主用数据库服务器即认为发生了HDR失败。
但这种HDR失败并不会导致HDR切换，而仅仅是关闭HDR，只做自已单个数据库的checkpoint，而不再将2个数据库捆绑在一起做checkpoint。
除非HDR又恢复正常工作。
五．参考资料
1．Administrator'
sGuideforInformixDynamicServer,Version7.3.pdf
2．IBMInformixDynamicServerAdministrator'
sGuide,Version9.4.pdf
3．IBMInformixDynamicServerAdministrator'
sReference,Version9.4.pdf
4．现网典型的数据库服务器配置文件onconfig（scp1,scp2）
5．现网典型的数据库服务器的日志文件online.log（scp1,scp2）
完成于2008。
9。
16
升级会员 