informix数据库高可用集群技术及应用实现

1、Informix 11.5 高可用集群技术及应用实现本文主要介绍了 Informix 11.5 中提供的高可用集群技术及其安装、配置、管理的根本方法，各种高可用集群技术的选择及应用场景，希望能够使读者能够对 Informix 11.5 高可用集群技术有一个比拟全面的了解。概述用户的关键业务系统，特别是 OLTP 系统，都要求提供 24X7 不间断的应用效劳，这就要求数据库系统能够提供强大的高可用能力。这种能力不仅仅表达在主机及备机的接管方面，同时要能够提供远程容灾能力，以及本地的负载均衡能力。针对上述对数据库的要求，Informix 从版本 6 开始， 就提供了 HDR 技术，它是通过数据库的

2、事务日志的方式实现了主、备机互相接管的功能，当主机工作时，备机提供只读功能，因此，备机可以提供查询、报表等功能，实现负载分担的功能，当主机发生故障，备时机自动接管，实现主机及备机的接管功能。从 Informix 7.2.2 版本开始，Informix 数据库提供了 ER(Enterprise Replication) 数据库复制技术，它也是通过读取数据库日志的方式实现数据同步功能，当源数据库数据发生变化后，Informix 数据库通过读取数据库日志，将变化的数据及时同步到目标数据库，采用 ER 的方式，和 HDR 不同，HDR 数据库的接管是基于数据库效劳器的，也就是它的作用范围是基于整个实例

3、的，而 ER 的作用范围是作用于一个表，你可以灵活定义需要复制哪些数据列及数据行，而且可以灵活定义数据复制的方式，是采用主从方式、汇总方式还是双向复制方式。从 Informix 11 开始，Informix 数据库提供了 SDS(Shared Disk Secondary)、RSS(Remote Standalone Secondary)、CLR(Continuous Log Restore) 等高可用集群技术，提供了更加强大的高可用能力。从 Informix 11.5 开始，HDR、SDS、RSS 备机都支持读写能力，提供了更强大的负载均衡能力。同时，从 Informix 11.5 开始，I

4、nformix 还提供了 Connection Manager 功能部件，它可以提供 SLA(Service Level Agreement) 功能，更好地实现负载均衡的能力，同时提供了 FOC(Fail Over Connection) 功能，实现透明故障接管能力，而且，所有这些对客户端应用来说是透明的。通过不断的开展与创新，Informix 提供了业界领先的高可用集群技术。下边，我们就具体讲述一下 Informix 高可用集群技术特点、使用范围及技术实现，希望读者能够对它有一个更全面的理解。HDR 技术高可用性数据复制 HDR 技术，从 Informix 6 版本就开始提供，它是采用一主、

5、一备方式，通过读取数据库逻辑日志方式，实现主备机互相切换功能。在 Informix 11.5 之前， HDR 备机支持只读方式，我们通常会通过备机来完成数据查询、报表功能，分担主机系统的压力。从 Informix 11.5 开始， HDR 备机支持读写操作，提供了更灵活的功能。 HDR 方式通常用来提供高可用性及 hot standby 功能。HDR 工作的根本原理图 1. HDR 工作原理例如图如图中所示，当主数据库效劳器开始将共享内存中的逻辑日志缓冲区的内容刷新到磁盘上的逻辑日志时，数据库效劳器也将逻辑日志缓冲区的内容复制到主数据库效劳器上的数据复制缓冲区。然后主数据库效劳器将这些逻辑日志

6、记录发送至 HDR 辅助数据库效劳器。HDR 辅助数据库效劳器将来自主数据库效劳器的逻辑日志记录接收到共享内存接收缓冲区数据库效劳器自动将接收缓冲区调节至适当的大小以适合正在发送的数据量。然后辅助数据库效劳器在整个逻辑恢复中应用逻辑日志记录 , ，并将这些记录应用到其自己的数据库空间。HDR 数据复制支持同步或异步两种方式。 ONCONFIG 配置参数 DRINTERVAL 的值确定数据库效劳器使用同步更新还是异步更新。如果将 DRINTERVAL 设置为 -1，那么对 HDR 辅助效劳器的数据复制同步发生。一旦主数据库效劳器将逻辑日志缓冲区内容写入 HDR 缓冲区，它会将那些记录从缓冲区发送

7、至 HDR 辅助数据库效劳器。仅当主数据库效劳器接收到来自 HDR 辅助数据库效劳器确实认已收到记录之后，主数据库效劳器上的逻辑日志缓冲区清仓才会完成。使用同步更新时，如果发生故障，那么在主数据库效劳器上提交的事务在 HDR 辅助数据库效劳器上不会仍未提交或局部提交。如果您将 DRINTERVAL 设置为除 -1 以外的任何值，那么数据复制将针对 HDR 辅助效劳器异步发生。主数据库效劳器在将逻辑日志缓冲区内容复制到 HDR 缓冲区之后会清仓逻辑日志缓冲区。与上述操作无关当发生以下条件之一时，主数据库效劳器在整个网络上发送 HDR 缓冲区的内容：HDR 缓冲区变满。自上次将记录发送至辅助数据库

