IDS 11 系统管理 第 7 部分: IDS复制

关于本教程

本教程讲解如何配置和管理 High Availability Data Replication(HDR)系统、Enterprise Replication(ER)系统、Remote Standalone Secondary(RSS)系统和 Shared Disk Secondary(SDS)系统。

目标

在学习完本教程之后,您应该能够:

  • 理解 IDS 11 提供的各种复制机制
  • 理解设置 ER、HDR、RSS 和 SDS 环境的需求
  • 熟悉复制术语
  • 配置和管理复制环境

本教程并不涉及不同复制方法的工作细节,也不讨论如何监视这些复制方法。

一、HDR:简介

本节讨论与 High Availability Data Replication 相关的以下主题:

什么是 HDR?

High Availability Data Replication(HDR)是一种将数据从主服务器复制到从服务器的方法。HDR 将所有启用日志记录功能的数据库从主服务器复制到从服务器。尽管可以把从服务器看作主服务器的复制品,但是它不包含未启用日志记录功能的数据库的数据。在从服务器上存在这些数据库和模式,因为 DML(Data Manipulation Language)语句总是记录在日志中的;但是除非数据库启用了日志记录功能,否则插入、更新或删除的数据不会被复制。HDR 确保从服务器总是与主服务器保持同步。如果主服务器发生故障,那么从服务器可以作为备用服务器,直到主服务器恢复运行为止。

HDR 的优点

  • 高可用性:如果主服务器发生故障,那么可以自动启用对从服务器的写访问。
  • (可能)分担负载:由于从服务器包含数据的另一个拷贝,所以可以在从服务器上运行报告任务,而不是在主服务器上运行。这样就把报告任务的负载转移到从服务器上,有助于增加主服务器的吞吐量。
  • 同步或异步复制:同步更新的过程是这样的:在主服务器上,将逻辑日志缓冲区复制到数据复制缓冲区,通过网络发送它,然后向主服务器发送一个确认消息,表示缓冲区已经接收到。这时主服务器上的逻辑日志缓冲区刷新才算完成。通过使用同步更新,可以确保在主服务器上提交的事务也被发送到从服务器。异步更新的过程是这样的:主服务器将逻辑日志缓冲区复制到数据复制缓冲区,然后在发生以下事件时,刷新逻辑日志缓冲区并通过网络发送数据复制缓冲区内容:
    • 数据复制缓冲区变满
    • 应用程序在一个未启用缓冲的数据库上提交了事务
    • 满足 DRINTERVAL配置参数指定的时间间隔

HDR 的缺点

  • 数据库的日志记录模式:只有启用了日志记录功能的数据库才被复制。
  • 数据库范围:HDR 的粒度是数据库级别。启用日志记录功能的数据库中的所有表都被复制。
  • 同步模式:在使用同步更新时,逻辑日志缓冲区的刷新会有一个小延迟,因为接收确认消息会产生网络通信延迟。
  • 异步模式:如果使用异步更新,那么在主服务器发生故障时,主服务器上已经提交的一些事务可能还没有复制到从服务器。
  • 对 blobspace blob 的支持:不复制 blobspace 中存储的任何 blob。
  • 只读的从服务器:从服务器是一个只读服务器。需要执行写访问的所有应用程序必须使用主服务器。

HDR 的历史

HDR 最初是在 IDS 的 7.10.UC1 版本中出现的。以下版本逐渐增加了各种特性:

  • 7.11.UC1 —— 增强了 HDR 的主/从服务器切换
  • 7.31.UC2 —— 增加了对 onbar 和 ISM 的支持以启动 HDR
  • 9.20.UC1 —— 支持遗留数据类型;禁用了 DRAUTO
  • 9.30.UC1 —— 引入了新的 HDR 故障转移脚本(hdrmkpri.bat、hdrmksec.bat),可以切换 HDR 服务器的角色
  • 10.00.UC1 —— 可以通过 HDR 使用外部备份/恢复;增加了 DRIDXAUTO,用于将索引复制到从服务器;恢复了 DRAUTO参数

二、HDR:配置

本节讨论以下配置主题:

硬件需求

主服务器和从服务器在平台、操作系统版本、内存、CPU 和存储空间方面必须相同。服务器必须支持网络连接。在主服务器和从服务器上,分配给 dbspace 的磁盘空间量必须相同。一些用户喜欢给主服务器配置更多的内存或 CPU。不建议这样做,而且在这种情况下,HDR 的速度取决于最慢的服务器的速度。

数据库需求

主服务器和从服务器上的 onconfig 文件应该非常相似,而且以下参数必须完全相同:

  • ROOTNAME
  • ROOTOFFSET
  • ROOTPATH
  • ROOTSIZE
  • MIRROROFFSET—— 如果使用镜像特性
  • MIRRORPATH—— 如果使用镜像特性
  • PHYSDBS
  • PHYSFILE
  • LOGFILES
  • LOGSIZE
  • DYNAMIC_LOGS
  • DRAUTO
  • DRINTERVAL
  • DRTIMEOUT

HDR 特有的配置参数

DRAUTO配置参数决定,在发生故障时,应该自动还是手动切换到从服务器。可用的值包括:

  • 0 = OFF—— 不自动切换 HDR 环境中的服务器类型
  • 1 = RETAIN_TYPE—— 在 HDR 发生故障时,将从服务器切换为标准服务器。在重新启动 HDR 时,切换回从服务器。
  • 2 = REVERSE_TYPE—— 在 HDR 发生故障时,将从服务器切换为标准服务器。在重新启动 HDR 时,切换为主服务器(将原来的主服务器切换为从服务器)。

DRINTERVAL配置参数指定刷新数据复制缓冲区的最大时间间隔(以秒为单位)。如果设置为 -1,那么使用同步更新。默认值是 30 秒,因此默认模式是异步更新。

DRTIMEOUT配置参数指定,在使用同步更新时,服务器等待确认消息的最大时间间隔(以秒为单位)。

DRLOSTFOUND指定 dr.lostfound.timestamp 文件的路径名。这个文件包含在主服务器发生故障时,在主服务器上已经提交但是没有在从服务器上提交的事务。这个文件附加一个时间戳,所以服务器不会覆盖现有的 lost-and-found 文件(如果存在该文件的话)。在对发生故障的服务器进行逻辑恢复时,创建这些文件。如果 HDR 服务器对之间的更新是同步的,就不创建这些文件。

DRIDXAUTO指定,在 HDR 从服务器探测到一个损坏的索引时,HDR 主服务器是否自动启动索引复制。

日志需求

要进行复制的所有数据库都必须使用事务日志记录。HDR 通过将事务日志传输到从服务器来执行复制,DDL(Data Definition Language)语句将发送给从服务器,因为无论数据库的日志记录模式是什么,IDS 总会在日志中记录所有 DDL 语句。

另外,使用缓冲的日志记录可能会导致将数据复制到从服务器时出现更大的延迟。对于缓冲的数据库,只在以下情况下发送数据复制缓冲区:

  • 数据复制缓冲区变满
  • 满足 DRINTERVAL配置参数指定的时间间隔

其他需求

在使用 HDR 时,需要一个临时的 dbspace,因为只读系统上的查询需要用临时空间来存储中间结果。这些 dbspace 是从服务器上仅有的可写 dbspace。使用这些临时 dbspace 需要设置 DBSPACETEMP环境参数或配置参数。

blob 应该存储在 dbspace 中,而不是存储在 blobspace 中。这是因为对 blobspace 中的 blob 的修改不被记录在日志中,所以这些修改无法应用于从数据库。实际上,如果使用具有数据复制的 blobspace,从数据库就会显示不正确的结果,因为对 blob 描述符的修改记录在日志中,但是对磁盘上的 blob 的修改不被记录

在主服务器和从服务器上,非临时 dbspace 的 dbspace、块(chunk)、偏移量和路径必须相同。实际上,建议对两台机器上 IDS 系统使用的磁盘采用相同的分区方式。如果两个服务器的分区方式不同,由于分区的差异,一个系统可能比另一个系统慢。

连接需求

为了在不同机器上的 IDS 服务器之间建立连接,需要执行以下步骤:

  • 确保服务器是完全可信的
  • 添加适当的 NETTYPE配置参数(soctcp 或 tlitcp),或者确保 sqlhosts 文件包含 DBSERVERNAME或 DBSERVERALIAS的 TCP 连接
  • 确保两个 sqlhosts 文件包含对方服务器的设置项
  • 测试两个服务器之间的连接。一种测试方法是使用 dbaccess > connection > connect。为了确认服务器是完全 可信的,不要使用用户名和密码进行连接。如果连接失败,就检查错误代码并进行调试

三、HDR:启动和管理

本节讨论与 HDR 的启动和管理相关的以下主题:

初次启动 HDR

为了创建 HDR 服务器对,必须在主服务器上生成一个存档文件,然后在从服务器上恢复它。采用的步骤如下:

表 1. 初次启动 HDR 的步骤

步骤 在主服务器上 在从服务器上
1 安装 UDR、UDT 和 DataBlade 模块。注册 UDR、UDT 和 DataBlade 模块。 安装 UDR、UDT 和 DataBlade 模块。
2 ontape -s -L 0,或 onbar -b -L 0,或执行外部备份
3 onmode -d primary sec_name
4 ontape -p,或 ontape -r -p -e,或 onbar -r,或 onbar -r -p -e
5 onmode -d secondary prim_name
6 ontape -l,或 onbar -r -l

下面详细描述这 6 个步骤:

  1. 在两个服务器上 安装 用户定义的类型、用户定义的例程和 DataBlade 模块,然后只在主服务器上注册它们。
  2. 在两个服务器上 执行 一次0级存档。对主服务器上的逻辑日志进行备份(如果需要的话)。
  3. 运行以下命令,将 IDS 服务器 设置 为主服务器:
    onmode -d primary sec_name

    将sec_name替换为作为从服务器的 IDS 系统的DBSERVERNAME。执行这个命令之后,检查消息日志文件。它应该包含以下消息:

    DR: new type = primary, server name = sec_name DR: Cannot connect to secondary server
  4. 在从服务器上用第二步中创建的0级备份 执行 物理恢复。不要执行逻辑恢复。如果使用:
    • onbar,那么使用 onbar -r -p命令执行物理恢复
    • onbar并执行外部恢复,那么使用 onbar -r -p -e命令执行物理恢复
    • ontape,那么使用 ontape -p选项。不能使用 ontape -r选项,因为它同时执行物理恢复和逻辑恢复
    • ontape并执行外部恢复,那么使用 ontape -p -e命令执行物理恢复
  5. 运行以下命令,将 IDS 服务器 设置 为从服务器:
    onmode -d secondary pri_name

    将pri_name替换为作为主服务器的系统的DBSERVERNAME。执行这个命令之后,检查消息日志文件。它应该包含以下消息:

    DR: new type = secondary, primary server name = prim_name

    如果在主服务器上备份了逻辑日志文件并删除了它们,那么这些文件中的记录就不再保留在主服务器上了。从服务器会提示从磁带恢复这些文件。在这种情况下,必须执行第六步。

  6. 如果 过去写到主服务器的逻辑日志记录不再保留在主服务器磁盘上,那么从服务器会提示从磁带备份恢复这些文件。在恢复磁带上的所有逻辑日志文件之后,使用主服务器磁盘上的逻辑日志文件完成逻辑恢复。

改变服务器模式和类型

在 HDR 服务器对中,改变一个服务器的模式就会影响另一个服务器的模式。本节讨论每个服务器上可能产生的影响:

  • 在主服务器上,运行onmode -k会有以下效果:
    • 从服务器在消息日志中记录一个消息:DR: Receive error. HDR is turned off.
    • 如果 DRAUTO = 0,那么从服务器仍然处于只读模式
    • 如果 DRAUTO = 1,那么从服务器切换到标准服务器模式,可以接受更新
    • 如果 DRAUTO = 2,那么一旦与原来的主服务器的连接中断,从服务器就切换为主服务器模式
  • 在主服务器上,运行onmode -s、onmode -u或onmode -j分别将模式切换为在线、静默(quiescent)或管理,就会产生以下效果:
    • 从服务器不接收错误
    • HDR 仍然打开
    • 模式仍然是只读的
  • 在从服务器上,运行onmode -k会产生以下效果:
    • 主服务器在消息日志中记录一个消息:DR: Receive error. HDR is turned off.

改变服务器类型

可以改变主服务器或从服务器的类型。

只有在从服务器上关闭了 HDR 时,才能将从服务器改为标准服务器(onmode -d standard)。当到主服务器的复制连接中断,或者从服务器上的复制失败时,HDR 就会关闭。在将从服务器切换为标准服务器后,它不会尝试连接复制服务器对中的另一个服务器。

使用以下脚本切换服务器类型:hdrmksec.[sh|bat] 和 hdrmkpri.[sh|bat] 脚本。

将索引复制到从服务器

有时候,主服务器和从服务器上的索引可能会不一致。老的修复方法是删除索引并重建它。这个过程要锁定整个表,而且需要花费相当长的时间。现在可以采用另一种方法 —— 可以将索引从主服务器复制到从服务器,而不必在主服务器上重建索引。可以选择手工重建索引,或者让从服务器自动复制索引。

索引的自动复制

为了将索引自动复制到从服务器,必须执行以下步骤:

  • 在从服务器上运行 onmode -d idxauto on,这在下一次服务器切换之前会一直生效
  • 在 onconfig 文件中将 DRIDXAUTO配置参数设置为 1,这不受服务器切换的影响

索引的手工复制

有时候索引的自动复制不起作用,比如在表被锁定时。为了将索引手工复制到 HDR 从服务器,需要关闭自动复制特性并运行以下命令:

