Informix 11.5 高可用集群技术及应用实现

大家好，今天我们在这里探讨Informix数据库的高可用技术。众所周知，用户的关键业务系统，特别是 OLTP 系统，都要求提供 24X7 不间断的应用服务，这就要求数据库系统能够提供强大的高可用能力。这种能力不仅仅体现在主机及备机的接管方面，同时要能够提供远程容灾能力，以及本地的负载均衡能力。 针对上述对数据库的要求，Informix 从版本 6 开始， 就提供了 HDR（High Availability Data Replication） 技术，从 Informix 11 开始，Informix 数据库提供了 SDS(Shared Disk Secondary)、RSS(Remote Standalone Secondary)、CLR(Continuous Log Restore) 等高可用集群技术，提供了更加强大的高可用能力。尤其是从 Informix 11.5 开始其高可用技术发生了质的飞跃，HDR、SDS、RSS 备机都具备可读可写的能力，提供了更强大的负载均衡能力。 本研讨会，我们就针对 Informix 高可用技术不同方案的特点、技术实现和使用范围等方面与大家共同探讨。

informix 的高可用技术SDS(Shared Disk Secondary)、RSS(Remote Standalone Secondary)、CLR(Continuous Log Restore) 分别适用的场景是那些呢？条件是什么呢？

SDS是双主机同时读写共享磁盘，一般用在大型联机交易应用业务，和Oracle RAC相似。RSS是广域网异步HDR，用在数据库级的灾备环境。CLR是在网络不太好的情况下的脱机连续逻辑日志的数据恢复，用于数据库备份。

SDS共享磁盘方案，类似ORACLE RAC，提供高可用性和负载均衡情况，但是不具备存储容灾能力。提供快速的故障切换能力。 HDR，近距离双机方案，一般使用于同机房、2机房、同城2中心的双机方案，提供数据灾备能力。当主机故障时，备机快速接管。 RSS，就是远程容灾方案，是在HDR基础上提供的远程容灾方案，适用于异地方案，长距离数据同步方案，提供异步通信工作模式，对网络带宽要求低。适用于自然灾害（地震、海啸）等灾难情况。 CLR 基于逻辑日志的容灾方案，对平台无要求，离线工作方式。

Informix数据库是在UNIX开发的，其名字的含义为Information for unix，在UNIX系统上占用内存少，效率高，尤其是联机处理优势明显。实际上ORACLE RAC技术，双机共享磁盘的同时可读可写，在当时是领先Informix的HDR的。但是从 Informix 11.5 开始，IBM加大了研发力度，其HDR、SDS、RSS 备机都具备可读可写的能力，提供了更强大的负载均衡能力。

Informix仍然是主流的关系型数据库之一，只是Informix的使用很多场景不为人知。Informix的独特性--高效、稳定、灵活，使之Informix在电信、零售、银行、保险、电力等行业有较多的客户。从2001年IBM收购INFORMIX后，市场上没有Informix的广告，客户感觉Informix在退出市场，其实不然。 关于Informix的高可用性方案，相比其他数据库要完善。HDR已经有10多年的历史了，DB2才在过去2年时间内学习了INformix的HDR技术提供了类似的HDAR功能。 INformix的高可用性方案架构与其他数据库不同，基于逻辑日志的同步，松耦合架构。实施成本低，部署快速，依赖硬件少。

目前国内客户对数据库的高可用性的需求有：1、在同一机房内，双主机同时可读写共享磁盘的数据库，如Informix SDS（Oracle RAC）技术，能够提供负载均衡。2、同城2机房中的数据库复制，主机和磁盘为2套，Informix HDR。3、异地数据库复制，如Informix RSS。

Informix11.5 HDR 当客户在主用服务器上进行数据库写操作，通过复制逻辑日志的方式，同步备用数据库；当客户对备用数据库进行写操作时，这时备用数据库当作主用服务器的Informix客户端，先向主用服务器写操作，主用服务器再把逻辑日志同步到备用服务器上。这样就保持了主备数据库的数据一致性。

Informix的高可用性方案的架构是松耦合架构。有主、备机之分，主备机之前不共享内存和锁。通过逻辑日志的同步和恢复来进行数据的同步。主备机之间的数据有毫秒级别的延迟。

Informix HDR 支持同步、异步工作方式。当设置为同步模式时，主服务器的写操作事务需要待备机完成同步后才结束。这种工作模式，对性能有影响。在异步工作模式下，通过控制延迟。DRINTERVAL，DRTIMEOUT参数设置来控制数据延迟程度。

 

Informix 11.5 高可用集群技术及应用实现

概述

用户的关键业务系统，特别是 OLTP 系统，都要求提供 24X7 不间断的应用服务，这就要求数据库系统能够提供强大的高可用能力。这种能力不仅仅体现在主机及备机的接管方面，同时要能够提供远程容灾能力，以及本地的负载均衡能力。

针对上述对数据库的要求，Informix 从版本 6 开始， 就提供了 HDR 技术，它是通过数据库的事务日志的方式实现了主、备机互相接管的功能，当主机工作时，备机提供只读功能，因此，备机可以提供查询、报表等功能，实现负载分担的功能，当主机发生故障，备机会自动接管，实现主机及备机的接管功能。