8、效劳器以后，DRINTERVAL 配置参数在主数据库效劳器上指定的时间间隔已过去。该更新方法可以提供比同步更新更好的性能。但是，可能会丧失事务。HDR 处理数据复制的线程主数据库效劳器启动专门的线程来支持数据复制。如图 2 所示，主数据库效劳器上名为 drprsend 的线程将整个网络上主效劳器缓冲区的内容发送至辅助数据库效劳器上名为 drsecrcv 的线程。辅助数据库效劳器上名为 drsecapply 的线程将接收缓冲区的内容复制到恢复缓冲区。 logrecvr 线程对恢复缓冲区的内容执行逻辑恢复，将逻辑日志记录应用到辅助数据库效劳器管理的数据库空间。 OFF_RECVRY_THREADS

9、 配置参数指定使用的 logrecvr 线程数。数据库效劳器启动的其余线程是 drprping 和 drsecping 线程，它们负责发送和接收指示两个数据库效劳器是否连接的消息。图 2. HDR 数据复制线程例如图HDR 主、备机之间采用半双工通信协议，因此对网络延迟非常敏感，通常要求网络要非常稳定，同时距离支持有限，通常在同一个大楼里面。HDR 配置实现HDR 对硬件和操作系统要求：运行主数据库效劳器和辅助数据库效劳器的计算机必须相同相同的供给商和体系结构。运行主数据库效劳器和辅助数据库效劳器的计算机上的操作系统必须相同。运行主数据库效劳器和辅助数据库效劳器的硬件必须支持网络能力。分配给主

10、数据库效劳器和辅助数据库效劳器的数据库空间的磁盘空间量必须相等。磁盘空间类型是不相关的；您可以在两个数据库效劳器上使用任何原始或格式化的空间组合。HDR 对数据库和数据要求：数据库必须将事务日志记录翻开。数据必须驻留在数据库空间或 Sb 空间中。HDR 对配置参数的要求：以下 ONCONFIG 参数在每个数据库效劳器上都必须具有相同值：ROOTNAMEROOTOFFSETROOTPATHROOTSIZEMIRROROFFSETMIRRORPATHPHYSDBSPHYSFILELTAPEBLKLTAPESIZETAPEBLKTAPESIZELOGFILESLOGSIZEDYNAMIC_LOGS数

11、据库效劳器记录逻辑日志文件的添加。在主效劳器上动态添加的逻辑日志文件将在辅助效劳器上自动复制。尽管辅助效劳器上的 DYNAMIC_LOGS 值不起作用，请保持主效劳器上 DYNAMIC_LOGS 与值的同步，以免它们切换角色。HDR 配置参数在复制对中的两个数据库效劳器上必须设置为相同的值：· DRAUTO· DRINTERVAL· DRTIMEOUTHDR 相关配置参数说明：· DRAUTO：用来控制主效劳器和 HDR 备用效劳器在出现故障时的行为。其取值范围如下 :o 0 表示 OFF = 不要在 HDR 环境中自动切换效劳器类型。o 1 表示 RE

12、TAIN_TYPE = 在 HDR 故障期间自动从辅助切换到标准。在重新启动 HDR 时切换回辅助。o 2 表示 REVERSE_TYPE= 在 HDR 故障时自动从辅助切换到标准。在重新启动 HDR 时切换到主要并将原来的主要切换为辅助。· DRIDXAUTO：指定如果 HDR 辅助效劳器检测到了毁坏的索引，主效劳器是否要自动启动索引复制。其取值范围如下 :o 0 - 禁用自动索引修复o 1 - 启用自动索引修复· DRINTERVAL：指定高可用性数据复制缓冲区的清仓之间的最大时间间隔秒。其取值范围如下 :o >= 0 - 异步更新o -1 - 同步更新·

13、; DRLOSTFOUND：指定 dr.lostfound.timestamp 文件的路径名。该文件包含当主数据库效劳器遇到故障时在主数据库效劳器上提交但未在辅助数据库效劳器上提交的事务。如果在主数据库效劳器和辅助数据库效劳器之间同步发生更新即，如果 DRINTERVAL 设置为 -1，那么此参数不适用。· DRTIMEOUT：出现网络超时的时间，以秒为单位。 DRAUTO 使用该参数检测故障转移。其取值范围如下 :>= 0 秒 , 缺省为 30 秒向集群中添加 HDR 备用效劳器向集群添加一个 HDR 备用效劳器的具体步骤：步骤1：准备 SQLHOSTS 文件在主效劳器更新