onmode -d index database:[ownername].table#index

练习

如果您以前没有设置过 HDR,现在就来实践一下前面讨论的操作。

练习 1:在两个服务器上设置一个 HDR 对。创建 stores 7 数据库的两个拷贝 —— 一个启用日志,一个不启用。可以使用以下命令创建这两个数据库:

  • dbaccessdemo7 stores7_log -log
  • dbaccessdemo7 stores7_nolog

在从服务器上检查这两个数据库。对于启用日志和不启用日志的数据库,会有什么不同吗?

练习 2:使用每个实例的相对路径在同一台服务器上设置 HDR 对。

解决方案

练习 1:这个练习的目标是帮助您熟悉 HDR 的设置,了解 HDR 的效果并理解它的工作方式。应该会看到,从服务器上的 ‘stores7_log’ 数据库与主服务器上相同 —— 数据库已经创建,所有表都存在,所有行也都存在。它们是完全相同的拷贝。对于不启用日志的数据库,您会发现数据库和表也已经创建,但是没有 复制行。这是因为 HDR 只复制逻辑日志中的内容。对于不启用日志的数据库,只有 DDL(Data Definition Language)语句被写入逻辑日志中。

练习 2:这个练习的目标是帮助您熟悉用相对路径在同一台服务器上启用 HDR。

四、HDR:监视

本节讨论以下监视主题:

onstat -g dri

在用 onstat -g dri检查 HDR 状态之前,先看一下 onstat 标题行 —— 它会显示以下信息之一:

清单 1. HDR 主服务器的 onstat 标题

IBM Informix Dynamic Server Version 11.10.FC1 — On-Line (Prim)

清单 2. HDR 从服务器的 onstat 标题

IBM Informix Dynamic Server Version 11.10.FC1 — Read-Only (Sec)

清单 3. 标准服务器的 onstat 标题

IBM Informix Dynamic Server Version 11.10.FC1 — On-Line

-g dri onstat选项输出 “完整的” HDR 监视信息。显示的信息包括:

  • 服务器类型(主、从或标准)
  • HDR 状态(开或关)
  • 配对服务器的名称
  • 最后一次 HDR 检查点的惟一逻辑日志 id 和逻辑页面
  • HDR 配置参数的值

下面是来自两个服务器的输出示例:

清单 4. HDR 主服务器上的 onstat -g dri 输出

$ onstat -g dri
IBM Informix Dynamic Server Version 11.10.FC1     — On-Line (Prim)
Data Replication:
Type           State        Paired server        Last DR CKPT (id/pg)
primary        on           october                       8 / 4276
DRINTERVAL   30
DRTIMEOUT    30
DRAUTO       0
DRLOSTFOUND  /cfs/mnt1/ERNS/class/rprivett/boy/dr.lostfound
DRIDXAUTO    0
ENCRYPT_HDR  0

清单 5. HDR 从服务器上的 onstat -g dri 输出

$ onstat -g dri
IBM Informix Dynamic Server Version 11.10.FC1     — Read-Only (Sec)
Data Replication:
Type           State        Paired server        Last DR CKPT (id/pg)
HDR Secondary  on           boy                           8 / 4276
DRINTERVAL   30
DRTIMEOUT    30
DRAUTO       0
DRLOSTFOUND  /cfs/mnt1/ERNS/class/rprivett/october/dr.lostfound
DRIDXAUTO    1
ENCRYPT_HDR  0

oncheck -pr

在启用 HDR 时,保留的页面 PAGE_1ARCH 和 PAGE_2ARCH 存储检查点的相关信息(HDR 使用检查点对两个服务器进行同步)。清单 6 和清单 7 是输出示例:

清单 6. HDR 主服务器上的 oncheck -pr 输出

    Validating PAGE_1ARCH & PAGE_2ARCH…
Using archive page PAGE_2ARCH.
Archive Level    0
Real Time Archive Began    05/23/2007 14:21:27
Time Stamp Archive Began    0x13b833
Logical Log Unique Id    8
Logical Log Position    0xf8250
DR Ckpt Logical Log Id    8
DR Ckpt Logical Log Pos    0x10b4018
DR Last Logical Log Id    8
DR Last Logical Log Page    4276
DR Last Mode Change    7 Primary mode

清单 7. HDR 从服务器上的 oncheck -pr 输出

    Validating PAGE_1ARCH & PAGE_2ARCH…
Using archive page PAGE_2ARCH.
Archive Level                  0
Real Time Archive Began        05/23/2007 14:21:27
Time Stamp Archive Began       0x13b833
Logical Log Unique Id          8
Logical Log Position           0xf8250
DR Ckpt Logical Log Id         8
DR Ckpt Logical Log Pos        0x10b4018
DR Last Logical Log Id         8
DR Last Logical Log Page       4277
DR Last Mode Change            8          Secondary mode

SMI 表

sysmaster:sysdri 表提供本地服务器的 HDR 状态信息。清单 8、清单 9 和清单 10 是输出示例:

清单 8. HDR 主服务器上的 SYSMASTER:sysdri

> select * from sysdri;
type       Primary
state      On
name       october
intvl      30
timeout    30
lostfound  /cfs/mnt1/ERNS/class/rprivett/boy/dr.lostfound
drauto     0
dridxauto  0
1 row(s) retrieved.

清单 9. HDR 从服务器上的 SYSMASTER:sysdri

> select * from sysdri;
type       Primary
state      On
name       october
intvl      30
timeout    30
lostfound  /cfs/mnt1/ERNS/class/rprivett/boy/dr.lostfound
drauto     0
dridxauto  0
1 row(s) retrieved.

清单 10. 标准服务器上的 SYSMASTER:sysdri

> select * from sysdri;
type       Standard
state      Off
name
intvl      30
timeout    30
lostfound  /cfs/mnt1/ERNS/class/rprivett/htdaab/dr.lostfound
drauto     0
dridxauto  0
1 row(s) retrieved.

五、HDR:故障转移

本节讨论以下故障转移主题:

为什么要进行故障转移?

老话说,“既然我们生活在现实世界中,遇到麻烦是难免的”,所以 HDR 故障转移是很有必要的。因为 IDS 和 HDR 依赖的系统各有不同,所以需要处理的问题也有许多差异。下面是需要进行故障转移的一些常见原因:

  • 在一个服务器站点发生灾难性事件,比如火灾或大地震
  • 两个服务器之间的连接出现问题
  • 发生与 IDS 或 HDR 无关的操作系统问题
  • 一个服务器上的处理过程出现过大的延迟
  • 从服务器上出现磁盘故障,而且无法用镜像块解决

当主服务器发生故障时

如果主服务器发生故障,从服务器可以采用以下选项:

  • 从服务器保持逻辑恢复模式。在这种情况下,不执行任何操作。如果相信 HDR 连接不久就会恢复,那么使用这个选项
  • 从服务器自动地成为标准服务器。这是将 DRAUTO设置为 1 或 2 的结果
  • 可以将从服务器的服务器模式手工切换为标准服务器

注意:自动切换只改变服务器类型。它不把客户机应用程序重定向到从服务器。

当从服务器发生故障时

如果从服务器发生故障,那么主服务器保持在线状态。如果将从服务器用作报告服务器,而且相信从服务器的故障需要花一些时间才能解决,那么需要将一些客户机重定向到主服务器。注意,主服务器可能需要额外的资源,比如额外的临时 dbspace、CPU VP 或内存。不需要将主服务器的类型改为标准,除非是需要重新启动 HDR。

对媒体故障的存档恢复

如果发生媒体故障,HDR 环境中可能会出现几个问题。这些问题取决于哪个服务器需要恢复。如果主服务器发生故障,要记住以下要点:

  • 如果块做了镜像,就可以从镜像恢复
  • 如果磁盘包含关键媒体(rootdbs、物理日志 dbspace 或逻辑日志 dbspace),主服务器就会运行失败。必须使用主 dbspace 备份执行完整恢复,或者将主服务器切换到标准模式,并将客户机重定向到这个服务器
  • 如果磁盘不包含关键媒体,就可以对受影响的 dbspace 执行热恢复

如果从服务器发生故障:

  • 如果块做了镜像,就可以从镜像恢复
  • 如果块没有做镜像,而且磁盘包含关键媒体(rootdbs、物理日志 dbspace 或逻辑日志 dbspace),从服务器就会运行失败。如果块没有做镜像,并且磁盘不包含关键媒体,那么从服务器会保持在线状态。在这两种情况下,都需要从主服务器执行完整恢复。这里不能执行热恢复,因为 dbspace 不处于在线模式

在没有媒体故障的情况下重新启动 HDR

如果两个 HDR 服务器上的关键媒体数据都没有损坏,那么可能出现以下四种情况,它们分别需要不同的 HDR 重新启动过程:

  1. 发生网络故障
  2. 发生从服务器故障
  3. 发生主服务器故障,而且从服务器没有切换为标准服务器
  4. 发生主服务器故障,而且从服务器切换为标准服务器

发生网络故障

在发生网络故障之后,HDR 对将超时,然后 HDR 关闭。主服务器将保持在线模式,从服务器仍然处于只读模式。在修复网络故障之后,可以在从服务器上运行 onmode -d secondary primary_name,重新启动 HDR。

注意:重新启动 HDR 不是必需的。主服务器会每隔 10 秒尝试重新连接从服务器。它还会每隔 2 分钟在 online.log 中记录一个关于连接无法建立的消息。如果连接很快恢复,就不必使用 onmode重新启动连接。

发生从服务器故障

在发生从服务器故障之后,只需使用 oninit重新启动 HDR。如果在消息日志中看到以下消息:

DR: Start Failure recovery from tape

就需要用 ontape -l命令将来自主服务器的逻辑日志应用于从服务器。

发生主服务器故障,而且从服务器没有切换为标准服务器

在发生主服务器故障之后,只需使用 oninit重新启动 HDR。

发生主服务器故障,而且从服务器切换为标准服务器

如果发生主服务器故障,而且从服务器已经切换为标准服务器,就需要按照表 2 中的步骤重新启动 HDR:

表 2. 从服务器处于标准模式时的 HDR 重新启动步骤

步骤 在主服务器上 在从服务器上
1 onmode -s —— 这个步骤将目前的标准服务器切换为静默模式。已经连接的所有客户机必须断开连接。执行更新的应用程序必须重定向到主服务器。
2 onmode -d secondary prim_name
3 oninit —— 如果过去写到从服务器上的所有逻辑日志记录仍然可用,那么在执行 oninit 命令时,主服务器会恢复从服务器磁盘上的这些记录。如果在从服务器上备份并删除了逻辑日志文件,那么这些文件中的记录就不再保留在从服务器磁盘上了。在这种情况下,会提示从磁带恢复这些逻辑日志文件(第四步)。
4 如果提示从磁带恢复逻辑日志记录,那么执行这个步骤:ontape -l 或 onbar -r -l

练习

在这个练习中,试验一下从主服务器向从服务器进行故障转移,然后再恢复 HDR 环境的状态。

练习 1:设置一个 HDR 环境。模拟一次主节点故障。将从节点转换为标准节点。

练习 2:重新设置 HDR 环境,使其恢复到主服务器故障之前的状态。

解决方案

练习 1:这个练习演示如何故障转移到从服务器。应该执行的步骤如下:

  1. 在主服务器上模拟一次故障:onmode -ky
  2. 将从服务器转换为标准模式:onmode -d standard

练习 2:有几种方法可以在此类故障之后设置 HDR,但是应该采用 表 2 中列出的步骤。这样就能够将 HDR 对恢复到以前的状态,而不需要执行备份和恢复。如果从服务器上的逻辑日志已经存档,而且主服务器也没有保留这些逻辑日志,就需要执行恢复。

六、ER:简介

本节讨论以下主题:

什么是 ER?

Enterprise Replication(ER)或 Continuous Data Replication(CDR)是一种内置的基于逻辑日志的异步机制,可以在事务级将对特定表和行的修改分布到任意数量的参与节点上。

ER 和 HDR 有什么差异?

ER 在以下方面与 HDR 不同:

  • 异构的 —— ER 可以在不同的平台上使用,IDS 版本也可以不一样
  • 只采用异步方式 —— 在使用 ER 时,在提交用户事务之后启动复制
  • 范围 —— ER 可以在特定表的行和列级复制数据
  • 多种复制模型 —— ER 可以使用与 HDR 相似的主 – 从模型,也可以使用许多其他模型,比如 update-anywhere、合并(consolidation)、分发(dissemination)和工作负载分区(workload partitioning)。在一个复制系统中可以任意混合使用这些模型
  • blob 支持 —— ER 支持 blobspace 中存储的文本列和字节列
  • 基于时间 —— 可以将 ER 设置为在特定时间或按照特定时间间隔执行复制

术语

ER 有许多新术语。表 3 简要总结了一些关键的术语:

表 3. 术语