从 Informix 7.2.2 版本开始，Informix 数据库提供了 ER(Enterprise Replication) 数据库复制技术，它也是通过读取数据库日志的方式实现数据同步功能，当源数据库数据发生变化后，Informix 数据库通过读取数据库日志，将变化的数据及时同步到目标数据库，采用 ER 的方式，和 HDR 不同，HDR 数据库的接管是基于数据库服务器的，也就是它的作用范围是基于整个实例的，而 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 开始，Informix 还提供了 Connection Manager 功能部件，它可以提供 SLA(Service Level Agreement) 功能，更好地实现负载均衡的能力，同时提供了 FOC(Fail Over Connection) 功能，实现透明故障接管能力，而且，所有这些对客户端应用来说是透明的。通过不断的发展与创新，Informix 提供了业界领先的高可用集群技术。

下边，我们就具体讲述一下 Informix 高可用集群技术特点、使用范围及技术实现，希望读者能够对它有一个更全面的理解。

HDR 技术

高可用性数据复制 HDR 技术，从 Informix 6 版本就开始提供，它是采用一主、一备方式，通过读取数据库逻辑日志方式，实现主备机互相切换功能。在 Informix 11.5 之前， HDR 备机支持只读方式，我们通常会通过备机来完成数据查询、报表功能，分担主机系统的压力。从 Informix 11.5 开始， HDR 备机支持读写操作，提供了更灵活的功能。 HDR 方式通常用来提供高可用性及 hot standby 功能。

HDR 工作的基本原理

图 1. HDR 工作原理示例图

如图中所示，当主数据库服务器开始将共享内存中的逻辑日志缓冲区的内容刷新到磁盘上的逻辑日志时，数据库服务器也将逻辑日志缓冲区的内容复制到主数据库服务器上的数据复制缓冲区。然后主数据库服务器将这些逻辑日志记录发送至 HDR 辅助数据库服务器。

HDR 辅助数据库服务器将来自主数据库服务器的逻辑日志记录接收到共享内存接收缓冲区（数据库服务器自动将接收缓冲区调节至适当的大小以适合正在发送的数据量）。然后辅助数据库服务器在整个逻辑恢复中应用逻辑日志记录 , ，并将这些记录应用到其自己的数据库空间。

HDR 数据复制支持同步或异步两种方式。 ONCONFIG 配置参数 DRINTERVAL 的值确定数据库服务器使用同步更新还是异步更新。如果将 DRINTERVAL 设置为 -1，那么对 HDR 辅助服务器的数据复制同步发生。一旦主数据库服务器将逻辑日志缓冲区内容写入 HDR 缓冲区，它会将那些记录从缓冲区发送至 HDR 辅助数据库服务器。仅当主数据库服务器接收到来自 HDR 辅助数据库服务器的确认（已收到记录）之后，主数据库服务器上的逻辑日志缓冲区清仓才会完成。使用同步更新时，如果发生故障，那么在主数据库服务器上提交的事务在 HDR 辅助数据库服务器上不会仍未提交或部分提交。

如果您将 DRINTERVAL 设置为除 -1 以外的任何值，那么数据复制将针对 HDR 辅助服务器异步发生。主数据库服务器在将逻辑日志缓冲区内容复制到 HDR 缓冲区之后会清仓逻辑日志缓冲区。（与上述操作无关）当发生以下条件之一时，主数据库服务器在整个网络上发送 HDR 缓冲区的内容：

• HDR 缓冲区变满。
• 自上次将记录发送至辅助数据库服务器以后，DRINTERVAL 配置参数在主数据库服务器上指定的时间间隔已过去。

该更新方法可以提供比同步更新更好的性能。但是，可能会丢失事务。

HDR 处理数据复制的线程

主数据库服务器启动专门的线程来支持数据复制。如图 2 所示，主数据库服务器上名为 drprsend 的线程将整个网络上主服务器缓冲区的内容发送至辅助数据库服务器上名为 drsecrcv 的线程。

辅助数据库服务器上名为 drsecapply 的线程将接收缓冲区的内容复制到恢复缓冲区。 logrecvr 线程对恢复缓冲区的内容执行逻辑恢复，将逻辑日志记录应用到辅助数据库服务器管理的数据库空间。 OFF_RECVRY_THREADS 配置参数指定使用的 logrecvr 线程数。

数据库服务器启动的其余线程是 drprping 和 drsecping 线程，它们负责发送和接收指示两个数据库服务器是否连接的消息。

图 2. HDR 数据复制线程示例图

HDR 主、备机之间采用半双工通信协议，因此对网络延迟非常敏感，通常要求网络要非常稳定，同时距离支持有限，通常在同一个大楼里面。

HDR 配置实现

HDR 对硬件和操作系统要求：