14、SQLHOSTS 文件，同时在 HDR 备用效劳器中更新：production onsoctcp server_1 prod_tcp sds1 onsoctcp server_1 sds1_tcp hdr1 onsoctcp server_1 hdr1_tcp rss1 onsoctcp server_1 rss1_tcp clr1 onsoctcp server_1 clr1_tcp步骤2：配置 ONCONFIG 文件保证 HDR 备用效劳器上的 DRAUTO、DRINTERVAL、DRTIMEOUT、与根 dbspace 相关的设置、与物理日志、逻辑日志相关的 ONCONFIG 配置参数同

15、主效劳器上保持一致。步骤3：备份主效劳器在主效劳器中，使用 0 级备份：ontape -s -L 0步骤4：将 HDR 备份效劳器注册到主效劳器在主效劳器中，运行：onmode -d primary hdr步骤5：准备 HDR 备用效劳器的磁盘HDR 备用效劳器使用的存储必须匹配主效劳器的存储例如，必须匹配 dbspace 的数量、块的数量、块大小、路径名和偏移量。步骤6：恢复 HDR 备用效劳器上的备份在 HDR 效劳器上，执行 0 级备份的物理恢复：ontape -p Three questions will be asked. Answer as shown below: Continu

16、e restore? (y/n) y Do you want to back up the logs? (y/n) n Restore a level 1 archive (y/n) n步骤7：使 HDR 备用效劳器进入 online 模式完成恢复后，HDR 备用效劳器将进入 recovery 模式。运行以下命令：onmode -d secondary productionHDR 状态监控onstat 命令每次执行 onstat 时显示的头信息均有字段指示数据库效劳器正在作为主数据库效劳器还是辅助数据库效劳器运行。以下例如为作为复制对中的主数据库效劳器并且处于联机方式的数据库效劳器显示头信息：

17、IBM Informix Dynamic Server Version 11.50.UC1 - On-Line (Prim) - Up 00:00:59 - 105120 Kbytes以下例如显示作为复制对中的 HDR 辅助数据库效劳器并且处于读写方式的数据库效劳器：IBM Informix Dynamic Server Version 11.50.UC1 - Updatable (Sec) - Up 00:00:59 - 105120 Kbytes以下例如显示不包含在 HDR 中的数据库效劳器的标题。该数据库效劳器的类型为标准类型。IBM Informix Dynamic Server Ve

18、rsion 11.50.UC1 - On-Line - Up 00:00:59 - 105120 Kbytesonstat -g dri 命令要获得完整的 HDR 监视信息，请执行 onstat -g dri 选项。显示以下字段：· 数据库效劳器类型主类型、辅助类型或标准类型· HDR 状态翻开或关闭· 成对的数据库效劳器· 最后一个 HDR 检查点· HDR 配置参数的值oncheck pr 命令如果您的数据库效劳器正在运行 HDR，那么保存页面 PAGE_1ARCH 和 PAGE_2ARCH 将保存 HDR 用于同步主数据库效劳器和辅助数据

19、库效劳器的检查点信息。下列图中给出相关的 oncheck -pr 输出例如。运行 HDR 的数据库效劳器的 oncheck -pr PAGE_1ARCH 输出 :Validating Informix Database Server reserved pages - PAGE_1ARCH & PAGE_2ARCH Using archive page PAGE_1ARCH. Archive Level 0 Real Time Archive Began 01/11/95 16:54:07 Time Stamp Archive Began 11913 Logical Log Unique

20、 Id 3 Logical Log Position b018 DR Ckpt Logical Log Id 3 DR Ckpt Logical Log Pos 80018 DR Last Logical Log Id 3 DR Last Logical Log Page 128使用 SMI 表 sysdri查询 sysmaster 数据库中的 sysdri 表，同样可以获得完整的 HDR 监视信息。 sysdri 表包含以下各列。列描述typeHDR 效劳器类型stateHDR 效劳器状态name数据库效劳器名称intvlHDR 缓冲区清空时间间隔timeout网络超时lostfoundHD

21、R lost+found 路径名HDR 故障恢复HDR 的失败是失去了复制对中数据库效劳器之间的连接。任一以下情况均可能导致数据复制失败：· 一个数据库效劳器的站点上发生灾难性故障如火灾或大地震· 连接两个数据库效劳器的联网电缆被破坏· 一个数据库效劳器上的处理中延迟过长· 辅助数据库效劳器上发生磁盘故障未通过镜像块解决HDR 故障的检测数据库效劳器将以下任何一种情况解释为 HDR 失败：· 超过了指定的超时值。在正常的 HDR 操作期间，数据库效劳器期待来自对中另一数据库效劳器的通信确认。对中的每个数据库效劳器都具有一个 ONCONFIG 参