术语 描述
企业复制(Enterprise replication) 一种内置的基于逻辑日志的异步机制,可以在事务级将对特定表和行的修改分布到任意数量的参与节点上。
高可用性数据复制(High-availability data replication) 提供对整个数据库服务器的同步和异步数据复制。用作热备用服务器,提供灾难恢复或分担负载。
服务器(Server) 数据库实例。
根服务器(Root server) 对于环境中其他 ER 服务器都完全可信的一个服务器。根服务器通常有一个完整的 SQLSHOSTS 和一个完整的全局编目。
副本(Replicate) 要复制的表。
参与服务器(Participant) 执行表复制的服务器。
副本集(Replset,replicate set) 副本的集合。
排他副本集(Exclusive replset) 暂停复制和基于时间的复制可以使用的副本集。
源(Source)和目标(target) 常常指 ER 环境。源是产生数据的地方;目标是接收数据的地方。
主服务器(Primary)和从服务器(secondary) 常常指 HDR 对。
异构环境(Heterogeneous environment)或同构环境(homogeneous environment) 异构环境是指环境中有不同的硬件平台或软件版本,同构环境是指环境中的硬件和软件版本都相同。
对等(Peer-to-peer)或双向(bi-directional),也称为 update-anywhere 参与复制的每个服务器可以同时作为源和目标。
层次化/层叠复制(Hierarchical/cascading replication) 一个复制源使用其他复制源作为分布点(A…B…C)。
水平分区(Horizontal partitioning) 只对行中选择的列进行复制。通过列映射实现。
垂直分区(Vertical partitioning) 只复制表中的某些行,通过 WHERE 子句实现。
同步服务器(Sync server) 同步服务器在 ER 服务器初始化期间使用。新的 ER 服务器从这个 ER 服务器获得 syscdr 数据库的拷贝。这让新的服务器了解其他已经定义的 ER 服务器、已经定义的副本等信息。
全局编目(Global catalog) 这由两部分组成:一个共享内存部分和磁盘上的一个稳定部分。共享内存部分由 onstat 使用,磁盘上的稳定部分由 cdr 命令使用。稳定部分基本上就是 syscdr 数据库。
稀疏编目(Sparse catalog) 稀疏编目提供全局编目的一个受限视图。提供稀疏编目的 ER 服务器常常是一个非根节点或叶节点。

历史

ER 的简要历史如下:

  • 7.22 —— 最初发布
  • 7.31 —— 层次化路由,新的网络接口
  • 9.21 —— 队列重写,初始 UDT 支持
  • 9.30 —— 完整的 UDT 支持,性能改进(动态并行),假脱机改进
  • 9.40 —— ER/HDR,大事务支持,网络加密支持,快速队列恢复
  • 10.00 —— 模式演化支持,模板,同步/检查

八、ER:配置

本节讨论以下主题:

启用日志的数据库

需要启用日志记录,因为 ER 需要读取日志。可以使用任何形式的日志记录:ANSI,缓冲的,非缓冲的。要想避免数据复制的延迟,应该使用非缓冲的数据库。

服务器之间的可信通信

所有根服务器必须能够通过 TCP/IP 相互通信(在使用层次化路由时,没有这个要求)。支持 SOC 和 TLI 通信协议。这些服务器必须是可信的参与复制的服务器。使用 dbaccess > connection > connect 但是不提供用户名/密码,从而确定连接是可信的。

主键约束

复制的所有表都必须有主键约束。ER 在内部使用主键提高性能和解决冲突。

SQLHOSTS 文件

sqlhosts 文件必须使用组语法。每个组必须有一个惟一的组名和 id 号。这里 “惟一” 的意思是,组名和 id 必须对于这个 ER 环境中的任何其他服务器都是惟一的。可以使用 sqlhosts 选项 s=6 来启用 $INFORMIXDIR/etc/hosts.equiv。只通过带 s=6 选项的服务接收 ER 或 HDR 连接。清单 11 给出一个包含几个节点的站点示例:

清单 11. 使用组语法的 SQLHOSTS 文件

                    
g_80s		group		-		-		i=80
boy		ontlitcp	sun-mach4	21340		g=g_80s
october		ontlitcp	sun-mach4	21341		g=g_80s
war		ontlitcp	sun-mach4	21342		g=g_80s
uabrs		ontlitcp	sun-mach4	21343		g=g_80s
g_90s		group		-		-		i=90
uf		ontlitcp	sun-mach5	21340		g=g_90s
jt		ontlitcp	sun-mach5	21341		g=g_90s
rh		ontlitcp	sun-mach5	21342		g=g_90s
ab		ontlitcp	sun-mach5	21343		g=g_90s
g_00s		group		-		-		i=2000
zooropa		ontlitcp	sun-mach6	21340		g=g_00s
pop		ontlitcp	sun-mach6	21341		g=g_00s
atyclb		ontlitcp	sun-mach6	21342		g=g_00s
htdaab		ontlitcp	sun-mach6	21323		g=g_00s

 

修改 onconfig 文件

下面的表 4 描述了在启动 ER 之前应该设置的 onconfig参数:

表 4. 修改 onconfig 文件

参数 描述
CDR_DSLOCKWAIT 指定 datasync(数据同步)组件等待数据库锁被释放的秒数。
CDR_NIFCOMPRESS 指定在将数据从源数据库服务器发送到目标数据库服务器之前,数据库服务器使用的压缩级别。
CDR_QUEUEMEM 任何 CDR 队列的最大内存量(KB);指定发送和接收队列使用的最大内存量。
CDR_SERIAL 指定在复制环境中的所有数据库服务器上,SERIAL 列是否使用不重复(惟一)的值。
CDR_DBSPACE 为 syscdr 数据库指定 dbspace(默认为 rootdbs)。
CDR_QHDR_DBSPACE 为来自队列的假脱机事务头信息指定 dbspace(默认值与编目相同);以轮循方式使用多个 sbspace。
CDR_QDATA_SBSPACE 设置为行数据 sbspace 的位置。如果没有在 ONCONFIG 中设置这个参数,或者 sbspace 名称是无效的,那么 Enterprise Replication 就无法定义服务器。以轮循方式使用多个 sbspace。建议为一些空间启用日志记录,一些不启用。ER 对于小事务使用启用日志的 sbspace,对于大事务使用禁用日志的空间。

九、ER:服务器

本节讨论以下主题:

服务器定义

使用命令行界面是定义 ER 环境的最快方法。至少需要运行两个命令。第一个命令定义初始服务器。在此之后,可以定义任意数量的服务器,但是必须使用 -S或 –sync选项将新服务器与已经定义的服务器之一连接起来。如果没有使用 sync选项,服务器就无法从 ER 的视角相互了解。

下面是可用的服务器定义选项和一个运行命令的示例:

清单 12. ‘cdr define server’ 命令选项和示例

                    
$ cdr define server
missing server name
usage: cdr define server {options} servername
 -c server --connect=server  connect to server
 -i min    --idle=min        idle timeout
 -s space  --send=space      dbspace where send queue created (obsolete)
 -r space  --recv=space      dbspace where recv queue created (obsolete)
 -A dir    --ats=dir         directory for Aborted Transaction Spool
 -R dir    --ris=dir         directory for Row Information Spool
 -I        --init            initialize server
 -S server --sync=server     synchronize catalog (use with -I)
 -N        --nonroot         non root server
 -L        --leaf            leaf server
 
$ cdr define server -A /informix/ats-ris/boy -R /informix/ats-ris/boy -I g_80s 

设置成功的证明

通过以下检查,确定设置已经成功:

  1. 两个服务器上都创建了 syscdr 数据库
  2. onstat -g ath显示以 ‘CDR’ 开头的复制线程
  3. onstat -g nif显示另一个复制服务器站点 id 项
  4. cdr list server显示活跃的连接
  5. onstat -g cat显示两个服务器都处于 ‘Active’ 状态
  6. online.log 显示与清单 13 相似的消息:
    清单 13. 执行 ‘cdr define server’ 之后产生的 online.log 消息

                                        
    12:50:57  Building 'syscdr' database ...
    12:51:00  'syscdr' database built successfully.
    12:51:01  CDR queuer initialization complete
    12:51:01  CDR NIF listening on asf://server_g_1
    

拓扑

拓扑主要是网络路由问题,与复制本身关系不大。ER 支持多节点环境和多种拓扑。如果路由要求副本跳过几个节点到达目标,那么被跳过的节点不需要了解副本、数据库或复制的表。

ER 节点常常是全连接的根节点,就像图 1 所示的情况:

图 1. 全连接的节点
全连接的节点

但是,业务需求可能要求采用其他拓扑。例如,常常采用集中星型(hub-spoke)拓扑,在这种拓扑中有一个大型中心节点(集线器)和一些小型节点。在这种情况下,集线器节点是惟一了解所有其他节点的节点,而 spoke 节点定义为叶节点。另外,ER 环境中的任何节点都可以是 HDR 对。

图 2. 集中星型拓扑
集中星型拓扑

非根节点有父节点,还可以有子节点。叶节点有父节点,但是不能有子节点。叶节点也不包含完整的 syscdr 数据库。它们只了解它们参与复制的副本的情况。

图 3. 根节点、非根节点和叶节点
根节点、非根节点和叶节点

请记住,复制环境中的任何节点都可以复制到环境中的任何其他节点。

图 4 给出一个层次化树型拓扑:

图 4. 层次化树型拓扑
层次化树型拓扑

图 5 给出一个树型拓扑的森林:

图 5. 树型拓扑的森林

表 5 描述可用的服务器节点类型及其性质:

表 5. 服务器节点选项

节点类型 有无父节点? 有无子节点? 有无完整的元数据? 命令选项
根节点 n/a
非根节点 -N
叶节点 -L

管理

本节讨论如何管理 Enterprise Replication 服务器,包括列出、修改、停止、重新启动、暂停、继续运行、连接、断开连接和删除服务器。

列出 ER 服务器

可以通过运行 cdr list server查看本地服务器已知的每个服务器的细节。这个命令还输出服务器组的队列的大小。

表 6. 服务器状态/状况值

状态 描述 状况 描述
Active 服务器是活跃的,正在进行复制。 Connected 服务器连接已经建立。
Deleted 服务器已经删除,不再捕捉或发送数据,队列被清空。 Connecting 服务器正在尝试连接。
Quiescent 服务器处于定义过程中。 Disconnect 服务器连接显式地中断。
Suspended 暂停向这个服务器发送复制数据。 Dropped 服务器连接由于网络错误而中断,服务器不可访问。
Error 发生一个错误(检查日志,如果需要的话,联系客户支持人员)。
Local 这个服务器是本地服务器,而不是远程服务器。
Timeout 连接由于空闲超时而中断。

清单 14 演示运行这个命令的不同方式:
清单 14. cdr list server 的语法

                      
$ cdr list server -x
usage: cdr list server [-c server] servername
 -c server --connect=server  connect to server
$ cdr list server
SERVER                 ID STATE    STATUS     QUEUE  CONNECTION CHANGED
-----------------------------------------------------------------------
g_00s                2000 Active   Dropped         0 Jun  5 10:35:29
g_80s                  80 Active   Local           0                
g_90s                  90 Suspend  Dropped         0 Jun  5 10:35:39
$ cdr list server g_80s
NAME                 ID     ATTRIBUTES
---------------------------------------
g_80s                  80 atsdir=/informix/ats-ris/boy risdir=/informix/ats-ris/boy
$ cdr list server -c g_90s g_90s
NAME                 ID     ATTRIBUTES
---------------------------------------
g_90s                  90 atsdir=/informix/ats-ris/uf risdir=/informix/ats-ris/uf

修改 ER 服务器

可以使用 cdr modify server命令修改三个服务器属性:

  • 空闲超时
  • Aborted Transaction Spooling(ATS)文件的目录位置
  • Row Information Spooling(RIS)文件的目录位置
清单 15. ‘cdr modify server’ 的选项

                            
usage: cdr modify server [-i min] [-A dir] [-R dir] [-m p | r] [-l on|off] server
 -c server --connect=server  connect to server
 -i min    --idle=min        idle timeout
 -A dir    --ats=dir         directory for Aborted Transaction Spool
 -R dir    --ris=dir         directory for Row Information Spool
 -m mode   --mode=mode       set server mode (primary or readonly)

还有几个与 ER 相关的服务器配置参数,可以动态地修改这些参数。更多信息请参考 IBM Informix Dynamic Server Enterprise Replication Guide

停止 ER 服务器

可以使用 cdr stop命令临时停止 ER 线程,而不停止服务器。在使用 cdr stop时,ER 停止读取逻辑日志和寻找要复制的数据。在 ER 停止时,要确保当时没有数据库活动发生(否则,这个站点就会与其他服务器不同步)。这个站点上的 ER 线程会一直停止,直到运行 cdr start命令为止。

警告:在停止 ER 时,向这个站点进行复制的其他 ER 服务器会把未完成的事务在它们的发送队列中积累起来,直到这个站点恢复运行(或删除)。

清单 16. cdr stop 语法

$ cdr stop -x
usage: cdr stop [-c server]

重新启动 ER 服务器

要想重新启动已经停止的 ER 服务器,应该使用 cdr start。在重新启动服务器时,ER 线程启动并从重放位置(原来停止的位置)继续计算逻辑日志。如果重放的位置指向的逻辑日志不再存在,那么重新启动失败,在服务器上 ER 不处于活跃状态。

清单 17. cdr start 语法

$ cdr start -x
usage: cdr start [-c server]
-c server –connect=server  connect to server

暂停 ER 服务器

cdr stop命令会完全关闭所有 ER 线程;与其相反,可以使用 cdr suspend server命令暂停向服务器复制数据。当 ER 暂停时,源服务器将复制的数据放到发送队列中,并暂停向目标服务器发送数据。源服务器会继续发送其他消息,比如确认和控制消息。

清单 18. cdr suspend server 的语法

usage: cdr suspend server [-c server] servername
-c server –connect=server  connect to server

继续运行 ER 服务器

要想在暂停的服务器上继续运行 ER,应该使用 cdr resume server。在服务器继续运行之后,发送队列中的数据。

清单 19. cdr resume server 的语法

$ cdr resume server -x
usage: cdr resume server [-c server] servername
-c server –connect=server  connect to server

连接 ER 服务器

connect命令尝试重新连接一个用 cdr disconnect server命令中断了连接的数据库服务器。

清单 20. cdr connect server 的语法