• 运行主数据库服务器和辅助数据库服务器的计算机必须相同（相同的供应商和体系结构）。
• 运行主数据库服务器和辅助数据库服务器的计算机上的操作系统必须相同。
• 运行主数据库服务器和辅助数据库服务器的硬件必须支持网络能力。
• 分配给主数据库服务器和辅助数据库服务器的数据库空间的磁盘空间量必须相等。磁盘空间类型是不相关的；您可以在两个数据库服务器上使用任何原始或格式化的空间组合。

HDR 对数据库和数据要求：

• 数据库必须将事务日志记录打开。
• 数据必须驻留在数据库空间或 Sb 空间中。

HDR 对配置参数的要求：

以下 ONCONFIG 参数在每个数据库服务器上都必须具有相同值：

• ROOTNAME
• ROOTOFFSET
• ROOTPATH
• ROOTSIZE
• MIRROROFFSET
• MIRRORPATH
• PHYSDBS
• PHYSFILE
• LTAPEBLK
• LTAPESIZE
• TAPEBLK
• TAPESIZE
• LOGFILES
• LOGSIZE
• DYNAMIC_LOGS

数据库服务器记录逻辑日志文件的添加。在主服务器上动态添加的逻辑日志文件将在辅助服务器上自动复制。尽管辅助服务器上的 DYNAMIC_LOGS 值不起作用，请保持主服务器上 DYNAMIC_LOGS 与值的同步，以免它们切换角色。

HDR 配置参数在复制对中的两个数据库服务器上必须设置为相同的值：

• DRAUTO
• DRINTERVAL
• DRTIMEOUT

HDR 相关配置参数说明：

• DRAUTO：用来控制主服务器和 HDR 备用服务器在出现故障时的行为。其取值范围如下 :
  • 0 表示 OFF = 不要在 HDR 环境中自动切换服务器类型。
  • 1 表示 RETAIN_TYPE = 在 HDR 故障期间自动从辅助切换到标准。在重新启动 HDR 时切换回辅助。
  • 2 表示 REVERSE_TYPE= 在 HDR 故障时自动从辅助切换到标准。在重新启动 HDR 时切换到主要（并将原来的主要切换为辅助）。
• DRIDXAUTO：指定如果 HDR 辅助服务器检测到了毁坏的索引，主服务器是否要自动启动索引复制。其取值范围如下 :
  • 0 - 禁用自动索引修复
  • 1 - 启用自动索引修复
• DRINTERVAL：指定高可用性数据复制缓冲区的清仓之间的最大时间间隔（秒）。其取值范围如下 :
  • >= 0 - 异步更新
  • -1 - 同步更新
• DRLOSTFOUND：指定 dr.lostfound.timestamp 文件的路径名。该文件包含当主数据库服务器遇到故障时在主数据库服务器上提交但未在辅助数据库服务器上提交的事务。如果在主数据库服务器和辅助数据库服务器之间同步发生更新（即，如果 DRINTERVAL 设置为 -1），那么此参数不适用。
• DRTIMEOUT：出现网络超时的时间，以秒为单位。 DRAUTO 使用该参数检测故障转移。其取值范围如下 :>= 0 秒 , 缺省为 30 秒

向集群中添加 HDR 备用服务器

向集群添加一个 HDR 备用服务器的具体步骤：

步骤1：准备 SQLHOSTS 文件

在主服务器更新 SQLHOSTS 文件，同时在 HDR 备用服务器中更新：

1 2 3 4 5

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 配置参数同主服务器上保持一致。

步骤3：备份主服务器

在主服务器中，使用 0 级备份：

1	ontape -s -L 0

步骤4：将 HDR 备份服务器注册到主服务器

在主服务器中，运行：

1	onmode -d primary hdr

步骤5：准备 HDR 备用服务器的磁盘

HDR 备用服务器使用的存储必须匹配主服务器的存储（例如，必须匹配 dbspace 的数量、块的数量、块大小、路径名和偏移量）。

步骤6：恢复 HDR 备用服务器上的备份

在 HDR 服务器上，执行 0 级备份的物理恢复：

1 2 3 4 5

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  Restore a level 1 archive (y/n) n

步骤7：使 HDR 备用服务器进入 online 模式

完成恢复后，HDR 备用服务器将进入 recovery 模式。运行以下命令：

1	onmode -d secondary production

HDR 状态监控

onstat – 命令

每次执行 onstat 时显示的头信息均有字段指示数据库服务器正在作为主数据库服务器还是辅助数据库服务器运行。

以下示例为作为复制对中的主数据库服务器并且处于联机方式的数据库服务器显示头信息：

1 2	IBM Informix Dynamic Server Version 11.50.UC1 -- On-Line (Prim) -- Up 00:00:59 -- 105120 Kbytes

以下示例显示作为复制对中的 HDR 辅助数据库服务器并且处于读写方式的数据库服务器：

1 2	IBM Informix Dynamic Server Version 11.50.UC1 -- Updatable (Sec) -- Up 00:00:59 -- 105120 Kbytes

以下示例显示不包含在 HDR 中的数据库服务器的标题。该数据库服务器的类型为标准类型。

1 2	IBM Informix Dynamic Server Version 11.50.UC1 -- On-Line -- Up 00:00:59 -- 105120 Kbytes

onstat -g dri 命令