22、数 DRTIMEOUT，该参数指定秒数。如果来自对中另一数据库效劳器确实认没有在 DRTIMEOUT 指定的秒数返回，那么数据库效劳器会假设发生了 HDR 失败。· 主 辅助对中的另一数据库效劳器未响应网络上的定期消息传递pinging尝试。无论主数据库效劳器是否向辅助数据库效劳器发送任何记录，两个数据库效劳器均会互相 ping 。如果主要 辅助对的一个数据库效劳器没有响应四个连续的 ping 尝试，那么另一个数据库效劳器会假设发生了 HDR 失败。当数据库效劳器检测到 HDR 失败时，它将写一个消息到其消息日志例如，DR: receive error并关闭数据复制。如果发生了 HD

23、R 失败，那么两个数据库效劳器之间的 HDR 连接将断开，并且辅助数据库效劳器将保持只读方式。如果辅助数据库效劳器在 high-availability data-replication 失败后保持联机状态，并且 DRAUTO 配置参数设置为 1RETAIN_TYPE，那么该数据库效劳器的类型将自动更改为标准。如果 DRAUTO 设置为 0off，那么辅助数据库效劳器将顶事尝试重新建立与主数据库效劳器的通信。如果 DRAUTO 设置为 2REVERSE_TYPE，那么当旧的主效劳器发生故障时而非旧的主效劳器重新启动时，在连接结束时，辅助数据库效劳器将立即成为主数据库效劳器。RSS 技术从 In

24、formix 11 开始，Informix 数据库提供了 RSS 、SDS、CLR 技术，它扩展了以前 HDR 只支持主、备两台机器，系统可以支持多台 RSS 、SDS 备机，进一步提高了高可用性。 Informix 11 提出了一种新的通信方式 SMX(Server Multiplexer) 用来建立节点之间的网络连接。 SMX 采用全双工的通信协议，支持异步通信方式，在低速网络上提供更好的通信连接，简化了节点之间的通信管理，支持加密传输，同一个 SMX 连接可以支持多个内部功能传输。图 3. SMX 通信示意图RSS 自动启动 SMX 通信方式。RSS 工作的根本原理为支持 RS 辅助效劳

25、器，主效劳器要进行检查以查看是否连接了 RS 辅助效劳器，如果连接，那么将页面复制到用于将该页面发送到 RS 辅助效劳器的日志高速缓存。图 4. RSS 数据复制线程示意图RSS_Send 线程将日志页面传输到 RS 辅助效劳器。很有可能需要发送的下一页不在日志高速缓存中。在该情况下，RSS_Send 线程将直接从磁盘读取日志页。 RSS_Send 线程与 SMX 交互，以使用全双工方式发送数据。有了全双工通信，线程在发送下一个缓冲区之前不等待来自 RS 辅助效劳器确实认。在主效劳器需要来自 RS 辅助效劳器确实认之前最多可发送 32 个缓冲区传输。如果到达 32 个缓冲区的限制，那么发送线程

26、将等待 RSS_Recv 线程接收来自 RS 辅助效劳器确实认。在 RS 辅助效劳器上，RSS_Recv 与 SMX 交互，以接收来自主效劳器的日志页。RSS 在很多方面都与 HDR 相似。将日志发送到 RSS 的方式与主效劳器将日志发送到 HDR 辅助效劳器的方式很相似。但是，RSS 采用 SMX 异步通信框架，因此其对主效劳器的影响到达最小。出于该原因，主效劳器和 RSS 辅助效劳器之间事务落实或检查点均不是同步进行的。换句话说，不保证在主效劳器上落实的任何事务也在同一时间在 RSS 辅助效劳器上得到落实。因为 RSS 辅助效劳器是异步进行更新的，所以 RSS 辅助效劳器不能直接提升为主效

27、劳器。相反，它可以提升为 HDR 辅助效劳器，然后可提升为主效劳器。另外，HDR 辅助效劳器可降级为 RS 辅助效劳器。尽管 RS 辅助效劳器与 HDR 辅助效劳器类似，但有某些操作是 HDR 辅助效劳器可执行但 RS 辅助效劳器却不支持，例如：· RS 辅助效劳器不支持 SYNC 方式· RS 辅助效劳器不支持 DRAUTO· RS 辅助效劳器不具有同步检查点· RS 辅助效劳器不能直接转换为主效劳器RSS 备用效劳器的主要作用是提供灾难恢复解决方案。如同在 HDR 中一样，主效劳器不断将其所有的逻辑日志记录发送给 RS 备用效劳器，不过 RS 使用的