$ cdr connect server -x
usage: cdr connect server [-c server] servername
-c server –connect=server  connect to server

断开 ER 服务器的连接

disconnect命令中断两个服务器(servername 和 –connect选项中指定的服务器)之间的连接。如果没有使用 –connect选项,那么这个命令中断 servername 和默认服务器(由 INFORMIXSERVER环境变量指定)之间的连接。

清单 21. cdr disconnect server 的语法

$ cdr disconnect server -x
usage: cdr disconnect server [-c server] servername
-c server –connect=server  connect to server

删除 ER 服务器

要想删除 ER 服务器,应该使用 cdr delete server。奇怪之处在于,必须运行 cdr delete server 两次。例如,要想从三节点的 ER 环境中删除服务器组 g_80s,那么需要运行以下命令:

清单 22. cdr delete server 的示例

cdr delete server g_80s
cdr delete server –connect=g_90s g_80s

第一个命令从 ER 环境中删除本地服务器组(g_80s),第二个命令连接复制环境中的另一个服务器并从那个服务器上删除 g_80s。然后,这个修改会复制到复制环境中的所有其他服务器。

清单 23. cdr delete server 的语法

$ cdr delete server -x
usage: cdr delete server servername
-c server –connect=server  connect to server
-f    –force  force the server to be deleted, even in an error condition

练习

现在来练习设置 ER 服务器。这个练习帮助您回顾 cdr命令并设置本教程中用来测试的两个服务器。

练习:使用已经定义的两个测试引擎和 cdr命令,设置两个相互连接的 ER 服务器,并在每个服务器上查看对方。

解决方案

练习:应该执行以下步骤:

  1. 添加一个 SBSPACE,并在 onconfig 文件参数 CDR_QDATA_SBSPACE中设置它的名称。
  2. 定义两个 ER 服务器:
    • 在第一个服务器上:cdr define server -A /informix/ats-ris/boy -R /informix/ats-ris/boy -I g_80s
    • 在第二个服务器上:cdr define server -A /informix/ats-ris/uf -R /informix/ats-ris/uf -I g_90s -S g_80s
  3. 检查服务器是否能够看到对方:
    • 检查 syscdr 数据库是否存在
    • 在消息日志中,检查与启动 ER 和创建 syscdr 数据库相关的消息
    • 运行 onstat -g nif,应该会看到另一个服务器。在每个节点上运行这个命令
    • 运行 cdr list server。应该会在列表中看到定义的两个服务器。在每个节点上运行这个命令

九、ER:复制

本节讨论以下主题:

副本定义

在计划创建副本时,要考虑以下因素:

  • 使用非缓冲的数据库日志记录
  • 启用行级锁来获得更好的目标并发性
  • 决定复制类型 —— update anywhere 或主/目标
  • 决定冲突解决规则 —— 忽略、总是、时间戳、存储过程
  • 使用冲突解决方法在表中添加 CRCOLS
  • 决定复制的数据的范围 —— 行或事务
  • 考虑其他复制选项,比如 ATS、RIS、fullrow、忽略删除、频率、浮点格式
  • 确保表中存在主键

清单 24 中的示例在三个节点上定义一个简单的副本(采用 update anywhere 形式)。注意,列出每个参与服务器的行采用以下格式:“database_name@server_group:table_owner.table_name” “SELECT语句和可选的 WHERE子句”:

清单 24. update anywhere 副本的示例

cdr def repl -I -C timestamp -S trans items_rep \
“stores7@g_80s:informix.items” “select * from items” \
“stores7@g_90s:informix.items” “select * from items” \
“stores7@g_00s:informix.items” “select * from items”

清单 25 给出相同的语句,但是这一次定义的是主/目标副本:

清单 25. 主/目标副本的示例

cdr def repl -I -C timestamp -S trans items_rep \
“P stores7@g_80s:informix.items” “select * from items” \
“R stores7@g_90s:informix.items” “select * from items” \
“R stores7@g_00s:informix.items” “select * from items”

清单 26. cdr define replicate 的语法

                            
$ cdr define replicate -x
usage: cdr define repl [-c server] [-vuiAFIORTm] -C rule(s) [-M master] [-S scope]
            [-n y/n] [-t] [-a time] [-e intvl] [-f y|n] [-D y/n] repl
 participant
 -M        --master=<node>   define master replicate
 -t        --empty           Empty mastered replicate
 -n        --name=y|n        mastered replicate name verification
 -v        --verify          verify the existing replicates using master definition
 -u        --autocreate      automatically create tables if they do not exists
 -a time   --at=time         replicate at specified time
 -c server --connect=server  connect to server
 -e intvl  --every=intvl     replicate every intvl minutes
 -i        --immediate       continuous replication (default)
 -A        --ats             aborted transaction spooling
 -C rule[,rule] --conflict=rule[,rule]  conflict resolution rule(s)
 -F        --floatcanon      transfer floating point in canonical form
                             (deprecated)
 -I        --floatieee       transfer floating point in IEEE form (recommended)
 -O        --optimize        don't call procedure unless different server
 -R        --ris             row information spooling
 -T        --firetrigger     fire triggers when replicating
 -S scope  --scope=scope     scope of conflict resolution (row or trans)
 -f y|n    --fullrow y|n     Enable/Disable sending of full row for updates
 -m <primary repl> --mirrors <primary repl>   Define a shadow replicate
 -D y|n    --ignoredel y|n   do not process any deletes on targets

主副本

什么是主副本(master replicate)?主副本可以保证 ER 环境中服务器之间的一致性。它们具有以下好处:

  • 检查所有参与服务器的表模式是否与主副本定义匹配,从而确保数据完整性
  • 如果表在目标节点上不存在,就自动创建表
  • 允许更改复制的表上的操作

有三种主副本类型:

  1. Normal —— 列名不必匹配,但是模式必须匹配
  2. Strict —— 所有参与服务器的表必须具有相同的列名和模式性质
  3. Empty —— 指定一个参与服务器作为主副本的基础,但是不在副本中包含这个参与服务器

副本集

副本集是几个副本的逻辑集合,可以作为一个单元进行管理。通过使用副本集,可以只用一个命令启动、停止、暂停或继续运行副本集中的所有副本。有两种副本集类型:排他(exclusive)和非排他(non-exclusive)。

排他副本集要求所有副本具有相同的状态和频率设置。属于一个排他副本集的副本不能同时属于其他任何副本集。使用 –exclusive选项创建排他副本集。

非排他副本集既允许对副本集中的副本进行统一管理,也允许单独管理。这意味着非排他副本集中的副本可以具有不同的状态;非排他副本集本身没有状态。另外,一个副本可以属于多个非排他副本集。

清单 27. cdr define replicateset 的语法

                    
$ cdr define replicateset -x
usage: cdr define replicateset [-c server] [-i ] [-e hh:mm] [-a day.hh:mm] [-x ]
          ReplSetName repl
 -a time   --at=time         replicate at specified time
 -c server --connect=server  connect to server
 -e intvl  --every=intvl     replicate every intvl minutes
 -i        --immediate       continuous replication (default)
 -X        --exclusive       Exclusive Replset.

模板

模板是副本集的一种特殊形式,可以帮助在新的 ER 节点上部署副本,包括自动地创建表和数据同步。在构建模板时,ER 会为每个表创建空的主副本,并包含在副本集中。可以分别列出每个表,也可以只提供要使用的数据库名,这样就会包含这个数据库中的所有表。在完成模板之后,必须使用 cdr realize template命令进行实例化或实现。实现模板之后,ER 会执行以下操作:

  • 如果数据库在目标节点上不存在,就自动创建数据库
  • 如果表在目标节点上不存在,就自动创建表
  • 表同步/填充

清单 28. cdr define template 的语法

                    
$ cdr define template -x
usage: cdr define template TemplateName -C rule(s) -M server [-S scope]
                  [-c server] [-xaAFIORTX] [-D y|n]
                   -d database  [-f file]|[Table(s)]
 -C rule[,rule] --conflict=rule[,rule]  conflict resolution rule(s)
 -S scope  --scope=scope     scope of conflict resolution (row or trans)
 -M        --master=<node>   define master replicate
 -c server --connect=server  connect to server
 -A        --ats             aborted transaction spooling
 -F        --floatcanon      transfer floating point in canonical form
                             (deprecated)
 -I        --floatieee       transfer floating point in IEEE form (recommended)
 -O        --optimize        don't call procedure unless different server
 -R        --ris             row information spooling
 -T        --firetrigger     fire triggers when replicating
 -D y|n    --ignoredel y|n   do not process any deletes on targets
 -X        --exclusive       Exclusive template.
 -d        --database=<name> database to be used to obtain the table info 
 -a        --all             include all tables in template
 -f        --file=<name>     file to obtain the list of table participants 

清单 29 中的示例在三个节点上为 stores7 数据库设置一个模板。注意:在运行这个命令之前,需要在基表中添加 CRCOLS 列。

清单 29. 为 stores7 数据库创建模板

                    
cdr define template stores7_template -C timestamp -S trans -M g_80s -A -R \
  -d stores7 call_type catalog cust_calls customer items manufact orders state 
  stock
cdr realize template stores7_template -u -S g_80s \
  "stores7@g_80s" "stores7@g_90s" "stores7@g_00s"

 

管理

本节讨论如何管理副本、副本集和模板,包括修改、列出、启动、停止、暂停、继续运行和删除。管理副本和副本集的大多数命令非常相似,所以本节只讨论副本的管理。

修改 ER 副本

可以对现有的副本进行两种修改:

  • 添加或删除参与服务器
  • 修改副本属性

使用以下命令添加或删除参与服务器:

清单 30. cdr change replicate 的语法

                    
$ cdr change replicate -x
usage: cdr change repl [-c server] [-a | -d] [-v | -u] replicate participant
 -c server --connect=server  connect to server
 -a        --add             add participant
 -d        --del             remove participant
 -v        --verify          verify the existing replicates using master definition
 -u        --autocreate      automatically create tables if they do not exists

使用 cdr modify replicate命令修改副本属性。有一些限制:不能将冲突解决选项从忽略改为非忽略,也不能将非忽略选项改为忽略。

清单 31. cdr modify replicate 的语法

                    
$ cdr modify replicate -x
usage: cdr modify repl  [-AORT] -C rule(s) [-i] [-a time] [-e min] [-f y|n] 
replicate
 -a time   --at=time         replicate at specified time
 -c server --connect=server  connect to server
 -e intvl  --every=intvl     replicate every intvl minutes
 -i        --immediate       continuous replication (default)
 -A (y/n)  --ats             aborted transaction spooling
 -C rule[,rule] --conflict=rule[,rule]  conflict resolution rule(s)
 -O        --optimize        don't call procedure unless different server
 -R (y/n)  --ris             row information spooling
 -T (y/n)  --firetrigger     fire triggers when replicating
 -S scope  --scope=scope     scope of conflict resolution (row or trans)
 -f y|n    --fullrow y|n     Enable/Disable sending of full row for updates
 -D y|n    --ignoredel y|n   do not process any deletes on targets
 -n        --name=n          mastered replicate name verification

列出 ER 副本

有三种运行 cdr list replicate命令的方式。如果省略副本名,那么会产生所有已经定义的副本的详细信息。如果使用 brief选项,就会产生所有副本的参与服务器列表。如果提供副本名,那么产生副本属性的详细列表。

清单 32. cdr list replicate 的语法

$ cdr list repl -x
usage: cdr list repl [-c server] [brief|full] [replicate(s)]
-c server –connect=server  connect to server

启动 ER 副本

根据定义,刚创建的副本是不活跃的。要想启用副本并让 ER 搜索针对这个表的活动的日志,就必须使用 cdr start replicate。可以有选择地在一个或多个节点上启动一个副本,也可以在副本的所有参与节点上启动它。

清单 33. cdr start replicate 的语法

                    
$ cdr start repl -x
usage: cdr start repl [-c server]  [-S server [-e keep|delete|merge]] 
                   replicate [TargetServers] 
 -c server --connect=server  connect to server
 -S server --syncdatasource=server server to be used as a data source for sync
 -e        --extratargetrows=[keep|delete|merge] handle extra row during sync
 TargetServers               List of TargetServers to be started.
                             Separate servers in the list by space.

停止 ER 副本

使用 cdr stop replicate命令停止副本。这个命令将副本的状态设置为 inactive 并删除这个副本的所有发送队列数据。

清单 34. cdr stop replicate 的语法

                    
$ cdr stop repl -x
usage: cdr stop repl [-c server] replicate server(s)
 -c server --connect=server  connect to server

暂停 ER 副本

使用 cdr suspend replicate命令暂停复制副本的数据。在副本暂停时,ER 捕捉对源数据库的修改并在队列中积累这些修改,但是不将捕捉到的数据发送到目标。如果在环境中引用完整性很重要,就不要使用这个命令,因为 ER 无法支持它。而是应该暂停服务器。

清单 35. cdr suspend replicate 的语法

                    
$ cdr suspend repl -x 
usage: cdr suspend repl [-c server] replicate(s)
 -c server --connect=server  connect to server

 

继续运行 ER 副本

使用 cdr resume replicate命令继续运行暂停的副本。

清单 36. cdr resume replicate 的语法

                    
$ cdr resume repl -x
usage: cdr resume repl [-c server] replicate(s)
 -c server --connect=server  connect to server

删除 ER 副本

使用 cdr delete replicate命令从 ER 环境中删除一个副本。ER 会从这个服务器和参与服务器列表中的所有其他节点上删除这个副本的所有引用。根据这个副本的发送队列中的数据量的不同,删除操作可能需要一些时间才能完成。