要获得完整的 HDR 监视信息，请执行 onstat -g dri 选项。显示以下字段：

• 数据库服务器类型（主类型、辅助类型或标准类型）
• HDR 状态（打开或关闭）
• 成对的数据库服务器
• 最后一个 HDR 检查点
• HDR 配置参数的值

oncheck – pr 命令

如果您的数据库服务器正在运行 HDR，那么保留页面 PAGE_1ARCH 和 PAGE_2ARCH 将保存 HDR 用于同步主数据库服务器和辅助数据库服务器的检查点信息。下图中给出相关的 oncheck -pr 输出示例。

运行 HDR 的数据库服务器的 oncheck -pr PAGE_1ARCH 输出 :

1 2 3 4 5 6

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 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 表包含以下各列。

列	描述
type	HDR 服务器类型
state	HDR 服务器状态
name	数据库服务器名称
intvl	HDR 缓冲区清空时间间隔
timeout	网络超时
lostfound	HDR lost+found 路径名

HDR 故障恢复

HDR 的失败是失去了复制对中数据库服务器之间的连接。任一以下情况均可能导致数据复制失败：

• 一个数据库服务器的站点上发生灾难性故障（如火灾或大地震）
• 连接两个数据库服务器的联网电缆被破坏
• 一个数据库服务器上的处理中延迟过长
• 辅助数据库服务器上发生磁盘故障（未通过镜像块解决）

HDR 故障的检测

数据库服务器将以下任何一种情况解释为 HDR 失败：

• 超过了指定的超时值。
  在正常的 HDR 操作期间，数据库服务器期待来自对中另一数据库服务器的通信确认。对中的每个数据库服务器都具有一个 ONCONFIG 参数 DRTIMEOUT，该参数指定秒数。如果来自对中另一数据库服务器的确认没有在 DRTIMEOUT 指定的秒数返回，那么数据库服务器会假设发生了 HDR 失败。
• 主 － 辅助对中的另一数据库服务器未响应网络上的定期消息传递（pinging）尝试。
  无论主数据库服务器是否向辅助数据库服务器发送任何记录，两个数据库服务器均会互相 ping 。如果主要 － 辅助对的一个数据库服务器没有响应四个连续的 ping 尝试，那么另一个数据库服务器会假设发生了 HDR 失败。

当数据库服务器检测到 HDR 失败时，它将写一个消息到其消息日志（例如，DR: receive error）并关闭数据复制。如果发生了 HDR 失败，那么两个数据库服务器之间的 HDR 连接将断开，并且辅助数据库服务器将保持只读方式。

如果辅助数据库服务器在 high-availability data-replication 失败后保持联机状态，并且 DRAUTO 配置参数设置为 1（RETAIN_TYPE），那么该数据库服务器的类型将自动更改为标准。如果 DRAUTO 设置为 0（off），那么辅助数据库服务器将顶事尝试重新建立与主数据库服务器的通信。如果 DRAUTO 设置为 2（REVERSE_TYPE），那么当旧的主服务器发生故障时（而非旧的主服务器重新启动时），在连接结束时，辅助数据库服务器将立即成为主数据库服务器。

RSS 技术

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

图 3. SMX 通信示意图

RSS 自动启动 SMX 通信方式。

RSS 工作的基本原理

为支持 RS 辅助服务器，主服务器要进行检查以查看是否连接了 RS 辅助服务器，如果连接，那么将页面复制到用于将该页面发送到 RS 辅助服务器的日志高速缓存。

图 4. RSS 数据复制线程示意图

RSS_Send 线程将日志页面传输到 RS 辅助服务器。很有可能需要发送的下一页不在日志高速缓存中。在该情况下，RSS_Send 线程将直接从磁盘读取日志页。 RSS_Send 线程与 SMX 交互，以使用全双工方式发送数据。有了全双工通信，线程在发送下一个缓冲区之前不等待来自 RS 辅助服务器的确认。在主服务器需要来自 RS 辅助服务器的确认之前最多可发送 32 个缓冲区传输。如果达到 32 个缓冲区的限制，那么发送线程将等待 RSS_Recv 线程接收来自 RS 辅助服务器的确认。

在 RS 辅助服务器上，RSS_Recv 与 SMX 交互，以接收来自主服务器的日志页。

RSS 在很多方面都与 HDR 相似。将日志发送到 RSS 的方式与主服务器将日志发送到 HDR 辅助服务器的方式很相似。但是，RSS 采用 SMX 异步通信框架，因此其对主服务器的影响达到最小。出于该原因，主服务器和 RSS 辅助服务器之间事务落实或检查点均不是同步进行的。换句话说，不保证在主服务器上落实的任何事务也在同一时间在 RSS 辅助服务器上得到落实。因为 RSS 辅助服务器是异步进行更新的，所以 RSS 辅助服务器不能直接提升为主服务器。相反，它可以提升为 HDR 辅助服务器，然后可提升为主服务器。另外，HDR 辅助服务器可降级为 RS 辅助服务器。

尽管 RS 辅助服务器与 HDR 辅助服务器类似，但有某些操作是 HDR 辅助服务器可执行但 RS 辅助服务器却不支持，例如：