28、异步方式。与 HDR 不同，通信使用全双工协议。因此 RS 对网络延迟不是很敏感，并且可以更容易驻留在一个较远的地理位置。同时，如果节点间通信线路比拟差的情况下，页经常采用 RS 备用效劳器方式。 RS 备用效劳器的一个特点是主效劳器并不和 RS 备用效劳器同步检查点，这一点和 SD 和 HDR 效劳器不同。因此不能立即替代主效劳器；必须首先切换为一个 HDR 效劳器。RSS 配置实现硬件和软件需求RS 辅助效劳器维护物理数据库的完整副本。出于此原因，以下内容必须与主效劳器相同：· 运行数据库效劳器的计算机硬件· 分配给数据库空间的磁盘空间量· 创立数据库空间时使

29、用的物理设备中的偏移量索引页日志记录LOG_INDEX_BUILDS在创立索引时，索引页日志记录将各页写入到逻辑日志，以使高可用性环境中各效劳器之间的索引创立同步。要使用 RS 辅助效劳器，必须启用索引页日志记录。索引页日志记录将完整索引写入到日志文件，然后将该日志文件异步地传输到辅助效劳器。辅助效劳器可以是 RS 辅助效劳器，也可以是 HDR 辅助效劳器。然后，日志文件事务被读入到辅助效劳器上的数据库，减少辅助效劳器在恢复期间重新构建索引的需求。对于 RS 辅助效劳器，主效劳器不等待来自辅助效劳器确实认，这允许对主效劳器上索引的立即访问。索引页日志记录是使用 onconfig 参数 LOG_

30、INDEX_BUILDS 进行控制的。如果 LOG_INDEX_BUILDS 设置为 1已启用，那么在主效劳器上构建索引然后将索引发送到辅助效劳器。向集群中添加 RS 备用效劳器向集群添加一个 RSS 备用效劳器的具体步骤：步骤1：准备 SQLHOSTS 文件集群中的所有效劳器必须具有针对其他效劳器的 SQLHOSTS 条目。production onsoctcp server_1 prod_tcp sds1 onsoctcp server_1 sds1_tcp hdr1 onsoctcp server_1 hdr1_tcp rss1 onsoctcp server_1 rss1_tcp cl

31、r1 onsoctcp server_1 clr1_tcp步骤2：在主效劳器上，启用索引页面日志记录onmode -wf LOG_INDEX_BUILDS=1步骤3：在主效劳器上，注册新的RS备用效劳器onmode -d add RSS rss1步骤4：对主效劳器采取0级备份ontape -s -L 0步骤5：在RS备用效劳器中，恢复备份ontape -p Three questions will be asked. Answer as shown below: Continue restore? (y/n) y Do you want to back up the logs? (y/n) n

32、 Restore a level 1 archive (y/n) n步骤6：使RS备用效劳器进入online模式onmode -d RSS myprimRSS 状态监控onstat 命令每次执行onstat时显示的头信息均有字段指示数据库效劳器正在作为主数据库效劳器还是辅助数据库效劳器运行。以下例如显示作为复制对中的 RSS 辅助数据库效劳器并且处于读写方式的数据库效劳器：IBM Informix Dynamic Server Version 11.50.UC1 - Updatable (RSS)- Up 00:00:59 - 105120 Kbytes onstat -g rss 命令我们可

33、以在主效劳器和 RSS 节点中分别运行 onstat -g rss 命令查看 RSS 节点状态。 在主效劳器和 RSS 节点上的输出稍有不同。在主效劳器上运行 onstat -g rss 命令输出如下： Local server type: Primary Index page logging status: Enabled Index page logging was enabled at: 2007/02/20 18:10:01 Number of RSS servers: 3 RSS Server information: RSS Srv RSS Srv Connection Next

34、LPG to send Supports name status status (log id,page) Proxy Writes cdr_ol_nag_1_c1 Active Connected 7,899 Y cdr_ol_nag_1_c2 Active Connected 7,899 Y其中：· Local server type：是 Primary 还是 RSS (remote standalone secondary) 效劳器类型· Index page logging status： 显示索引页日志记录状态是否被激活· Index page logg

35、ing was enabled at：显示索引页日志记录激活的时间· Number of RSS servers：连接到主效劳器上 RSS 效劳器的数量· RSS Srv name: RSS 效劳器的名称· RSS Srv status: 显示 RSS 效劳器数否活动· Connection status：显示 RSS 效劳器是否已经连接· Next LPG sent (log id, page)：最近发送的 LPG log ID and page· Supports Proxy Writes：显示辅助效劳器是否可执行 update

36、操作，Y 代表支持，N 不支持在辅助效劳器上运行 onstat -g rss 命令输出如下：IBM Informix Dynamic Server Version 11.50.UC1 - Read-Only (RSS) - Up 00:05:18 - 55296 Kbytes Local server type: RSS Server Status : Active Source server name: cdr_ol_nag_1 Connection status: Connected Last log page received(log id,page): 7,877其中：· L