清单 37. cdr delete replicate 的语法

                    
$ cdr delete repl -x
usage: cdr delete repl [-c server] replicate(s)
 -c server --connect=server  connect to server

十、ER:冲突解决

当多个数据库服务器试图同时更新同一行时(更新的时间戳是相同的 GMT 时间),就会发生冲突。ER 必须判断出要复制的新数据。为了解决冲突,必须指定冲突解决规则和规则的事务范围。本节讨论以下主题:

方法

有五个不同的冲突解决选项,它们的表现各不相同。下面的表总结了这些方法:

表 7. 冲突解决选项

规则 描述
Ignore(忽略) ER 不尝试解决冲突。
Time stamp(时间戳) 应用时间戳最近的行或事务。
SPL routine(SPL 例程) ER 使用一个用 SPL(Stored Procedure Language)编写的例程来判断应该应用的数据。
Time stamp with SPL routine(结合使用时间戳与 SPL 例程) 如果时间戳相同,那么 ER 就调用 SPL 例程来解决冲突。
Always-apply(总是应用) ER 不尝试解决冲突,总是把源数据应用于目标。

表 8. 忽略冲突解决

目标是否存在键值? 插入 更新 删除
No 应用源记录 丢弃源记录 丢弃源记录
Yes 丢弃源记录 应用源记录 应用源记录

表 9. 时间戳冲突解决
时间戳冲突解决

表 10. “总是应用” 冲突解决

目标是否存在键值? 插入 更新 删除
No 应用源记录 将行作为 upsert 应用 将行应用于影子表
Yes 将行作为 upsert 应用,覆盖现有行 应用行 删除行

副本范围

副本的范围(事务或行)定义 ER 如何对故障做出反应。故障可能由冲突、锁问题等造成。如果范围是 ‘row’,那么只有单独的行失败;但是,如果范围是 ‘transaction’,那么整个事务都将失败。

影子对象

为了解决冲突,需要了解两种影子对象:

  • 影子列
  • 影子表

影子列

对于使用时间戳或存储过程冲突解决选项的所有表,复制过程使用影子列实现冲突解决。这些列也称为 CRCOLS 或冲突解决列。它们由两个字段组成,cdrserver 和 cdrtime。cdrserver 是一个惟一 ID,表示行的源服务器 id。cdrtime 是一个时间戳,表示在源服务器上执行提交的时间。

影子表

ER 创建影子表(即删除表)来存储已经删除的行,直到删除操作完全传播出去为止。影子表包含删除的行的完整拷贝(包括影子列)。只要冲突解决类型不是忽略,那么在创建副本时,就会创建影子表。在 syscdr 数据库的 ‘deltabdef’ 表中包含复制的表和影子表之间的关系。

ATS 和 RIS 文件

Aborted Transaction Spooling

如果一个事务无法应用,ER 就会从接收队列中删除失败的事务,并在指定的 ATS 目录中写入一个文件,其中包含整个事务的详细信息。只在整个事务失败的情况下,执行 ATS spooling。每个失败的事务被写到 ATS 配置参数指定的目录中的一个外部文件中。ATS 和 RIS 文件的默认位置是 /tmp。ATS 文件名的格式是 ats.targetServername.sourceServername.threadId.timestamp.sequence,其中各个部分的含义如下:

  • targetServername —— 接收这个事务的 ER 服务器的名称
  • sourceServername —— 发送这个事务的 ER 服务器的名称
  • threadId —— 处理这个事务的线程
  • timestamp —— 创建 ATS 文件时 cdrtime 的值
  • sequence —— 对于每个文件递增的惟一整数

示例:

  • ats.test1.test3.D_1.970827_14:23:42.4
  • ats.test2.test3.D_1.970827_14:23:41.4

Row Information Spooling

在插入转换为更新和更新转换为插入时,ER 将失败的行错误记录在 RIS 文件中。另外,如果用来解决冲突的存储过程失败了,那么用返回码生成一个 RIS 文件。RIS 文件名的格式与 ATS 文件名相同。下面是一些示例:

  • ris.test1.test3.D_1.970827_14:23:42.3
  • ris.test2.test3.D_1.970827_14:23:41.3

练习

这个练习实践复制和冲突解决方面的操作。通过这个练习,您应该能够看到 ER 如何用时间戳和忽略选项处理冲突。

练习:执行以下步骤:

表 11. 冲突解决练习

步骤 描述
1 定义下面的表:
清单 38. 创建 rocket

CREATE table rocket(

rocket_id       int,

rocket_name     char(20),

rocket_cost     money(10,2),

launch_date     datetime year to second,

primary key (rocket_id,rocket_name))

with crcols;

2 定义一个副本,这个副本在系统的其他节点上创建这个表。这个副本包含以下属性:

  • 时间戳冲突解决选项
  • 事务范围
  • ATS 和 RIS 错误日志记录
3 启动副本并插入以下行:
清单 39. 插入行

insert into rocket values (10,”Gemini”,500000.00,today);

insert into rocket values (20,”Apollo13″,800000.00,today);

insert into rocket values (30,”Ramjet”,400000.00,today);

insert into rocket values (40,”Ramjet2″,1000000.00,today);

4 暂停副本
5 在两个服务器上执行以下更新。一定要按照这里的次序执行更新(首先执行 T1)。
清单 40. 执行更新

(T1) 在服务器 A 上

UPDATE rocket set rocket_cost = 600000.00

where rocket_cost = 500000.00 and rocket_name = “Gemini”;

(T2) 在服务器 B 上

UPDATE rocket set rocket_cost = 700000.00

where rocket_cost = 500000.00 and rocket_name = “Gemini”;

6 继续执行副本。在两个服务器上 Gemini 的成本值是相同的吗?值为多少?在哪里进行冲突探测?在哪里执行冲突解决?在每个服务器上查询数据库来证实您的猜测。
7 检查是否生成了任何日志消息。每个服务器上应该会生成一个日志消息。是什么导致生成 ATS 和 RIS 文件?

解决方案

解决方案:应该执行以下步骤:

表 12. 冲突解决解决方案

步骤 描述
1 定义下面的表:
清单 41. 创建 rocket

CREATE table rocket(

rocket_id       int,

rocket_name     char(20),

rocket_cost     money(10,2),

launch_date     datetime year to second,

primary key (rocket_id,rocket_name))

with crcols;

2 定义一个副本,这个副本在系统的其他节点上创建这个表。这个副本包含以下属性:

  • 时间戳冲突解决选项
  • 事务范围
  • ATS 和 RIS 错误日志记录

清单 42. rocket 表定义副本

cdr def repl -M g_80s -n n -u -C “timestamp” -S tran -A -R rocketrep \

“stores7@g_80s:informix.rocket” “select * from rocket” \

“stores7@g_90s:informix.rocket” “select * from rocket”

定义副本的语句产生以下输出:
清单 43. 检验 rocket 表的副本

$ ./def_rocketrep.sh

 

Verification of stores7@g_80s:informix.rocket started

Verification of stores7@g_80s:informix.rocket is successful

Verification of stores7@g_90s:informix.rocket started

Creating table…

create table informix.rocket (

rocket_id        integer,

rocket_name      char(20),

rocket_cost      money(10,2),

launch_date      datetime year to second,

primary key (rocket_id, rocket_name)) with CRCOLS lock mode row;

 

Verification of stores7@g_90s:informix.rocket is successful

3 启动副本并插入以下行:
清单 44. 启动副本

cdr start repl rocketrep

清单 45. rocket 表中插入行

insert into rocket values (10,”Gemini”,500000.00,today);

insert into rocket values (20,”Apollo13″,800000.00,today);

insert into rocket values (30,”Ramjet”,400000.00,today);

insert into rocket values (40,”Ramjet2″,1000000.00,today);

4 暂停副本:
清单 46. 暂停副本

cdr suspend repl rocketrep

检查onstat -g cat的输出,副本的状态应该是 SUSPENDED。

5 在两个服务器上执行以下更新。一定要按照这里的次序执行更新(首先执行 T1)。
清单 47. 执行更新

(T1) 在服务器 A 上

UPDATE rocket set rocket_cost = 600000.00

where rocket_cost = 500000.00 and rocket_name = “Gemini”;

(T2) 在服务器 B 上

UPDATE rocket set rocket_cost = 700000.00

where rocket_cost = 500000.00 and rocket_name = “Gemini”;

6 继续执行副本 —— cdr resume repl rocketrep。在两个服务器上 Gemini 的成本值是相同的吗?值为多少?在哪里进行冲突探测?在哪里执行冲突解决?在每个服务器上查询数据库来证实您的猜测。
清单 48. 更新的结果

on server A

rocket_id rocket_name           rocket_cost launch_date

 

10 Gemini                 $600000.00 2007-06-09 00:00:00

20 Apollo13               $800000.00 2007-06-09 00:00:00

30 Ramjet                 $400000.00 2007-06-09 00:00:00

40 Ramjet2               $1000000.00 2007-06-09 00:00:00

 

on server B

rocket_id rocket_name           rocket_cost launch_date

 

10 Gemini                 $700000.00 2007-06-09 00:00:00

20 Apollo13               $800000.00 2007-06-09 00:00:00

30 Ramjet                 $400000.00 2007-06-09 00:00:00

40 Ramjet2              $1000000.00 2007-06-09 00:00:00

如果先在服务器 B 上运行更新,然后是服务器 A,那么结果可能不一样。

7 检查是否生成了任何日志消息。是什么导致生成 ATS 和 RIS 文件?
清单 49. 消息日志文件

15:28:51 CDR CDRD_3: transaction aborted (One or more rows in a

transaction defined with tx scope were rejected) with sql error 0 isam

error 0.

15:28:51 CDR CDRD_3: failed transaction spooled to file

/informix/ats-ris/boy/ats.g_80s.g_90s.D_3.070609_15:28:51.2

清单 50. ATS 文件内容

$ more ats.g_80s.g_90s.D_3.070609_15:28:51.2

TXH RIS file:/informix/ats-ris/boy/ris.g_80s.g_90s.D_3.070609_15:28:51.1

has also been created for this transaction

==========

TXH Source ID:90 / Name:g_90s / CommitTime:07-06-09 15:26:40

TXH Target ID:80 / Name:g_80s / ReceiveTime:07-06-09 15:28:51

TXH Number of rows processed when transaction was aborted:1

TXH One or more rows in a transaction defined with tx scope were rejected

TXH CDR:14 (Error: Failed conflict resolution rule) / SQL:0 / ISAM:0

———-

RRH Row:1 / Replicate Id: 5242884 / Table: stores7@informix.rocket /

DbOp:Update

RRS 90 (g_90s)|1181420800 (07/06/09 15:26:40)

RRD 10|Gemini|700000.00|2007-06-09 00:00:00

清单 51. RIS 文件内容

$ more ris.g_80s.g_90s.D_3.070609_15:28:51.1

TXH Source ID:90 / Name:g_90s / CommitTime:07-06-09 15:26:40

TXH Target ID:80 / Name:g_80s / ReceiveTime:07-06-09 15:28:51

———-

RRH Row:1 / Replicate Id: 5242884 / Table: stores7@informix.rocket /

DbOp:Update

RRH CDR:14 (Error: Failed conflict resolution rule) / SQL:0 / ISAM:0

LRS 80 (g_80s)|1181420912 (07/06/09 15:28:32)

LRD 10|Gemini|600000.00|2007-06-09 00:00:00

RRS 90 (g_90s)|1181420800 (07/06/09 15:26:40)

RRD 10|Gemini|700000.00|2007-06-09 00:00:00

==========

TXH Transaction aborted

TXH ATS file:/informix/ats-ris/boy/ats.g_80s.g_90s.D_3.070609_15:28:51.2

has also been created for this transaction

十一、ER:监视

本节讨论以下主题:

概述

本节主要关注应该 监视什么,而不是可以 监视什么。可以收集的信息量非常大,无法在本教程中全面讨论。所以本节只讨论经常出现问题的领域,以及在深入研究之前需要检查的领域。问题常常只与一个服务器相关,比如日志文件写满、引擎停止运行或连接问题。尽管实际问题可能只发生在一个服务器上,但是应该分别检查每个 ER 服务器。请记住,ER 是在 IDS、操作系统和网络之上建立的。这些部分都可能导致 ER 出现问题。确定问题出现在某个服务器上之后,就要深入研究 ER 的数据流。

onstat

表 13 列出了对于 Enterprise Replication 比较重要的 onstat选项。本节后面会详细讨论那些粗体显示的选项:

表 13. ER onstat 选项

onstat 功能 描述
onstat -g cat 全局编目 记录 ER 内部状态和活动的内存结构
onsat -g ddr 搜索和重放位置 扫描日志页面并决定要复制的日志记录
onsat -g grp 分组器 在提交事务之前持有事务、压缩事务、对事务进行排队以便发送
onsat -g nif 网络接口功能 处理每个连接的数据包压缩和发送/接收线程
onsat -g dss 数据同步统计 在目标实例上重放复制的数据,处理冲突解决,数据映射
onsat -g rcv 接收统计信息和数据同步摘要 接收和发送队列器、全局编目和数据同步组件的消息
onsat -g rqm 队列信息 维护 ER 使用的消息队列(SENDQ、CNTRLQ、ACKQ、SYNCQ、RECVQ)

onstat -g ddr

这个命令查看三个重要的逻辑日志位置,从而判断 ER 的表现。这些位置由逻辑日志惟一 ID 和逻辑日志位置指定。这些位置是:

  • 当前 ID / 位置 —— 应用程序线程插入新的逻辑日志记录的位置
  • 搜索 ID / 位置 —— ER 当前在逻辑日志中正在 “搜索” 的位置
  • 重放 ID / 位置 —— 如果暂停的话,ER 重新启动 “搜索” 的位置