• RS 辅助服务器不支持 SYNC 方式
• RS 辅助服务器不支持 DRAUTO
• RS 辅助服务器不具有同步检查点
• RS 辅助服务器不能直接转换为主服务器

RSS 备用服务器的主要作用是提供灾难恢复解决方案。如同在 HDR 中一样，主服务器不断将其所有的逻辑日志记录发送给 RS 备用服务器，不过 RS 使用的异步方式。与 HDR 不同，通信使用全双工协议。因此 RS 对网络延迟不是很敏感，并且可以更容易驻留在一个较远的地理位置。同时，如果节点间通信线路比较差的情况下，页经常采用 RS 备用服务器方式。 RS 备用服务器的一个特点是主服务器并不和 RS 备用服务器同步检查点，这一点和 SD 和 HDR 服务器不同。因此不能立即替代主服务器；必须首先切换为一个 HDR 服务器。

RSS 配置实现

硬件和软件需求

RS 辅助服务器维护物理数据库的完整副本。出于此原因，以下内容必须与主服务器相同：

• 运行数据库服务器的计算机硬件
• 分配给数据库空间的磁盘空间量
• 创建数据库空间时使用的物理设备中的偏移量

索引页日志记录（LOG_INDEX_BUILDS）

在创建索引时，索引页日志记录将各页写入到逻辑日志，以使高可用性环境中各服务器之间的索引创建同步。要使用 RS 辅助服务器，必须启用索引页日志记录。

索引页日志记录将完整索引写入到日志文件，然后将该日志文件异步地传输到辅助服务器。辅助服务器可以是 RS 辅助服务器，也可以是 HDR 辅助服务器。然后，日志文件事务被读入到辅助服务器上的数据库，减少辅助服务器在恢复期间重新构建索引的需求。对于 RS 辅助服务器，主服务器不等待来自辅助服务器的确认，这允许对主服务器上索引的立即访问。

索引页日志记录是使用 onconfig 参数 LOG_INDEX_BUILDS 进行控制的。如果 LOG_INDEX_BUILDS 设置为 1（已启用），那么在主服务器上构建索引然后将索引发送到辅助服务器。

向集群中添加 RS 备用服务器

向集群添加一个 RSS 备用服务器的具体步骤：

步骤1：准备 SQLHOSTS 文件

集群中的所有服务器必须具有针对其他服务器的 SQLHOSTS 条目。

1 2 3 4 5 6

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：在主服务器上，启用索引页面日志记录

1	onmode -wf LOG_INDEX_BUILDS=1

步骤3：在主服务器上，注册新的RS备用服务器

1	onmode -d add RSS rss1

步骤4：对主服务器采取0级备份

1	ontape -s -L 0

步骤5：在RS备用服务器中，恢复备份

1 2 3 4 5

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  Restore a level 1 archive (y/n) n

步骤6：使RS备用服务器进入online模式

1	onmode -d RSS myprim

RSS 状态监控

onstat – 命令

每次执行onstat时显示的头信息均有字段指示数据库服务器正在作为主数据库服务器还是辅助数据库服务器运行。

以下示例显示作为复制对中的 RSS 辅助数据库服务器并且处于读写方式的数据库服务器：

1 2	IBM Informix Dynamic Server Version 11.50.UC1 -- Updatable (RSS)-- Up 00:00:59 -- 105120 Kbytes  <br>

onstat -g rss 命令

我们可以在主服务器和 RSS 节点中分别运行 onstat -g rss 命令查看 RSS 节点状态。 在主服务器和 RSS 节点上的输出稍有不同。

在主服务器上运行 onstat -g rss 命令输出如下：

1 2 3 4 5 6 7 8 9 10 11

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 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 logging 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 操作，Y 代表支持，N 不支持

在辅助服务器上运行 onstat -g rss 命令输出如下：

1 2 3 4 5 6 7

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

其中：

• Local 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 page

RSS 故障切换

在高可用集群环境中，数据库服务器主要包含下述三种工作方式：

服务器方式	说明
标准方式	不是数据复制系统的一部分。
主要方式	数据复制系统的主要方式。可以更新数据。
辅助方式	数据复制系统的辅助方式。无法更新数据，但是可以读取数据。

RSS 进行故障切换的基本原则：

• RSS 节点不能升级为主节点
• DRAUTO 对 RSS 不起作用
• RSS 节点可以转换为 HDR 辅助节点
• HDR 辅助节点可以转变为 RSS 节点
• RSS 节点可以转换为 standard node

RSS 故障切换的基本方法及形式：

将 RSS 节点升级为 HDR 辅助节点 :

1	onmode – d secondary <primary>

将 RSS 节点转换为标准节点 :

1	onmode – d standard

将 HDR 辅助节点装换为 RSS 节点 :

1	onmode – d RSS <primary>

除去 RSS 节点 :

1	onmode -d delete RSS rss_servername

SDS 技术