37、ocal server type：是 Primary 还是 RSS (remote standalone secondary) 效劳器类型· Server Status: 显示 RSS 效劳器是否活动· Source server name：主效劳器名称· Connection status：显示 RSS 效劳器是否已经连接· Last log page received (log id,page)：最近接受的 LPG log ID and pageRSS 故障切换在高可用集群环境中，数据库效劳器主要包含下述三种工作方式：效劳器方式说明标准方式不是数据复

38、制系统的一局部。主要方式数据复制系统的主要方式。可以更新数据。辅助方式数据复制系统的辅助方式。无法更新数据，但是可以读取数据。RSS 进行故障切换的根本原那么：· RSS 节点不能升级为主节点· DRAUTO 对 RSS 不起作用· RSS 节点可以转换为 HDR 辅助节点· HDR 辅助节点可以转变为 RSS 节点· RSS 节点可以转换为 standard nodeRSS 故障切换的根本方法及形式：将 RSS 节点升级为 HDR 辅助节点 :onmode d secondary <primary>将 RSS 节点转换为标准节点

39、:onmode d standard将 HDR 辅助节点装换为 RSS 节点 :onmode d RSS <primary>除去 RSS 节点 :onmode -d delete RSS rss_servernameSDS 技术与 HDR、RSS 不同，SDS 采用和主机共享磁盘方式，防止了数据重复存储的问题，节省了空间，同时安装、配置更加简单。而且，当主机发生故障后，它可以快速实现接管，另外，我们可以非常容易地配置多个 SDS，可以实现了负载均衡的功能。由于 SD 备用节点利用了主效劳器的磁盘并且可以轻松快速地启动，因而非常适合规模扩展场景，由于 SD 备用效劳器非常接近主效劳器

40、即它们共享相同的磁盘，因此最适合在主效劳器遇到问题时作为故障转移效劳器。SDS 工作的根本原理所有辅助效劳器类型都使用日志从主效劳器复制数据。对于 HDR 辅助效劳器和 RS 辅助效劳器可通过生成日志时使主效劳器将其所有逻辑日志记录发送到辅助效劳器，从而在辅助效劳器上复制对主效劳器所作的更新。 HDR 辅助效劳器和 RS 辅助效劳器接收在主效劳器上生成的逻辑日志记录，并将这些记录应用到其自己的数据库空间。对于 SD 辅助效劳器，如下图，同 HDR 辅助效劳器和 RS 辅助效劳器不同，主效劳器不是将整个日志进行发送，而只是将逻辑日志页的日志位置发送到 SD 辅助效劳器。通过使用从主效劳器接收到的

41、日志位置，SD 辅助效劳器从磁盘读取逻辑日志页，并将其应用于内存数据缓冲区。图 5. SDS 数据复制示意图SD 辅助效劳器不会向共享磁盘块中写任何东西，不会将共享内存的数据刷新到磁盘，即使是发生 checkpoint 操作也一样。如果 SD 辅助效劳器需要刷新共享内存数据，他们会备写到临时的 paging file 中，直到下一次 checkpoint 操作才清空 paging file 。同时，如下列图所示，主效劳器不会清仓共享内存中的数据页，直到确认 SDS 不在需要该数据页才会清仓到磁盘上。下列图显示了启动 SD 辅助效劳器的根本过程：SD 辅助效劳器首先创立到主效劳器的 SMX 连接

42、，之后，SD 辅助效劳器向主效劳器发出 checkpoint 请求，主效劳器响应 SD 辅助效劳器的 checkpoint 请求，并将相应 LSN 发送给 SD 辅助效劳器，SD 辅助效劳器启动必要的恢复操作，之后，主效劳器开始不断向 SD 辅助效劳器发送当前的 LSN，SD 辅助效劳器也开始不断向主效劳器发送 ACK 确认信息。图 6. SDS 数据复制工作原理示意图SDS 配置实现辅助效劳器的硬件和软件需求除了磁盘需求与主效劳器共享，硬件和软件需求与 HDR 辅助效劳器的需求相同。此外，具有数据库效劳器的计算机之间必须共享主磁盘系统。这表示从 SD 辅助效劳器到数据库空间的路径必须与主效劳

43、器的数据库空间路径相同。SDS 相关配置参数说明· SDS_ENABLE：用来启用 SD 辅助效劳器功能。您必须在主效劳器及 SD 辅助效劳器中将 SDS_ENABLE 都设置为 1启用，才能启用 SD 辅助效劳器功能。其取值范围：o 0 - 禁用 SDS 功能o 1 - 启用 SDS 功能· SDS_PAGING： 指定了两个要作为缓存器调页文件的文件的位置。如果未设置 SDS_PAGING，SD 辅助效劳器可能无法启动。在 SD 辅助效劳上设置该值。其取值范围：< 分页文件 1 的绝对路径 >，< 分页文件 2 的绝对路径 >· SDS