清单 52. ‘onstat -g ddr’ 的输出

                    
$ onstat -g ddr
IBM Informix Dynamic Server Version 11.10.FC1     -- On-Line (Prim) -- Up 16 days 
18:50:41 -- 196608 Kbytes
DDR -- Running --  
# Event  Snoopy   Snoopy   Replay   Replay   Current  Current 
Buffers   ID      Position  ID      Position   ID     Position
528      11       643018   11       4f3070   11       644000  
Log Pages Snooped:
      From      From      Tossed
     Cache      Disk  (LBC full)
      5992       612           0
Total dynamic log requests: 0              
DDR events queue
Type   TX id    Partnum  Row id  

正如在 onstat -g ddr的输出中看到的,重放位置和搜索位置应该正在向前推进。如果重放位置没有前进,这说明发送队列已满,或者远程服务器关闭。如果搜索位置没有移动,那么可能是 ddr_snoopy 线程出了问题。

如果数据库服务器将要覆盖 ER 还没有处理的逻辑日志,ER 就会进入 DDRBLOCK 模式。在服务器处于 DDRBLOCK 模式期间,尽管用户事务会被阻塞,但是 ER 活动可以继续执行。在此期间,ER 尝试处理事务,从而将重放位置向前推进,避免日志文件被用光。

onstat -g nif

这个命令指出(服务器已知)站点是否连接,并显示发送和接收的字节数。这有助于找到暂停的站点(相对于其他活动站点)。在下面清单 53 中的输出示例中可以看到,站点 g_90s 处于 SUSPEND 状态。这意味着有人在这个站点上运行了 cdr suspend server。如果该服务器离线,这个输出中就不会列出它。(参见 cdr list server提供的信息。)

清单 53. onstat -g nif 的输出

                    
$ onstat -g nif
IBM Informix Dynamic Server Version 11.10.FC1     -- On-Line (Prim) -- Up 16 days 
20:17:51 -- 196608 Kbytes
NIF anchor Block: fe0a678
	nifGState       	RUN
	   RetryTimeout 	300
CDR connections:
 Id    Name               State               Version       Sent   Received
---------------------------------------------------------------------------
2000 g_00s                RUN                       9       5559         18
  90 g_90s                RUN,SUSPEND               9       5562         17

有时候,在这个输出中可能看到 “BLOCK” 状态。阻塞状态意味着这个站点无法处理更多的信息,并请求不要再向它发送更多的数据。这个状态应该是临时的,常常只会持续几分钟。如果 BLOCK 状态持续存在,那么要进一步检查这个站点。

onstat -g rqm

这个命令输出五个 ER 队列的相关信息:SENDQ、CNTRLQ、ACKQ、SYNCQ、RECVQ。每个队列有自己的选项,还可以使用以下选项之一查看所有队列的信息:FULL、BRIEF、VERBOSE。清单 54 中的输出示例显示一个队列的所有信息。输出分为五个部分:

  1. 队列的活动和摘要信息
  2. 队列的进度表
  3. 队列中与目标服务器相关的条目的服务器和副本细节
  4. 队列中第一个和最后一个事务的细节
  5. 正在处理这个队列的线程的细节

清单 54. onstat -g rqm sendq 的输出

                    
$ onstat -g rqm sendq
IBM Informix Dynamic Server Version 11.10.FC1     -- On-Line (Prim) -- Up 16 days 
20:46:32 -- 196608 Kbytes
CDR Reliable Queue Manager (RQM) Statistics:
RQM Statistics for Queue (0xfdb1028) trg_send
 Transaction Spool Name: trg_send_stxn
 Insert Stamp: 6161/0
 Flags: SEND_Q, SPOOLED, PROGRESS_TABLE, NEED_ACK
 Txns in queue:             4003
 Log Events in queue:       0
 Txns in memory:            4003
 Txns in spool only:        0
 Txns spooled:              4001
 Unspooled bytes:           210
 Size of Data in queue:     849555  Bytes
 Real memory in use:        849555  Bytes
 Pending Txn Buffers:       0
 Pending Txn Data:          0 Bytes
 Max Real memory data used: 849555 (1843200) Bytes
 Max Real memory hdrs used  1206340 (1843200) Bytes
 Total data queued:         1188006  Bytes
 Total Txns queued:         6161
 Total Txns spooled:        4001
 Total Txns restored:       0
 Total Txns recovered:      0
 Spool Rows read:           0
 Total Txns deleted:        2158
 Total Txns duplicated:     0
 Total Txn Lookups:         29232
 Progress Table:
	Progress Table is Stable
		On-disk table name............:		spttrg_send
		Flush interval (time).........:		30
		Time of last flush............:		1181403392
		Flush interval (serial number):		1000
		Serial number of last flush...:		5
		Current serial number.........:		5
Server    Group Bytes Queued      Acked	    		    Sent
------------------------------------------------------------------------------
  2000 0x500001                  0 50/b/4e8118/0            -        50/b/4e8118/0
    90 0x500001                  0 50/b/4e8118/0            -        50/b/4e8118/0
 Traverse handle (0x104f0028) for thread CDRGeval1 at Head_of_Q,  Flags: None
 Traverse handle (0x10483028) for thread CDRGeval0 at Head_of_Q,  Flags: None
 Traverse handle (0x10351028) for thread CDRGeval2 at Head_of_Q,  Flags: None
 Traverse handle (0x1034f028) for thread CDRACK_0 at Head_of_Q,  Flags: None
 Traverse handle (0x1048c028) for thread CDRACK_1 at Head_of_Q,  Flags: None
 Traverse handle (0x10288028) for thread CDRNrA90 at Head_of_Q,  Flags: None
 Traverse handle (0xfe60028) for thread CDRNsA2000 at Head_of_Q,  Flags: None
 Traverse handle (0x102b9028) for thread CDRNrA2000 at Head_of_Q,  Flags: None

syscdr 数据库

IBM Informix Dynamic Server Enterprise Replication Guide 中详细描述了为 ER 添加的所有 SMI(sysmaster 数据库)表。这些 SMI 表是基于 syscdr 数据库的视图,而且可能将几个表组合在一个视图中。在 $INFORMIXDIR/etc/syscdr.sql 中可以找到这些表的模式,在 $INFORMIXDIR/etc/syscdrview.sql 中可以找到在 sysmaster 中创建的视图。

如果 onstat命令和 cdr命令的输出之间出现差异,那么可能需要查看这些表。onstat实用程序总是从共享内存读取信息,而 cdr实用程序读取全局编目(也称为 syscdr 数据库)。

表 14. syscdr 表

表名 描述
hostdef_tab Enterprise Replication 服务器信息(就像 SQLHOSTS)
protodef_tab 服务器协议信息
servdef_tab 服务器定义
repdef_tab 副本定义
triggerdef_tab ER 触发器定义
triggercol_tab ER 触发器列
partdef_tab 副本的参与服务器
mastered_replicates_tab 主副本描述
mastered_syscolumns_tab 主副本列
mastered_sysxtdtypes_tab 主扩展类型
mastered_sysattr_tab 扩展类型的属性
rsncjobdef_tab resync 作业定义表
rsncjobdeps resync 作业依赖项
rsncprocnames_tab Resync 过程名
delrepl 删除的副本表
replsetdef_tab 副本集定义
replsetpartdef 副本集中的副本
servroute 服务器路由表
cdr_errors 错误日志
gcversion 全局编目版本
swaploginfo 交换日志位置表
shadow_event_info 影子副本事件表
replaytab 重放位置表
recvcntldup 接收控制消息重复探测
cdrstatedef_tab CDR 编目状态
deltabdef_tab 活跃删除表定义
cdrviotabdef_tab CDR 违例表定义
deltabrep 删除表到副本的映射
freqdef 基于时间的复制频率信息
rsncrowstats 跟踪 resync 作业的行计数
replevents 副本暂停/继续运行事件
cdr_pcpt PostCommit 触发器进度表
cdrddlpt PostCommit DDL 日志进度表

十二、ER:结合使用 ER 和 HDR

本节讨论以下主题:

SQLHOSTS 需求

为了结合使用 ER 和 HDR 服务器,HDR 主服务器和从服务器必须属于同一个 ER 服务器组。清单 55 给出一个结合使用 ER 和 HDR 的 SQLHOSTS 文件示例:

清单 55. 使用组语法的 SQLHOSTS 文件

                    
g_80s		group		-		-		i=80
boy		ontlitcp	sun-mach4	21340		g=g_80s
october		ontlitcp	sun-mach4	21341		g=g_80s
war		ontlitcp	sun-mach4	21342		g=g_80s
uabrs		ontlitcp	sun-mach4	21343		g=g_80s
g_90s		group		-		-		i=90
uf		ontlitcp	sun-mach5	21340		g=g_90s
jt		ontlitcp	sun-mach5	21341		g=g_90s
rh		ontlitcp	sun-mach5	21342		g=g_90s
ab		ontlitcp	sun-mach5	21343		g=g_90s
g_00s		group		-		-		i=2000
zooropa		ontlitcp	sun-mach6	21340		g=g_00s
pop		ontlitcp	sun-mach6	21341		g=g_00s
atyclb		ontlitcp	sun-mach6	21342		g=g_00s
htdaab		ontlitcp	sun-mach6	21323		g=g_00s

在这个示例中,服务器 ‘boy’、‘uf’ 和 ‘zooropa’ 都是 HDR 主服务器。从服务器是 ‘october’、‘jt’ 和 ‘pop’。

SBSPACE 需求

ER 使用的所有 sbspace 都必须启用日志记录特性。HDR 和 ER 混合环境必须同时满足这两者的最低需求。因此,所有 sbspace 在创建时都需要使用 LOGGING=ON选项。

复制 UDT/UDR/Blade 数据

如果环境使用用户定义的类型、用户定义的例程和 DataBlade 模块,那么需要执行表 15 所示的步骤:

表 15. 为 ER/HDR 设置 UDT/UDR/Blade 数据

步骤 在主服务器上 在从服务器上
1 安装用户定义的类型、用户定义的例程或 DataBlade 模块。 安装用户定义的类型、用户定义的例程或 DataBlade 模块。
2 注册用户定义的类型、用户定义的例程或 DataBlade 模块。

十三、持续复制(Continuous Replication)

本节讨论以下主题:

什么是 Continuous Replication?

Continuous Replication 对 HDR 进行扩展,允许一个从服务器与多个主服务器相连接。有两种新的从服务器类型:Remote Standalone Secondary(RSS)和 Shared Disk Secondary(SDS)。可以按照(几乎)任何组合使用 RSS、SDS 和 HDR。Continuous Replication 是由这三种形式的从服务器组成的多层可用性解决方案。

它解决什么问题?

业务连续性:HDR 适合提供备份服务器和实现负载平衡,但需付一定代价。由于从服务器与主服务器紧密相连,所以从服务器的性能有所影响,只提供有限的功能。

业务连续性的好处是增强可用性、存储备份和克服网络延迟的影响。

RSS 如何帮助维护业务连续性?

RSS 节点可以在 HDR 从服务器永久丢失时替代 HDR 从服务器。可以将 RSS 节点看作在 HDR 主服务器和从服务器节点丢失时提供灾难恢复的一种措施。

SDS 如何帮助维护业务连续性?

在存储和服务器相互分隔的环境(比如 SAN 环境)中或者共享同一存储的组合式系统(比如一组刀片服务器)中,SDS 节点可以提供更高的可用性。SDS 节点可以非常快速地实例化,因为它不需要单独的存储拷贝。因为 SDS 节点不提供存储的额外拷贝,所以需要用别的方法提供磁盘可用性,比如磁盘镜像或使用 RSS 或 HDR 节点。

十四、基础设施的变化

本节讨论以下主题:

Server Multiplexer(SMX)

SMX 是一个新的内部通信协议,用来在节点之间建立网络连接。它可以在一个 TCP 连接上支持多个逻辑连接。SMX 使用一个完全的双向式协议,这意味着它向其他节点发送数据包,而不等待确认(ACK)返回。所以要在一定时间段之后确保主节点接收到确认。接收线程会阻塞并等待对等节点发送 ACK。SMX 连接支持加密,可以自动启用,不需要配置(加密特性除外)。

为了支持 SMX,每个节点有两个新线程:

  • smxrcv [server] —— 从指定的服务器接收线程
  • smxsnd [server] —— 向指定的服务器发送线程
回页首

索引页面日志(IPL)

为了满足业务连续性目标,将索引复制到从服务器的方式有一个变化。当前,HDR 在创建索引时将索引页面传输到从服务器。这样做的问题是从服务器必须可用,而且在创建索引之后才能(在主服务器上)使用索引。另外,在添加 RSS 节点时,不希望要求 RSS 节点和 HDR 从服务器同时在线。

解决方案是,在最初创建索引时,允许将索引页面复制到逻辑日志中。索引的日志记录划分为多个事务,这些事务不属于用户事务。在启用索引页面日志时,主服务器使用逻辑日志将索引发送到从服务器,而不是传输当前的索引。

启用索引页面日志

有两种启用索引页面日志的方法。可以将 ONCONFIG参数 LOG_INDEX_BUILDS手工编辑为 1,或者使用 onmode -wf编辑 onconfig 文件。例如:

onmode -wf LOG_INDEX_BUILDS 1

如果启用了任何 RSS 节点,那么不能关闭 IPL。

数据库更改

表 16 描述那些为支持 RSS 和 SDS 节点在 sysmaster 中添加的表:

表 16. 新的 sysmaster 表