与 HDR、RSS 不同，SDS 采用和主机共享磁盘方式，避免了数据重复存储的问题，节省了空间，同时安装、配置更加简单。而且，当主机发生故障后，它可以快速实现接管，另外，我们可以非常容易地配置多个 SDS，可以实现了负载均衡的功能。

由于 SD 备用节点利用了主服务器的磁盘并且可以轻松快速地启动，因而非常适合规模扩展场景，由于 SD 备用服务器非常接近主服务器（即它们共享相同的磁盘），因此最适合在主服务器遇到问题时作为故障转移服务器。

SDS 工作的基本原理

所有辅助服务器类型都使用日志从主服务器复制数据。对于 HDR 辅助服务器和 RS 辅助服务器可通过生成日志时使主服务器将其所有逻辑日志记录发送到辅助服务器，从而在辅助服务器上复制对主服务器所作的更新。 HDR 辅助服务器和 RS 辅助服务器接收在主服务器上生成的逻辑日志记录，并将这些记录应用到其自己的数据库空间。对于 SD 辅助服务器，如图所示，同 HDR 辅助服务器和 RS 辅助服务器不同，主服务器不是将整个日志进行发送，而只是将逻辑日志页的日志位置发送到 SD 辅助服务器。通过使用从主服务器接收到的日志位置，SD 辅助服务器从磁盘读取逻辑日志页，并将其应用于内存数据缓冲区。

图 5. SDS 数据复制示意图

SD 辅助服务器不会向共享磁盘块中写任何东西，不会将共享内存的数据刷新到磁盘，即使是发生 checkpoint 操作也一样。如果 SD 辅助服务器需要刷新共享内存数据，他们会备写到临时的‘ paging file ’ 中，直到下一次 checkpoint 操作才清空‘ paging file ’。

同时，如下图所示，主服务器不会清仓共享内存中的数据页，直到确认 SDS 不在需要该数据页才会清仓到磁盘上。

下图显示了启动 SD 辅助服务器的基本过程：

SD 辅助服务器首先创建到主服务器的 SMX 连接，之后，SD 辅助服务器向主服务器发出 checkpoint 请求，主服务器响应 SD 辅助服务器的 checkpoint 请求，并将相应 LSN 发送给 SD 辅助服务器，SD 辅助服务器启动必要的恢复操作，之后，主服务器开始不断向 SD 辅助服务器发送当前的 LSN，SD 辅助服务器也开始不断向主服务器发送 ACK 确认信息。

图 6. SDS 数据复制工作原理示意图

SDS 配置实现

辅助服务器的硬件和软件需求

除了磁盘需求（与主服务器共享），硬件和软件需求与 HDR 辅助服务器的需求相同。此外，具有数据库服务器的计算机之间必须共享主磁盘系统。这表示从 SD 辅助服务器到数据库空间的路径必须与主服务器的数据库空间路径相同。

SDS 相关配置参数说明

• SDS_ENABLE：用来启用 SD 辅助服务器功能。您必须在主服务器及 SD 辅助服务器中将 SDS_ENABLE 都设置为 1（启用），才能启用 SD 辅助服务器功能。
  其取值范围：
  • 0 - 禁用 SDS 功能
  • 1 - 启用 SDS 功能
• SDS_PAGING： 指定了两个要作为缓存器调页文件的文件的位置。如果未设置 SDS_PAGING，SD 辅助服务器可能无法启动。在 SD 辅助服务上设置该值。
  其取值范围：
  < 分页文件 1 的绝对路径 >，< 分页文件 2 的绝对路径 >
• SDS_TEMPDBS：指定 SD 辅助服务器用于动态创建临时数据库空间的信息。为了启动 SD 辅助服务器，SD 辅助服务器的 ONCONFIG 文件中至少出现一次 SDS_TEMPDBS，最多可以配置为 16 SDS_TEMPDBS 条目。在 SD 辅助服务上设置该值，主服务器上不使用 SDS_TEMPDBS 。
  其取值范围：
  、< 路径 >、< 页面大小以 KB 为单位 >、< 偏移量以 KB 为单位 >、< 大小 >
  示例：
  SDS_TEMPDBS sdstmpdbs1, /work/dbspaces/sdstmpdbs1,2,0,16000
• SDS_TIMEOUT：该配置参数用于主服务器确定要从 SD 服务器获得确认需要等待多长时间，如果没有获得确认，主服务器将停止 SD 服务器。在主服务器上设置该值。
  其取值范围：
  >= 0 秒，默认值为 20 秒。

向集群中添加 SD 备用服务器

向集群添加一个 SDS 备用服务器的具体步骤：

步骤1：准备SQLHOSTS文件

确保 SQHOSTS 文件在主服务器和 SDS 节点都具有另一个服务器的条目：

1 2 3 4 5 6

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：将主服务器设置为共享磁盘的所有者

在主服务器中，运行：

1	onmode -d set SDS primary myprim

步骤3：配置SD备用服务器

• 确保以下参数匹配主服务器的 ONCONFIG：ROOTNAME、ROOTPATH、ROOTOFFSET、ROOTSIZE、PHYSDBS、PHYSFILE、LOGFILES 和 LOGSIZE 。
• 将 SDS_ENABLE 设置为 1 。
• 配置 SDS_PAGING 和 SDS_TEMPDBS 。