44、_TEMPDBS：指定 SD 辅助效劳器用于动态创立临时数据库空间的信息。为了启动 SD 辅助效劳器，SD 辅助效劳器的 ONCONFIG 文件中至少出现一次 SDS_TEMPDBS，最多可以配置为 16 SDS_TEMPDBS 条目。在 SD 辅助效劳上设置该值，主效劳器上不使用 SDS_TEMPDBS 。其取值范围：<dbspace_name>、< 路径 >、< 页面大小以 KB 为单位 >、< 偏移量以 KB 为单位 >、< 大小 >例如：SDS_TEMPDBS sdstmpdbs1, /work/dbspaces/sdstmp

45、dbs1,2,0,16000· SDS_TIMEOUT：该配置参数用于主效劳器确定要从 SD 效劳器获得确认需要等待多长时间，如果没有获得确认，主效劳器将停止 SD 效劳器。在主效劳器上设置该值。其取值范围：>= 0 秒，默认值为 20 秒。向集群中添加 SD 备用效劳器向集群添加一个 SDS 备用效劳器的具体步骤：步骤1：准备SQLHOSTS文件确保 SQHOSTS 文件在主效劳器和 SDS 节点都具有另一个效劳器的条目：production onsoctcp server_1 prod_tcp sds1 onsoctcp server_1 sds1_tcp hdr1 ons

46、octcp server_1 hdr1_tcp rss1 onsoctcp server_1 rss1_tcp clr1 onsoctcp server_1 clr1_tcp注意这里使用的组是可选的。步骤2：将主效劳器设置为共享磁盘的所有者在主效劳器中，运行：onmode -d set SDS primary myprim步骤3：配置SD备用效劳器· 确保以下参数匹配主效劳器的 ONCONFIG：ROOTNAME、ROOTPATH、ROOTOFFSET、ROOTSIZE、PHYSDBS、PHYSFILE、LOGFILES 和 LOGSIZE 。· 将 SDS_ENABLE

47、设置为 1 。· 配置 SDS_PAGING 和 SDS_TEMPDBS 。例如：SDS_ENABLE 1 SDS_PAGING /ids/sds/dbspaces/page_1,/ids/sds/dbspaces/page_2 SDS_TEMPDBS sdstmpdbs1,/ids/sds/dbspaces/sdstmpdbs1,2,0,16000 REDIRECTED_WRITES 1 TEMPTAB_NOLOG 1步骤4：启动SD备用效劳器oninitSDS 状态监控onstat 命令每次执行onstat时显示的头信息均有字段指示数据库效劳器正在作为主数据库效劳器还是辅助数据库

48、效劳器运行。以下例如显示作为复制对中的 SDS 辅助数据库效劳器并且处于读写方式的数据库效劳器：IBM Informix Dynamic Server Version 11.50.UC1 - Updatable (SDS)- Up 00:00:59 - 105120 Kbytesonstat -g sds 命令您可以使用onstat -g sds命令来查看 SD 辅助效劳器统计信息。 onstat 实用程序的输出取决于实用程序是在主效劳器还是在辅助效劳器上运行。onstat-g sds 命令输出根本包括：· Local server type：是 Primary 还是 SDS (sh

49、ared disk secondary) 效劳器类型· Number of SDS servers：连接到主效劳器上 SDS 效劳器的数量· SDS Srv name: SDS 效劳器的名称· SDS Srv status: 显示 SDS 效劳器数否活动· Connection status：显示 SDS 效劳器是否已经连接· Last LPG sent (log id, page)：最近发送的 LPG log ID and page· Supports Proxy Writes：显示辅助效劳器是否可执行 update 操作，Y 代表

50、支持，N 不支持下边是执行 onstat -g sds 命令的输出：Local server type: Primary Number of SDS servers:1 SDS server information SDS srv SDS srv Connection Last LPG sent Supports name status status (log id,page) Proxy Writes C_151162 Active Connected 554,4998使用 SMI 表查询 syssrcsds 表可获取关于主效劳器上共享磁盘统计信息的信息。查询 systrgsds 表可获取关