表名 描述
syssmx 与 onstat -g smx 相同的信息
syssmxses 与 onstat -g smx [ses] 相同的信息
syssrcrss 与 onstat -g rss(主服务器)相同
sysrsslog 与 onstat -g rss log 相同
systrgrss 与 onstat -g rss(从服务器)相同
sysha_lagtime HA 服务器延迟信息
sysha_nodes 一个显示已定义的 HDR、RSS 或 SDS 节点的视图
sysha_type HA 服务器类型
sysha_workload HA 服务器工作负载信息

另外,在定义 RSS 或 SDS 节点时,会创建一个名为 sysha 的新数据库。

新的 onconfig 参数

有两个支持 SMX 和 IPL 的新的 ONCONFIG参数:

  1. LOG_INDEX_BUILDS—— 在执行 create index语句期间开/关索引页面日志。在使用 RSS 节点时,需要在主节点上设置这个参数。
  2. ENCRYPT_SMX—— 对主节点和 RSS/SDS 节点之间的连接进行加密。如果设置为 1,那么只在连接的服务器也支持加密的情况下,对 SMX 事务进行加密。如果设置为 2,那么只允许连接到加密的服务器。将 ENCRYPT_SMX设置为 0 就禁用服务器之间的加密。

十五、RSS:简介

本节讨论以下主题:

与 HDR 的相似性

Remote Standalone Secondary(RSS)系统节点在以下几个方面与 HDR 从服务器非常相似:

  • 它们都维护数据库的一个磁盘拷贝
  • 它们都可以用于处理报告
  • 它们都是通过执行数据库备份/恢复创建的

与 HDR 的差异

但是,有一些关键的差异:

  • RSS 使用 SMX 连接,可以在比较慢的线路上实现更好的吞吐量
  • 不支持 SYNC 模式,甚至对于检查点也是如此
  • 不能提升为主节点,但是可以提升为 HDR 从节点(用于灾难恢复而不是 HA)
  • 可以有任意数量的 RSS 节点
  • 在主节点上需要启用索引页面日志
回页首

RSS 的工作方式

当前,在 IDS 将日志缓冲区保存到磁盘时,还将它复制到 HDR 日志缓冲区和 ER 缓冲区缓存(如果使用 ER 的话)。现在,主节点检查是否启用了 RSS 节点,并将相同的页面复制到一个日志缓存,这个缓存用来将页面发送给远程节点。如果发送线程当前正在睡眠,就唤醒 RSS_Send 线程,这个线程将日志页面传输到远程服务器。

十六、RSS:配置

本节讨论以下主题:

需求

RSS 服务器维护物理数据库的一个完整拷贝。因此,它在以下方面必须与主服务器相同:

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

RSS 还有其他一些需求:

  • 所有 HDR 需求都适用于 RSS 节点
  • 确保 RSS 节点上的块/磁盘布局与源服务器相似(相对路径或精确路径)
  • 需要在源节点上启用索引页面日志
  • 在源服务器上识别 RSS 节点(为了安全性)

初次启动 RSS 节点

按照表 17 中的步骤启动 RSS 节点:

表 17. 初次启动 RSS 节点

步骤 在主服务器上 RSS 节点上
1 安装 UDR、UDT 和 DataBlade 模块。注册 UDR、UDT 和 DataBlade 模块。 安装 UDR、UDT 和 DataBlade 模块。
2 onmode -wf LOG_INDEX_BUILDS=1
3 ontape -s -L 0,或 onbar -b -L 0
4 onmode -d add RSS rss_servername [password]
5 ontape -p,或 ontape -p -e(在提示备份日志时,回答no),或 onbar -r -p,或 onbar -r -p -e
6 onmode -d RSS primary_servername password
7 ontape -l,或 onbar -r -l

下面详细说明前面的六个步骤:

  1. 在两个服务器上 安装 用户定义的类型、用户定义的例程和 DataBlade 模块,然后只在 ServerA 上注册它们。
  2. 在主服务器上 启用 索引页面日志:
    onmode -wf LOG_INDEX_BUILDS=1
  3. 创建 ServerA 的0级备份:
    ontape -s -L 0

    onbar -b -L 0
  4. 在主服务器上 记录 RSS 节点的标识。密码是可选的,而且只能在第一次执行这个命令时指定。在已经连接 RSS 节点之后,尝试修改密码就会导致错误。
    onmode -d add RSS rss_servername [password]
  5. 用第 4 步中创建的0级备份在 ServerB 上 执行 物理恢复。不执行逻辑恢复。
    ontape -p,或 ontape -p -e

    (在提示备份日志时,回答 no。)或

    onbar -r -p,或 onbar -r -p -e

    如果在主服务器上备份了逻辑日志文件并删除它们,那么这些文件中的记录就不再保留在主服务器上了。RSS 节点会提示从磁带恢复这些文件。在这种情况下,必须执行下一步。否则,跳到最后一步。

  6. 如果 过去写到主服务器的逻辑日志记录不再保留在主服务器磁盘上,那么 RSS 节点会提示从磁带备份恢复这些文件。在恢复磁带上的所有逻辑日志文件之后,使用主服务器磁盘上的逻辑日志文件完成逻辑恢复。
    ontape -l

    onbar -r -l
  7. 使用 以下命令将 ServerB 的类型设置为 RSS 节点,并指出相关联的主数据库服务器。密码是可选的,而且只能在第一次执行这个命令时指定。
    onmode -d add RSS primary_servername {password]

    对主服务器执行这个命令之后,检查消息日志文件。它应该包含以下消息:

    14:47:16 RSS ServerB added … 15:02:23 RSS Server ServerB – state is now connected

    另外,RSS 节点会向消息日志输出以下消息:
    清单 56. RSS 节点的在线日志中的消息

                                
    15:02:23  DR: Reservation of the last logical log for log backup turned off
    15:02:23  DR: new type = RSS
    15:02:23  RSS Server ServerA - state is now connected
    15:02:23  Logical Recovery Started.
    15:02:23  10 recovery worker threads will be started.
    15:02:51  Start Logical Recovery - Start Log 3, End Log ?
    15:02:51  Starting Log Position - 3 0x1167250
    15:02:51  Clearing the physical and logical logs has started
    15:03:06  Cleared 967 MB of the physical and logical logs in 15 seconds
    15:03:07  DR: RSS secondary server operational
    

十七、RSS:管理

本节讨论以下主题:

1. 故障转移规则

在 RSS 环境中应用以下规则:

  • 从 11.11.xC1 版本开始,RSS 节点不能与主服务器进行交换
  • DRAUTO不适用于 RSS
  • RSS 节点可以转换为 HDR 从服务器
  • HDR 从服务器可以转换为 RSS 节点
  • RSS 节点可以转换为标准节点

2. 提升为独立服务器

在 RSS 节点上执行以下命令,就可以将 RSS 节点转换为标准服务器:

onmode -d standard

在将 RSS 服务器提升为独立服务器之后,它就不能再转换回 RSS 节点。只能执行前面描述的步骤,重新创建一个新的 RSS 节点。

3. 转换为 HDR 从服务器

可以使用以下命令将 RSS 节点转换为 HDR 从服务器:

onmode -d secondary <primary server name>

注意,如果日志的来源是一个标准服务器,那么这个标准服务器将转换为 HDR 主服务器。

4. 将 HDR 从服务器转换为 RSS 节点

将 HDR 从服务器转换为 RSS 节点的步骤如下:

  1. 向 HDR 主服务器注册 RSS 节点名:
    onmode -d add RSS rss_servername [optional password]
  2. 在 HDR 从服务器上,运行以下命令将它转换为 RSS 节点:
    onmode -d RSS primary_servername [optional password]

5. 删除 RSS 节点

可以执行以下命令从环境中删除 RSS 节点:

onmode -d delete RSS rss_servername

十八、RSS:监视

本节讨论以下主题:

onstat -g rss

onstat有几个选项,而且输出取决于运行 onstat的位置。清单 57 演示了如何使用显示简要 RSS 信息的几个选项:

清单 57. onstat -g rss 的输出(主服务器)

                    
$ onstat -g rss
IBM Informix Dynamic Server Version 11.10.FC1     -- On-Line (Prim) -- Up 1 days 
02:28:52 -- 196608 Kbytes
Local server type: HDR Primary
Index page logging status: Enabled
Index page logging was enabled at: 2007/05/15 08:50:18
Number of RSS servers: 2
RSS Server information:
RSS Srv       RSS Srv       Connection        Next LPG to send
name          status        status            (log id,page)
war                Active       Connected               4,3
uabrs              Active       Connected               4,3

注意 “Next LPG to send”。这是惟一逻辑日志 id 和这个惟一日志中的逻辑日志页面。

清单 58 显示一个特定 RSS 节点的相关信息:

清单 58. onstat -g rss <rss_servername> 的输出(主服务器)

                    
$ onstat -g rss war
IBM Informix Dynamic Server Version 11.10.FC1     -- On-Line (Prim) -- Up 1 days 
06:49:10 -- 196608 Kbytes
RSS Server control block: 0xf202f68
RSS server name: war
RSS server status: Active
RSS connection status: Connected
Log transmission status: Active
Next log page to send(log id,page): 4,48
Sequence number of next buffer to send: 1279
Sequence number of last buffer acked: 1265
Log Pages Snooped:
RSS Srv         From      From      Tossed
name            Cache     Disk     (LBC full)
war                3448       1053      0 

清单 59 显示详细的 RSS 信息:

清单 59. onstat -g rss verbose 的输出(主服务器)

                    
$ onstat -g rss verbose
IBM Informix Dynamic Server Version 11.10.FC1     -- On-Line (Prim) -- Up 1 days 
06:51:01 -- 196608 Kbytes
Local server type: HDR Primary
Index page logging status: Enabled
Index page logging was enabled at: 2007/05/15 08:50:18
Number of RSS servers: 2
RSS Server information:
RSS Server control block: 0xf202f68
RSS server name: war
RSS server status: Active
RSS connection status: Connected
Log transmission status: Active
Next log page to send(log id,page): 4,48
Sequence number of next buffer to send: 1279
Sequence number of last buffer acked: 1265
RSS Server control block: 0xf202e20
RSS server name: uabrs
RSS server status: Active
RSS connection status: Connected
Log transmission status: Active
Next log page to send(log id,page): 4,48
Sequence number of next buffer to send: 313
Sequence number of last buffer acked: 299

清单 60 显示日志信息:

清单 60. onstat -g rss log 的输出(主服务器)

                    
$ onstat -g rss log    
IBM Informix Dynamic Server Version 11.10.FC1     -- On-Line (Prim) -- Up 1 days 
06:52:24 -- 196608 Kbytes
Log Pages Snooped:
RSS Srv         From      From      Tossed
name            Cache     Disk     (LBC full)
war                3448       1053      0          
uabrs              47         4454      0

清单 61 中的选项显示在 RSS 节点上看到的信息:

清单 61. onstat -g rss 的输出(从服务器)

                    
$ onstat -g rss
IBM Informix Dynamic Server Version 11.10.FC1     -- Read-Only (RSS) -- Up 1 days 
05:46:19 -- 196608 Kbytes
Local server type: RSS
Server Status : Active
Source server name: boy
Connection status: Connected
Last log page received(log id,page): 4,47

onstat -g smx

清单 62 演示了如何利用 onstat -g smx选项显示 SMX 连接统计信息:

清单 62. onstat -g smx 的输出

                    
$ onstat -g smx
IBM Informix Dynamic Server Version 11.10.FC1     -- On-Line (Prim) -- Up 18 days 
09:22:51 -- 196608 Kbytes
SMX connection statistics: 
SMX control block: 0xefa9028
  Peer server name: war
  SMX connection address: 0xefabcc8
  Encryption status: Disabled
  Total bytes sent: 49830400
  Total bytes received: 23055144
  Total buffers sent: 211527
  Total buffers received: 795204
  Total write calls: 205405
  Total read calls: 795204
  Total retries for write call: 0
  Peer server name: uabrs
  SMX connection address: 0xf73c050
  Encryption status: Disabled
  Total bytes sent: 49829140
  Total bytes received: 23053252
  Total buffers sent: 211508
  Total buffers received: 795138
  Total write calls: 205382
  Total read calls: 795138
  Total retries for write call: 0

清单 63 中的选项显示 SMX 会话统计信息:

清单 63. onstat -g smx ses 的输出

                    
$ onstat -g smx ses
IBM Informix Dynamic Server Version 11.10.FC1     -- On-Line (Prim) -- Up 18 days 
09:25:20 -- 196608 Kbytes
SMX session statistics: 
SMX control block: 0xefa9028
Peer        SMX session        client        reads        writes
name        address            type
war      f968050         RSS Send       397634       211541
uabrs      f73c688         RSS Send       397601       211522

onstat -g ipl

清单 64 利用 onstat -g ipl选项显示索引页面日志记录的状态信息:

清单 64. onstat -g ipl 的输出

                    
$ onstat -g ipl
IBM Informix Dynamic Server Version 11.10.FC1     -- On-Line (Prim) -- Up 18 days 
09:38:43 -- 196608 Kbytes
Index page logging status: Enabled
Index page logging was enabled at: 2007/05/15 08:50:18

十九、RSS:练习

练习 1

使用相对路径设置一个 HDR 对。在这个系统中添加一个 RSS 节点,并将这个 RSS 节点改为新的从服务器。

练习 2

在练习 1 建立的系统中,将原来的从服务器(目前离线)转换为 RSS 节点。

二十、RSS:解决方案

练习 1

使用相对路径设置一个 HDR 对。在这个系统中添加一个 RSS 节点,并将这个 RSS 节点改为新的从服务器。

