INFORMIX-HDR 机制与事务丢失
- 格式:doc
- 大小:126.50 KB
- 文档页数:23
《INFORMIX-HDR机制与事务丢失》 目录 说明 一. HDR的参数解析 二. HDR的创建和启动 三. HDR的数据复制过程与事务丢失 四. 事务丢失后的应对之策 五. HDR相关术语解释(重要) 六. 参考资料
说明 INFORMIX-HDR(High Availability Data Replication)高可用数据复制是IBM Informix Dynamic Server为保证数据库应用高可用性而提出的双机热备企业级解决方案,即由1个主用数据库服务器和1个辅助数据库服务器构成一个HDR对。HDR一旦被启动以后,HDR对中的主用数据库服务器上数据的任何变化在有限的时间内都将被一一复制到HDR对中的辅助数据库服务器。一旦在主用数据库服务器上发生可控或不可控的HDR失败事件,HDR将提供自动或手动切换,由辅助数据库服务器快速接管后充当主用数据库服务器,以满足24小时×7天不间断的业务要求。 本文试图从HDR机制分析入手,通过展现HDR参数,HDR各种数据复制模式的运行过程,HDR失败的不同原因等,来求解导致事务丢失的场景及相关对策,以便于在今后的维护工作中能够做到预防在先,把目前应用系统先天缺陷可能对业务造成的影响降低到最低水平。 由于本人初涉INFORMIX-HDR,浏览资料和实践经验均有限,部分观点尚未得到证实,故缪误将在所难免。但在百万级用户的预付费系统即将上线的任务驱使下,在此大胆成文,亮出个人见解。望各位同仁在阅读后质疑指正,共同探讨面临的难题。 文后列出了本人参考的中英文资料,供各位取舍。若有相关案例及参考资料,麻烦诸位发送出来共享,在此先致谢了!
一. HDR的参数解析 HDR参数在数据库配置文件onconfig中配置。HDR相关参数共有4个,这些参数值的设定在HDR对中的2个数据库服务器上应相同,否则可能会导致不可预期的后果。下面分别对这4个参数做详细说明: 1. DRAUTO: 该参数确定辅助数据库服务器响应HDR失败的模式。 取值范围:0,1,2 DRAUTO=0 表示 OFF。即在HDR失败时不自动切换服务器类型。辅助数据库服务器将以只读方式继续保持辅助类型。 DRAUTO=1 表示 RETAIN_TYPE。即在HDR失败时辅助数据库服务器类型自动从辅助切换到标准。而当HDR链接恢复时,原来的辅助数据库服务器将自动切换回辅助类型。 DRAUTO=2 表示 REVERSE_TYPE。即在HDR失败时辅助数据库服务器自动从辅助切换到主用。当HDR链接恢复时,原来辅助数据库服务器仍为主用类型,而原来的主用数据库服务器将切换到辅助类型。 解析: 对于需要automatic fail-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:ss DR: ping timeout”。 解析: DRTIMEOUT的值将直接影响到HDR的切换速度。当HDR通信网络中断的这种HDR失败发生后,辅助数据库服务器将一直要等到DRTIMEOUT×4的时间到达后才能接管。
4.DRLOSTFOUND: 该参数指定dr.lostfound文件的全路径名。当不可控的HDR失败后,接管主用数据库的原辅助数据库服务器在逻辑恢复期间将回滚所有打开(未提交)的事务,并将其所对应逻辑日志记录写入该文件。为确保该文件不被覆盖,HDR在每次生成的文件名后附上时间戳,即dr.lostfound.timestamp。也就是说,如果出现该文件,即意味着切换前在原主用数据库服务器上已提交的事务在切换后新主用数据库服务器上已丢失。 解析: 如能解读该文件,则事后有可能恢复丢失的事务。 该文件为HDR双机热备系统提供了监控事务丢失的手段。
二. HDR的创建和启动 1. HDR的创建和启动 假设scp1(别名为scp1_net)为主用数据库服务器名,scp2(别名为scp2_net)为辅助数据库服务器名。 在主用机和辅助机上分别安装好数据库,并做好相关调整。 在主用机和辅助机上分别配置好onconfig,sqlhosts,services等文件。 以下为创建HDR的步骤: (1) 在主用机上启动数据库: informix% oninit (2) 在主用机上做数据库0级备份: informix% ontape –s –L 0 (3) 在主用机上将SCP1指定为主用数据库服务器,将 SCP2指定为辅助数据库服务器: informix% onmode –d primary scp2_net (4) 在辅助机上使用主用机数据库备份恢复数据库: informix% ontape -p (5) 在辅助机上将SCP1指定为主用数据库服务器,将 SCP2指定为辅助数据库服务器: informix% onmode –d secondary scp1_net
当以上步骤都已成功完成后,HDR即已启动生效。使用“onstat –”命令分别可在主用机和辅助机上看到HDR状态: SCP1: On-Line (Prim) 数据库可读可写,在HDR对中为主用 SCP2: Read-Only (Sec) 数据库可读不可写,在HDR对中为辅助
有关informix数据库和HDR的安装,配置和启动等的详细信息,请参考厂商提供的安装手册。
三.HDR的数据复制过程与事务丢失 1.HDR如何工作 当HDR在工作时,主数据库服务器处于联机状态并接受更新和查询(如同标准数据库服务器一样)。而辅助数据库服务器处于逻辑恢复方式,无法接受可导致对磁盘写入的SQL语句(排序和临时表除外)。 数据复制的过程见图1。
图1 HDR的数据复制过程 其中: (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对的通信网络将其发送至辅助数据库服务