例如：

1 2 3 4 5

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备用服务器

1

oninit

SDS 状态监控

onstat – 命令

每次执行onstat时显示的头信息均有字段指示数据库服务器正在作为主数据库服务器还是辅助数据库服务器运行。

以下示例显示作为复制对中的 SDS 辅助数据库服务器并且处于读写方式的数据库服务器：

1 2	IBM Informix Dynamic Server Version 11.50.UC1 -- Updatable (SDS)-- Up 00:00:59 -- 105120 Kbytes

onstat -g sds 命令

您可以使用onstat -g sds命令来查看 SD 辅助服务器统计信息。 onstat 实用程序的输出取决于实用程序是在主服务器还是在辅助服务器上运行。onstat-g sds 命令输出基本包括：

• Local server type：是 Primary 还是 SDS (shared 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 代表支持，N 不支持

下边是执行 onstat -g sds 命令的输出：

1 2 3 4 5 6

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 表可获取关于辅助服务器上共享磁盘统计信息的信息。

SDS 故障切换

辅助服务器环境中的灾难恢复

在当前主服务器连接到新的主服务器时执行故障转移

当高可用性环境处于活动状态时，新的主服务器将通知旧主服务器它将采取共享磁盘的所有权。然后，旧的主服务器将回滚所有打开的事务，并将其自身切换为辅助状态。在旧的主服务器完成该过程之后，它将通知新的主服务器回滚完成。这将成为新的主服务器继续操作的信号。可通过在新的主服务器上发出onmode -d set sds primary命令来执行此过程。

在当前主服务器未连接到新的主服务器时执行故障转移

在此场景中，新旧主服务器之间的连接不存在。在这种情况下，我们需要强制执行转换。这可通过发出onmode -d set sds primary force命令完成。仅当在确定原始主服务器不活动时才能发出该命令。因为强制关键字会使新的主服务器在不与旧主服务器通信的情况下成为源服务器，所以如果旧的主服务器仍然处于活动状态，它很可能导致数据库毁坏。

当高可用性集群中的所有节点不可用时执行故障转移

这是在所有服务器出现故障而且未能启动现有主服务器后尝试故障转移时的唯一问题。该问题的原因是主服务器必须能够连接以启动高可用性集群中的辅助服务器。如果主服务器不处于活动状态，那么无法建立连接，因此无法启动辅助服务器。如果无法启动辅助服务器，那么用于更改主服务器的 onmode 命令将不会起作用。要避免该问题，请使用 oninit -SDS=，其中 是新的主服务器上的 TCP 别名。这允许启动现有辅助服务器，并使其能够同时采取环境的所有权。仅当启动集群内的第一个服务器时才能使用 oninit 命令的该选项。

SDS 故障切换的基本方法及形式

将 SD 辅助服务器提升为主服务器

可通过在 SD 辅助服务器上发出以下命令来将 SD 辅助服务器转换为主服务器：

1	onmode -d set SDS primary <alias>

请注意：SD 辅助服务器不能转换为标准服务器。

禁用 SD 辅助服务器环境中的主服务器

可使用以下命令禁用主服务器：

在主服务器上，输入以下命令：

1	onmode -d clear SDS primary <alias>

该命令将使主服务器成为标准服务器，并禁用共享磁盘环境。

SD 辅助服务器环境中的灾难恢复的建议

如果主服务器发生故障，那么故障转移的顺序应该是：

• 转移到 SD 辅助服务器
• 转移到 HDR 辅助服务器
• 转移到 RS 辅助服务器

集群环境下灾难恢复的各种方式对比

可在任何类型的辅助服务器上运行 onmode -d make primary 命令以将该服务器提升为主服务器。下表说明了每个服务器类型是如何受到影响的。

如果新的主服务器是：	那么该类型的对等服务器：	受该方式的影响：
SD 辅助服务器	SD 辅助服务器	连接到新的主服务器并继续
	RS 辅助服务器	连接到新的主服务器并继续
	HDR 辅助服务器	连接到新的主服务器并继续
	旧的主服务器	关闭
HDR 辅助服务器	SD 辅助服务器	关闭
	RS 辅助服务器	连接到新的主服务器并继续
	HDR 主服务器	取决于用户操作
RS 辅助服务器	SD 辅助服务器	关闭
	HDR 辅助服务器	关闭
	RS 辅助服务器	关闭

CLR 技术

有的时候，远程灾备服务器和主机服务器要实现物理隔离，或者数据网络非常不稳定，这种情况下，Informix 11 提供了 CLR （Continuous Log Restore）技术，它是通过逻辑日志备份的方式，将数据库的逻辑日志人工传送到远程灾备服务器，通过数据库逻辑日志恢复的方式保持和主数据库数据同步的方式。

图 7. CLR 数据复制工作原理示意图

CLR 方式，就是我们常说的 log shipping 方式，CLR 服务器一直处于 fast recover 状态，不断接收新的逻辑日志，当需要恢复时，执行 ontape – l – X 命令，数据库会转变为静态模式，之后就可以正常使用了。

CLR 方式，主要用于远程灾备服务器和主机服务器采用物理隔离，或者数据网络非常不稳定的情况下实现灾难恢复的场景。

CLR 工作的基本原理

主服务器通过定期或连续进行逻辑日志备份，并将日志备份数据手工的方式传送到 CLR 服务器端， CLR 服务器不断采用 ontape -l – C 命令前滚日志， CLR 处于 logical roll-forward 模式，当需要使用 CLR 服务器时，采用 ontape – l – X 命令，数据库会转变为静态模式，之后就可以正常使用了。

CLR 配置实现

向集群中添加 CLR 备用服务器

向集群添加一个 CLR 备用服务器的具体步骤：

步骤 1 ：准备 SQLHOSTS 文件

集群中的所有服务器必须具有针对其他服务器的 SQLHOSTS 条目。

1 2 3 4 5 6

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 ：对主服务器采取 0 级备份

1	ontape -s -L 0

步骤 3 ：在 CLR 备用服务器中，恢复备份

1 2 3 4 5 6

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 Restore a level 1 archive (y/n) n

步骤 4 ：备份逻辑日志，并拷贝到 CLR 服务器，并按需要重命名日志文件

1

ontape -a

步骤 5 ：对 CLR 服务器，恢复逻辑日志文件

1	ontape – l -C

步骤 6 ：当需要时，停止前滚恢复状态，经 CLR 服务器转变为 quiescent mode

1	ontape – l -X

高可用集群技术使用场景举例

三层服务器可用性的配置示例

图 8. 三层服务器可用性配置示例图

现在假设新奥尔良校园的建筑物 A 中发生了本地中断。可能是机房内的水管破裂使水对刀片服务器和共享磁盘子系统的主副本造成了损害。通过运行 onmode -d 以使主服务器名位于建筑物 B 中的刀片服务器上运行的某个 SD 辅助服务器上来将主服务器的角色切换为建筑物 B 。这将导致其他所有辅助节点自动连接到新的主节点。

图 9. 第一层保护

因新奥尔良发生了区域性中断，所以建筑物 A 和建筑物 B 均丢失，那么您可以将主服务器角色切换至孟菲斯。此外，您也可能使丹佛进入到 HDR 辅助服务器，并可将附加 SD 辅助服务器添加到孟菲斯中的机器。

图 10. 第二层保护

影响两个站点的更大型中断应需要切换至最远的系统。

图 11. 第三层保护

高可用集群技术的选择

Informix 高可用集群技术版本支持情况

功能	IDS Express	IDS 工作组版	IDS 企业版
RS 辅助服务器	不可用	不可用	是
HDR 辅助服务器	不可用	可选	是
SD 辅助服务器	不可用	可选	可选

Informix 高可用集群技术的选择考虑

需求	建议配置
您需要定期增大报告容量	请使用 SD 辅助服务器
您正在使用提供足够磁盘硬件可用性的 SAN 设备，但是担心发生服务器故障	请使用 SD 辅助服务器
您正在使用提供足够磁盘硬件镜像的 SAN 设备，但是也需要当主操作丢失时能够返回联机状态的第二组服务器（而已镜像磁盘的限制不是问题）	考虑使用在两个站点上运行 SD 辅助服务器的两个刀片服务器中心
您需要具有距离适中的备份站点，但不能容忍故障转移期间出现任何数据丢失	考虑使用两个刀片服务器中心，SD 辅助服务器在主刀片服务器中心上，HDR 辅助服务器在远程刀片服务器上。
您想要具有未曾丢失事务的高度可用系统，但是还必须在世界的另一面上设置远程系统	考虑使用附近的运行 SYNC 方式的 HDR 辅助服务器，并使用世界另一面的 RS 辅助服务器
您想要具有高可用性解决方案，但是因为您所在区域中的网络，ping 的最佳响应时间为大约 200 ms	考虑使用 RS 辅助服务器
您需要备份站点，但不具有与备份站点之间的任何直接通信	考虑使用带有备份和恢复的“连续日志恢复 CLR ”
只要数据最终能够到达目的地，您就能够忍受数据交付过程中的延迟；但是在任何情况下都需要具有快速故障转移	考虑使用硬件磁盘镜像与 ER 相结合的 SD 辅助服务器。
您需要其他写处理功能，能够容忍这些写交付中的某些延迟，需要高度可用的事物并能够分割工作负载	考虑使用带有 SD 辅助服务器的 ER

结论

Informix 提供了业界领先的高可用集群技术。通过结合使用 HDR、SDS、RSS、CLR，为用户不仅提供了业界领先的高可靠解决方案，同时提供了最全面的负载均衡能力及故障接管能力。同时，Informix 11.5 还提供了 Connection Manager 功能部件，它是采用 ESQLC 编写的一个实用程序，通过它，可以为应用程序屏蔽 informix 高可用集群服务器的复杂性，对应用程序来说，它看到的永远是一个数据库实例，由 Connection Manager 来自动完成透明的负载均衡及故障接管工作，真正做到了用户应用不间断地运行。