下面是应该执行的步骤:

  1. 设置 HDR 对
  2. 主服务器:onmode -d add RSS <RSS Server Name>
  3. 主服务器:ontape -s -L 0
  4. RSS 节点:ontape -p
  5. RSS 节点:onmode -d RSS <primary node>
  6. 让现有的 HDR 从服务器离线:onmode -ky
  7. RSS 节点:onmode -d secondary <primary node>

练习 2

在练习 1 建立的系统中,将原来的从服务器(目前离线)转换为 RSS 节点。

下面是应该执行的步骤:

  1. 主服务器:onmode -d add RSS <old secondary node>
  2. 原来的从服务器:oninit
  3. 原来的从服务器:onmode -d RSS <primary>

二十一、SDS:简介

本节讨论以下与 Shared Disk Secondary(SDS)相关的主题:

与 HDR 的相似性

SDS 节点在以下几个方面与 HDR 从服务器非常相似:

  • 它们都是只读服务器
  • 它们都需要有自己的临时空间来处理报告
  • 它们都可以提升为主服务器

与 HDR 的差异

但是,有一些关键的差异:

  • SDS 使用 SMX 连接,可以在比较慢的线路上实现更好的吞吐量
  • 可以有任意数量的 SDS 节点

SDS 的工作方式

Shared Disk Secondary 服务器基本上就是在共享磁盘子系统上建立的 HDR。主服务器在刷新日志时传输当前的 LSN(日志序号)。SDS 节点从主服务器接收 LSN,并从共享磁盘读取日志。然后,SDS 节点将日志的修改应用于它的缓冲区缓存。SDS 节点定期向主服务器发回接收 LSN 的确认消息。

SDS 节点并不写共享磁盘块,也不将数据刷入共享磁盘块。即使在检查点期间也是如此。如果 SDS 节点需要从缓冲区缓存中删除一个页面,那么将它放在一个临时页面文件中,直到下一个检查点为止。

二十二、SDS:配置

本节讨论以下主题:

需求

除了磁盘之外(磁盘与主服务器共享),SDS 节点的硬件和软件需求与 HDR 从服务器相同。

SDS 节点不能与主服务器共享临时空间。因此,必须为每个 SDS 节点指定临时空间(可以定义多个 DBSpace/块)。临时空间是在启动 SDS 节点时创建的。动态创建的 DBSpace/块对于 SDS 节点是本地的。这些 DBSpace/块使用最高的编号,以避免与主服务器上的编号冲突。主服务器和其他 SDS 节点并不知道存在这些本地的临时 DBSpace。

在启动 SDS 节点之前,应该设置下一节描述的 Onconfig 参数。

新的 onconfig 参数

表 18. 用于支持 SDS 的新的 onconfig 参数

参数 描述
SDS_ENABLE 设置为 1 启用 SDS;0 表示禁用 SDS
SDS_TIMEOUT 指定一个整数,表示主服务器在尝试删除一个 SDS 节点之前等待从节点确认日志位置的秒数
SDS_TEMPDBS 使用以下格式 <name>,<path>,<pagesize>,<offset>,<size>。因为 SDS 节点无法共享临时空间,所以必须为每个从 SDS 节点指定临时 dbspace。这个空间是在启动 SDS 节点时创建的
SDS_PAGING 指定两个文件,SDS 节点将在其中维护它刷新的页面

初次启动 SDS 节点

与启动 HDR、ER 或 RSS 相比,启动 Shared Disk Secondary 节点的过程很简单。

表 19. 初次启动 SDS 节点

步骤 在主服务器上 SDS 节点上
1 设置共享磁盘环境
2 在主服务器上将 SDS_ENABLE 设置为 1
3 运行 onmode -d set SDS primary <alias>
4 配置 SDS_ENABLE、SDS_PAGING 和 SDS_TEMPDBS
5 在 SDS 节点上,映射以下参数来匹配主服务器:ROOTNAME、ROOTPATH、ROOTOFFSET、ROOTSIZE、PHYSDBS、PHYSFILE、LOGFILES、LOGSIZE。建议映射所有其他配置参数来匹配主服务器的参数,但是 DBSERVERALIASES、DBSERVERNAME 和 SERVERNUM 除外
6 用 oninit 命令启动 SDS 节点

二十三、SDS:管理

本节讨论以下主题:

故障转移

如果主服务器发生故障,那么应该按以下次序执行故障转移:

  1. 转移到 SDS 从服务器
  2. 转移到 HDR 从服务器
  3. 转移到 RSS 从服务器

应该注意,故障转移不是 “自动的”。根据节点类型的不同,故障转移步骤可能不一样。当主服务器的角色改变时,其他节点会随着变化。

提升、禁用和删除

下面描述 SDS 节点的故障转移过程。

提升

在 SDS 节点上运行以下命令,就可以将 SDS 节点提升为 HDR 主服务器:

onmode -d SDS primary

注意:SDS 节点不能转换为标准服务器。

禁用

在主服务器上运行以下命令来禁用主 SDS 服务器的设置:

onmode -d clear SDS primary <alias>

这个命令将主服务器转换为标准服务器。

删除

要想删除 SDS 节点,只需用 onmode -ky命令停止 SDS 节点,然后禁用 SDS 主节点。注意:如果打算再次使用同一个实例,那么要修改 ROOTPATH 的值,以避免破坏主实例。

onmode -d make primary

添加了 RSS 和 SDS 节点之后,可以用 make primary命令轻松地将一个服务器转换为环境中的主服务器。表 20 描述了在运行 make primary时每个服务器类型受到的影响:

表 20. onmode -d make primary 命令的结果

新主服务器的类型 其他服务器的类型 受到的影响
SDS 从服务器 SDS 节点 连接到新的主服务器并继续运行
RSS 节点 连接到新的主服务器并继续运行
HDR 从服务器 连接到新的主服务器并继续运行
原来的 HDR 主服务器 关闭
HDR 从服务器 SDS 节点 关闭
RSS 节点 关闭
HDR 从服务器 取决于用户操作
RSS 节点 SDS 节点 关闭
RSS 节点 关闭
HDR 从服务器 关闭

二十四、SDS:监视

可以使用 onstat或系统监视接口(SMI)表查看 SDS 服务器统计信息。本节讨论以下主题:

onstat 选项

可以使用 onstat -g sds命令查看 SDS 服务器统计信息。onstat的输出取决于运行它的位置(主服务器或从服务器)以及使用的选项。

onstat -g sds(主服务器)

在主服务器上运行这个命令,显示 SDS 环境的状态。

清单 65. onstat -g sds 的输出(主服务器)

                    
$ onstat -g sds
IBM Informix Dynamic Server Version 11.10.FC1 -- On-Line (Prim) -- Up 01:00:55
 -- 39936 Kbytes
Local server type: HDR Primary
Number of SDS servers:1
SDS server information
SDS srv      SDS srv      Connection        Last LPG sent
name         status       status            (log id,page)
sds_informix       Active    Connected           19,516

onstat -g sds <node>(主服务器)

在主服务器上运行这个命令,显示特定 SDS 节点的详细信息。

清单 66. onstat -g sds <node> 的输出(主服务器)

                    
$ onstat -g sds sds_informix
IBM Informix Dynamic Server Version 11.10.FB7TL -- On-Line (Prim) -- Up 01:05:15
 -- 39936 Kbytes
SDS server control block: 0xc15bba0
server name: sds_informix
server type: SDS
server status: Active
connection status: Connected
Last log page sent(log id,page):19,516
Last log page flushed(log id,page):19,516
Last LSN acked (log id,pos):19,2113560
Sequence number of next buffer to send: 229
Sequence number of last buffer acked: 0
Time of lask ack:2007/06/28 09:17:05
Total LSNs posted:0
Total LSNs sent:0
Total page flushes posted:0
Total page flushes sent:0

onstat -g sds verbose(主服务器)

在主服务器上运行这个命令,显示与这个主服务器相连的每个 SDS 节点的详细信息。输出与分别运行 onstat -g sds <node>相同。

onstat -g sds(从服务器)

在从服务器上运行这个命令,显示本地 SDS 节点的状态。

清单 67. onstat -g sds 的输出(从服务器)

                    
$ onstat -g sds
IBM Informix Dynamic Server Version 11.10.FB7TL -- Read-Only (SDS) -- Up 
00:25:10 -- 47104 Kbytes
Local server type: SDS
Server Status : Active
Source server name: pri_informix
Connection status: Connected
Last log page received(log id,page): 19,516

onstat -g sds verbose(从服务器)

在从服务器上运行这个命令,显示本地 SDS 节点的详细信息。

清单 68. onstat -g sds verbose 的输出(从服务器)

                    
$ onstat -g sds verbose
IBM Informix Dynamic Server Version 11.10.FB7TL -- Read-Only (SDS) -- Up 
00:29:54 -- 47104 Kbytes
SDS server control block: 0xb242e20
Local server type: SDS
Server Status : Active
Source server name: pri_informix
Connection status: Connected
Last log page received(log id,page): 19,516
Next log page to read(log id,page):19,517
Last LSN acked (log id,pos):19,2113560
Sequence number of last buffer received: 0
Sequence number of last buffer acked: 0
Current paging file:/usr2/informix/class/sds/paging2
Current paging file size:2048
Old paging file:/usr2/informix/class/sds/paging1
Old paging file size:10240

sysmaster 表

sysmaster 数据库中的两个表(syssrcsds 和 systrgsds)记录每个 SDS 节点的相关信息。syssrcsds 表包含的信息与在主服务器上运行 onstat -g sds的输出相同。systrgsds 表包含的信息与在从服务器上运行 onstat -g sds的输出相同。下面是这两个表的输出:

清单 69. sysmaster:syssrcsds 的输出

                    
> select * from syssrcsds;
address             202750880
server_name         sds_informix
server_status       Active
connection_status   Connected
last_sent_log_uniq  19
last_sent_logpage   516
last_flushed_log_+  19
last_flushed_logp+  516
last_acked_lsn_un+  19
last_acked_lsn_pos  2113560
seq_tosend          451
last_seq_acked      0
timeof_lastack      1183040225
totallsn_posted     0
totallsn_sent       0
totalpageflush_po+  0
totalpageflush_se+  0
1 row(s) retrieved.

清单 70. sysmaster:systrgsds 的输出

                    
> select * from systrgsds;
address             186920480
source_server       pri_informix
connection_status   Connected
last_received_log+  19
last_received_log+  521
next_lpgtoread_lo+  19
next_lpgtoread_lo+  522
last_acked_lsn_un+  19
last_acked_lsn_pos  2134040
last_seq_received   0
last_seq_acked      0
cur_pagingfile      /usr2/informix/class/sds/paging1
cur_pagingfile_si+  12288
old_pagingfile      /usr2/informix/class/sds/paging2
old_pagingfile_si+  6144
1 row(s) retrieved.

消息日志输出

根据 SDS 主节点和从节点的活动,在在线日志中可以看到以下消息。

清单 71. onstat -g set SDS primary <primary node> 在主服务器上产生的消息日志输出

08:37:25 SDS Source Node Alias Changed from (<null>) to (pri_informix)

清单 72. 连接 SDS 从服务器在主服务器上产生的消息日志输出

08:43:36 SDS Server sds_informix – state is now connected

清单 73. 关闭 SDS 从服务器在主服务器上产生的消息日志输出

16:29:15 SDS Server sds_informix – state is now disconnected

清单 74. 启动 SDS 从服务器在从服务器上产生的消息日志输出(注意:这里修改了一些输出以满足每行不超过 90 个字符的限制)

                    
16:29:05  DR: DRAUTO is 0 (Off)
...
16:29:05  Servername:sds_informix
...
16:29:06  Setting checkpoint 21:3018 intvl:52
16:29:06  SDS Server pri_informix - state is now connected
...
16:29:06  IBM Informix Dynamic Server Initialized -- Shared Memory Initialized.
16:29:06  Initializing SDS Temp dbspace sds_temp1
16:29:06  Requesting logs from 21:3
...
16:29:06  Servername:sds_informix
...	
16:29:06  Space 'sds_temp1' added.
16:29:06  Onconfig parameter MSGPATH modified from 
            /usr2/informix/class/pri/online.log.informix to 
            /usr2/informix/class/sds/online.log.informix.
16:29:06  Onconfig parameter CONSOLE modified from 
            /usr2/informix/class/pri/online.log.informix to 
            /usr2/informix/class/sds/online.log.informix.
16:29:06  Onconfig parameter DBSERVERNAME modified from pri_informix to 
            sds_informix.
16:29:06  Onconfig parameter SERVERNUM modified from 201 to 204.
16:29:06  Onconfig parameter DUMPDIR modified from 
            /usr2/informix/class/pri to 
            /usr2/informix/class/sds.
16:29:06  Onconfig parameter DBSPACETEMP modified from <blank> to sds_temp1.
...
16:29:06  Recovery Mode
16:29:06  Logical Recovery Started.
16:29:06  10 recovery worker threads will be started.
...
16:29:06  Start Logical Recovery - Start Log 21, End Log ?
16:29:06  Starting Log Position - 21 0x3018
16:29:06  DR: SDS secondary server operational
16:29:06  Cleaning up to 51

二十五、结束语

在学习完本教程之后,您应该能够:

  • 理解 IDS 11 提供的各种复制机制
  • 设置 ER、HDR、RSS 和 SDS 环境的需求
  • 理解复制术语
  • 配置和管理复制环境

请考虑阅读 HDR、RSS、SDS 和 ER 的相关文档,了解本教程没有讨论的问题。

英文出处:System Administration Certification exam 918 for IBM Informix Dynamic Server 11 prep, Part 7: Informix Dynamic Server replication

发表回复