51、于辅助效劳器上共享磁盘统计信息的信息。SDS 故障切换辅助效劳器环境中的灾难恢复在当前主效劳器连接到新的主效劳器时执行故障转移当高可用性环境处于活动状态时，新的主效劳器将通知旧主效劳器它将采取共享磁盘的所有权。然后，旧的主效劳器将回滚所有翻开的事务，并将其自身切换为辅助状态。在旧的主效劳器完成该过程之后，它将通知新的主效劳器回滚完成。这将成为新的主效劳器继续操作的信号。可通过在新的主效劳器上发出onmode -d set sds primary命令来执行此过程。在当前主效劳器未连接到新的主效劳器时执行故障转移在此场景中，新旧主效劳器之间的连接不存在。在这种情况下，我们需要强制执行转换。这可通过

52、发出onmode -d set sds primary force命令完成。仅当在确定原始主效劳器不活动时才能发出该命令。因为强制关键字会使新的主效劳器在不与旧主效劳器通信的情况下成为源效劳器，所以如果旧的主效劳器仍然处于活动状态，它很可能导致数据库毁坏。当高可用性集群中的所有节点不可用时执行故障转移这是在所有效劳器出现故障而且未能启动现有主效劳器后尝试故障转移时的唯一问题。该问题的原因是主效劳器必须能够连接以启动高可用性集群中的辅助效劳器。如果主效劳器不处于活动状态，那么无法建立连接，因此无法启动辅助效劳器。如果无法启动辅助效劳器，那么用于更改主效劳器的 onmode 命令将不会起作用。要防

53、止该问题，请使用 oninit -SDS=<new alias>，其中 <new alias> 是新的主效劳器上的 TCP 别名。这允许启动现有辅助效劳器，并使其能够同时采取环境的所有权。仅当启动集群内的第一个效劳器时才能使用 oninit 命令的该选项。SDS 故障切换的根本方法及形式将 SD 辅助效劳器提升为主效劳器可通过在 SD 辅助效劳器上发出以下命令来将 SD 辅助效劳器转换为主效劳器：onmode -d set SDS primary <alias>请注意：SD 辅助效劳器不能转换为标准效劳器。禁用 SD 辅助效劳器环境中的主效劳器可使用以下命令

54、禁用主效劳器：在主效劳器上，输入以下命令： onmode -d clear SDS primary <alias>该命令将使主效劳器成为标准效劳器，并禁用共享磁盘环境。SD 辅助效劳器环境中的灾难恢复的建议如果主效劳器发生故障，那么故障转移的顺序应该是：· 转移到 SD 辅助效劳器· 转移到 HDR 辅助效劳器· 转移到 RS 辅助效劳器集群环境下灾难恢复的各种方式比照可在任何类型的辅助效劳器上运行 onmode -d make primary 命令以将该效劳器提升为主效劳器。下表说明了每个效劳器类型是如何受到影响的。如果新的主效劳器是：那么该类型的对

55、等效劳器：受该方式的影响：SD 辅助效劳器SD 辅助效劳器连接到新的主效劳器并继续RS 辅助效劳器连接到新的主效劳器并继续HDR 辅助效劳器连接到新的主效劳器并继续旧的主效劳器关闭HDR 辅助效劳器SD 辅助效劳器关闭RS 辅助效劳器连接到新的主效劳器并继续HDR 主效劳器取决于用户操作RS 辅助效劳器SD 辅助效劳器关闭HDR 辅助效劳器关闭RS 辅助效劳器关闭CLR 技术有的时候，远程灾备效劳器和主机效劳器要实现物理隔离，或者数据网络非常不稳定，这种情况下，Informix 11 提供了 CLR Continuous Log Restore技术，它是通过逻辑日志备份的方式，将数据库的逻辑日

56、志人工传送到远程灾备效劳器，通过数据库逻辑日志恢复的方式保持和主数据库数据同步的方式。图 7. CLR 数据复制工作原理示意图CLR 方式，就是我们常说的 log shipping 方式，CLR 效劳器一直处于 fast recover 状态，不断接收新的逻辑日志，当需要恢复时，执行 ontape l X 命令，数据库会转变为静态模式，之后就可以正常使用了。CLR 方式，主要用于远程灾备效劳器和主机效劳器采用物理隔离，或者数据网络非常不稳定的情况下实现灾难恢复的场景。CLR 工作的根本原理主效劳器通过定期或连续进行逻辑日志备份，并将日志备份数据手工的方式传送到 CLR 效劳器端， CLR 效劳

57、器不断采用 ontape -l C 命令前滚日志， CLR 处于 logical roll-forward 模式，当需要使用 CLR 效劳器时，采用 ontape l X 命令，数据库会转变为静态模式，之后就可以正常使用了。CLR 配置实现向集群中添加 CLR 备用效劳器向集群添加一个 CLR 备用效劳器的具体步骤：步骤 1 ：准备 SQLHOSTS 文件集群中的所有效劳器必须具有针对其他效劳器的 SQLHOSTS 条目。production onsoctcp server_1 prod_tcp sds1 onsoctcp server_1 sds1_tcp hdr1 onsoctcp serve