内容


Informix MACH 11 高可用性特性中针对次要服务器的新增特性

降低主要服务器上的负载并从问题中快速恢复

Comments
免费下载:IBM® Informix® 11.7 试用版(包括 Ultimate Edition、Developer Edition 和 Innovator-C Edition)
下载更多的 IBM 软件试用版,并加入 IBM 软件下载与技术交流群组,参与在线交流。

概述

从 V11 开始,Informix 包含了一组高可用性与群集功能,这些功能也称为 MACH 11。这些功能可以确保无论出现什么问题,数据都能保持可用性。在 V11.50.xC6 中,提供了一些针对次要服务器的增强,它们使您能够降低主要服务器的负载,并帮助您从问题中更快地恢复。本文旨在为您提供必要的信息,以便您在自己的环境中实现这些新功能。

在 Informix 群集环境中停止或暂停复制

从 Informix V11.50.xc6 开始,您可以使用延迟应用 功能在远程独立次要 (RS) 节点上暂停或停止逻辑日志应用。通过在次要节点上快速暂停或停止逻辑日志,可以帮助 DBA 从问题中快速恢复。延迟应用功能既快速又方便使用,它允许 DBA 在出现损坏或问题删除之前从次要节点中提取数据。

启用与禁用延迟应用功能

通过设置配置文件 onconfig 中的配置参数 DELAY_APPLY,您可以暂停从主要服务器流向次要服务器的逻辑日志。您可以手动编辑配置文件,或使用以下命令动态地修改参数的值:

  • onmode -wf LOG_STAGING_DIR = [Valid_Dir_Path:用于更新 ONCONFIG 文件中指定配置参数的值
  • onmode -wm DELAY_APPLY = Dir_Path:用于动态设置内存中指定的配置参数的值

您可以指定一个时间延迟(可以为天、小时、分和秒为单位),如下面的 DELAY_APPLY 参数所示:

  • s/S: 秒
  • m/M: 分
  • h/H: 小时
  • d/D: 天

下面的例子说明了如何在远处备用次要服务器上延迟应用日志文件。

要延迟 4 小时,可以使用以下命令:

  • onmode -wf DELAY_APPLY=4H

要延迟 1 天,可以使用以下命令:

  • onmode -wf DELAY_APPLY=1D

要延迟 30 分钟,可以使用以下命令:

  • onmode -wf DELAY_APPLY=30M

要延迟 15 秒,可以使用以下命令:

  • onmode -wf DELAY_APPLY=15S

要关闭 DELAY_APPLY,则需要禁用应用于 RS 次要服务器上的逻辑日志文件延迟,如下面的 onmode 命令所示:onmode -wfDELAY_APPLY=0

在设置参数 DELAY_APPLY 之前,则必须在配置文件中设置LOG_STAGING_DIR 参数。此参数表示次要节点上保存来自主要服务器的日志的目录。

您可以手动编辑配置文件,也可以使用如下命令动态地修改参数的值:

  • onmode -wf LOG_STAGING_DIR = [Valid_Dir_Path]:用于更新 ONCONFIG 文件中指定配置参数的值
  • onmode -wm LOG_STAGING_DIR = [Valid_Dir_Path]:用于动态设置内存中指定配置参数的值

在设置此参数之前,确保已经使用以下权限创建了该目录:

  • Owner 与 Group 应该是用户 “informix”
  • 禁止拥有公共的读、写或执行权限(即 0770)

配置延迟应用的步骤

以下步骤描述了如何配置延迟,并说明了它的工作原理。

1. 使用正确权限创建一个日志暂存目录

下面的例子显示,目录 logs_staged_dir 创建于 /work/harsha 下,而配置参数 LOG_STAGING_DIR 被设置为有效路径,即 /work/harsha/logs_staged_dir。

清单 1. logs_staged_dir 的目录清单
ls -ld /work/harsha/logs_staged_dir
drwxrwx---  2 informix informix   512 Jun 1 01:52 /work/harsha/logs_staged_dir/

onmode -wf LOG_STAGING_DIR=/work/harsha/logs_staged_dir

清单 2 显示了在 RS 次要服务器上设置LOG_STAGING_DIR 时的 RS 次要服务器的在线日志消息。

清单 2. 远程次要服务器的在线日志消息
RS 次要服务器在线日志:
----------------------------------------------------------------------------------
01:47:57  DR: RSS secondary server operational
01:48:11  Checkpoint Completed:  duration was 0 seconds.
01:48:11  Tue Jun  1 - loguniq 4, logpos 0x49e018, timestamp: 0x27bf0 Interval: 21

01:48:11  Maximum server connections 0 
01:48:11  Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns blocked 0,
 Plog used 143, Llog used 0

01:48:12  Logical Log 4 Complete, timestamp: 0x2802b.
01:48:18  Checkpoint Completed:  duration was 1 seconds.
01:48:18  Tue Jun  1 - loguniq 5, logpos 0x10018, timestamp: 0x28091 Interval: 22

01:48:18  Maximum server connections 0 
01:48:18  Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns blocked 0,
 Plog used 49, Llog used 0

01:54:06  Value of LOG_STAGING_DIR has been changed to /work/harsha/logs_staged_dir.

通过查看清单 3 中显示的逻辑日志,可以看到日志位于同一位置上。这意味着主要与 RS 次要服务器上的数据是同步的。

清单 3. 主要与 RS 次要服务器上的逻辑日志
主要服务器上的逻辑日志:

Logical Logging
Buffer bufused  bufsize  numrecs    numpages   numwrits   recs/pages pages/io
  L-1  0        32       209379     17044      4683       12.3       3.6     
        Subsystem    numrecs    Log Space used
        OLDRSAM      209236     28540032      
        SBLOB        20         1008          
        HA           123        5412          

address     number   flags    uniqid   begin       size     used    %used
8759bf50    1        U-B----  1        1:7763      3000     3000   100.00
8759bfb8    2        U-B----  2        1:10763     3000     3000   100.00
87582f50    3        U-B----  3        1:13763     3000     2458    81.93
87582fb8    4        U-B----  4        1:16763     3000     1476    49.20
87456b48    5        U-B----  5        1:19763     3000     3000   100.00
87456bb0    6        U-B----  6        1:22763     3000     3000   100.00
87456c18    7        U---C-L  7        1:25763     3000     1111    37.03
87456c80    8        A------  0        1:28763     3000        0     0.00


次要服务器上的逻辑日志:

Logical Logging
Buffer bufused  bufsize  numrecs    numpages   numwrits   recs/pages pages/io
  L-1  0        32       0          0          0          0.0        0.0     
        Subsystem    numrecs    Log Space used

address     number   flags    uniqid   begin       size     used    %used
87455f98    1        F------  0        1:7763      3000        0     0.00
8759bf50    2        F------  0        1:10763     3000        0     0.00
8759bfb8    3        F------  0        1:13763     3000        0     0.00
87582f50    4        U-B----  4        1:16763     3000     1476    49.20
87582fb8    5        U-B----  5        1:19763     3000     3000   100.00
87456518    6        U-B----  6        1:22763     3000     3000   100.00
87456580    7        U---C-L  7        1:25763     3000     1111    37.03
874565e8    8        A------  0        1:28763     3000        0     0.00

2. 设置 RS 次要服务器上的 DELAY_APPLY 配置参数

使用 onmode 实用工具将 DELAY_APPLY 设为 5 分钟,从而将 RS 次要服务器上的逻辑日志应用延迟 5 分钟,如下所示:

Execute: onmode -wf DELAY_APPLY=5M

当使用 onmode 实用工具设置 DELAY_APPLY 参数之后,系统会自动基于 SERVERNUM 创建子目录 ifmxlog_[server_num],用它来暂存来自主要服务器的逻辑日志。

下一个例子显示了设置 DELAY_APPLY 时的 RS 次要服务器在线日志。服务器自动在 LOG_STAGING_DIR 下创建了一个暂存区域 “ifmxlog_14”,用它来暂存逻辑日志 7。

清单 4. 设置 DELAY_APPLY 时的日志
RS 次要服务器在线日志
-----------------------------------------------------------------------------
02:12:47  Maximum server connections 1 
02:12:47  Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns blocked 0,
 Plog used 1053, Llog used 0

02:15:20  Secondary Delay or Stop Apply: 
Using the directory /work/harsha/logs_staged_dir/ifmxlog_14.
02:15:20  A Request to reset the log position to 7:0 was sent 
to the primary server.
02:15:21  Value of DELAY_APPLY has been changed to 5M.
--------------------------------------------------------------------

ls -l /work/harsha/logs_staged_dir/ifmxlog_14
total 4464
-rw-rw----   1 root     informix 2273280 Jun  1 02:15 ifmxUniqueLog_7


Primary Server Online log
------------------------------------------------------------------------------
02:12:47  Maximum server connections 2 
02:12:47  Checkpoint Statistics - Avg. Txn Block Time 0.009, # Txns blocked 1,
 Plog used 1050, Llog used 1760

02:15:20  DELAY_APPLY has been set to 5M on server m64a1_c2
------------------------------------------------------------------------------

在主要服务器上执行事务

下一个例子显示了如何删除 stores_demo 数据库中的 customer 表,以演示是否会在 RS 次要服务器上立即应用以下事务。

清单 5. 设置 DELAY_APPLY 之后主要服务器上的事务
--------------------------------------------------------------------------------
>dbaccess stores_demo -

Database selected.

> begin work;

Started transaction.

> info tables;


Table name

call_type          catalog            classes            cust_calls        
customer           employee           ext_customer       items             
manufact           orders             state              stock             
tab                warehouses         

> drop table customer;

Table dropped.

> commit work;

Data committed.

> close database;

Database closed.
----------------------------------------------------------------------------------

现在使用 onlog 实用工具查看以上事务的提交时间,如下所示。

清单 6. 检查事务的提交时间
onlog -n 7
----------------------------------------------------------------------------------
addr     len  type     xid      id link    
4611f8   56   COMMIT   34       0  4611cc   06/01/2010 02:18:36
462018   44   HA       33       0  45f648   SDSCYCLE 106

当您在 5 分钟内查找 customer 表时,会发现 RS 次要节点上并未应用逻辑日志。提交的事务日志将位于 RS 次要服务器上的 LOG_STAGING_DIR 目录中。

下面的例子显示,RS 次要服务器上 stores_demo 数据库中的 customer 表仍然可用。

清单 7. 次要服务器上的 stores_demo 数据库
>dbaccess stores_demo -

Database selected.

> info tables;

Table name

call_type          catalog            classes            cust_calls        
customer           employee           ext_customer       items             
manufact           orders             state              stock             
tab                warehouses         

> 

暂存逻辑日志的目录:
/work/harsha/logs_staged_dir/ifmxlog_14> ls -l
total 4512
-rw-rw----   1 root     informix 2299904 Jun  1 02:18 ifmxUniqueLog_7

在 5 分钟的提交事务时间之后,次要节点将从暂存目录 LOG_STAGING_DIR 读取事务,然后应用它们。

清单 8. 次要服务器的在线日志
APPLY TIME = COMMIT TIME + DELAY_TIME
	     = 02:18:36	 + 5 mins
 	     = 02:23:36

现在查询 stores_demo 数据库,并在提交时间过去 5 分钟后在 RS 次要服务器上查找 customer 表。

下面的例子显示 RS 次要服务器上 stores_demo 中的 customer 表不可用,而且该事务已经被应用。

清单 9. 应用事务后次要服务器上的 Customer 表
> dbaccess stores_demo -

Database selected.

> info tables;

Table name

call_type         catalog           classes          cust_calls        
employee          ext_customer      items            manufact          
orders            state             stock            tab               
warehouses         

> select * from customer;

  206: The specified table (customer) is not in the database.

  111: ISAM error:  no record found.
Error in line 1
Near character position 22
>

远程独立次要服务器上的外部备份

这项功能允许 DBA 降低主要服务器上的负载。通常,可以用 RSS 节点的工作负载较低,而 DBA 会使用它们来执行备份。

一个好处是,使用次要服务器中的卷影拷贝 (shadow copy) 来执行外部备份不需要任何特殊硬件。您需要能够使用像 dd 和 gzip 这样的存档自定义程序来并行复制大块内容。

计划在 RS 次要服务器上进行备份时,有一些注意事项:

  • 目前,RSS 次要服务器上只支持外部备份。
  • 这项功能的作用与主要服务器的备份类似。
  • RS 次要节点上执行的外部备份不会阻塞或影响主要服务器。
  • 从次要服务器获得的备份可以恢复到群集中的任意其他服务器。
  • 不能使用在群集中另一台服务器上所做的 1 级 或 2 级备份恢复从次要服务器获得的备份。

先决条件

以下是在 RS 次要服务器上执行外部备份的必要条件:

  • 必须将 LOG_STAGING_DIR 设为 RSS 服务器中的有效值。
  • 为了启动外部存档,STOP_APPLY 不能是活动的。
  • DELAY_APPLY可以是活动的,但建议禁用它,因为您可能无法获得及时的存档检查点来完成存档。

进行外部备份的步骤

进行一次外部备份的步骤包括:

  1. 使用 onmode -c block [timeout] 阻塞 RS 次要服务器。
  2. 使用操作系统命令执行备份,比如 tar、gzip、cp 与 dd。
  3. 使用 onmode -c unblock 解除 RS 次要服务器的阻塞。

我们将在接下来的内容中详细讲述这些步骤。

外部备份的工作方式

图 1 显示了主要节点、HDR 与 RS 次要节点,并举例说明了在 RSS 上进行外部备份的步骤。

图 1. 主要节点、HDR 与 RSS
图像显示主要节点、HDR 与 RSS 次要节点的图形化表示,而且 RSS 次要节点拥有逻辑日志暂存区域
图像显示主要节点、HDR 与 RSS 次要节点的图形化表示,而且 RSS 次要节点拥有逻辑日志暂存区域

当您使用 onmode -c block 命令阻塞 RS 次要服务器时,RS 次要服务器将从主要服务器请求一个检查点。一旦将检查点传输给 RSS 节点,它会开始将来自主要服务器的日志记录暂存到 RS 次要服务器上的日志暂存区域中。RS 次要服务器继续从主要服务器接收逻辑日志,但不会应用它们。主要服务器将不会知道逻辑日志暂存在 RS 次要服务器上。一旦存档检查点在 RSS 节点中完成操作,它会停止应用任何其他的日志记录,让服务器保持正确状态,以便使用外部实用工具复制数据块。

当使用外部实用工具完成复制数据块之后,在执行 onmode -c unblock 时,RSS 服务器将开始应用暂存的逻辑日志中的日志记录。

一旦应用暂存的逻辑日志,只要从主要服务器接收到日志记录,就可以立即恢复应用日志记录。

在 RS 次要节点上执行外部备份的详细步骤

以下步骤明确说明了如何在 RS 次要服务器上执行外部备份。

1. 使用正确权限创建一个日志暂存目录

下面的例子显示了在 /work/harsha 下创建的 logs_staged_dir 目录,而且配置参数 LOG_STAGING_DIR 被设置为有效路径 /work/harsha/logs_staged_dir。

清单 10. 日志暂存目录
ls -ld /work/harsha/logs_staged_dir
drwxrwx---   2 informix informix     512 Jun  1 01:52 /work/harsha/logs_staged_dir/

onmode -wf LOG_STAGING_DIR=/work/harsha/logs_staged_dir

在 RS 次要服务器上设置 LOG_STAGING_DIR 时的 RS 次要服务器的在线日志消息。

清单 11. RS 次要服务器的在线日志
onstat -
IBM Informix Dynamic Server Version 11.50.FC6     -- Updatable (RSS) -- Up 04:14:04 --
 165576 Kbytes

06:38:53  Maximum server connections 1 
06:38:53  Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns blocked 0,
 Plog used 2, Llog used 0

06:39:54  Value of LOG_STAGING_DIR has been changed to /work/harsha/logs_staged_dir.

2. 阻塞服务器

使用 onmode 实用工具阻塞服务器:onmode -c block 60。当发出该命令时,将等待来自主要服务器的检查点请求。

清单 12. 服务器阻塞之后的主要与次要日志
主要服务器在线日志
-----------------------------------------------------------------------------------
06:40:41  A checkpoint request for an archive was received from a secondary server.
06:40:41  Checkpoint Completed:  duration was 0 seconds.
06:40:41  Fri Jun  3 - loguniq 4, logpos 0xe9018, timestamp: 0x3542e Interval: 30


RS Secondary Server Online Log
-----------------------------------------------------------------------------
06:38:53  Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns blocked 0,
 Plog used 2, Llog used 0

06:39:54  Value of LOG_STAGING_DIR has been changed to /work/harsha/log_staged_dir.
06:40:41  Secondary Delay or Stop Apply: 
Using the directory /work/harsha/log_staged_dir/ifmxlog_64.
06:40:41  A Request to reset the log position to 4:0 was sent to the primary server.
06:40:42  Staging of logical logs successfully started.
06:40:42  Checkpoint Completed:  duration was 0 seconds.
06:40:42  Fri Jun  3 - loguniq 4, logpos 0xe9018, timestamp: 0x35431 Interval: 31

06:40:42  Maximum server connections 1 
06:40:42  Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns blocked 0,
 Plog used 0, Llog used 0

06:40:43  The external backup is blocking the database server at checkpoint
 4:0xe9018.
06:40:43  Dynamic Server blocked.

 onstat -

IBM Informix Dynamic Server Version 11.50.FC7     -- Updatable (RSS) -- Up 04:16:53
 -- 165576 Kbytes
Blocked:ARCHIVE

3. 复制所有 RSS 数据块

现在正是使用操作系统命令复制所有 RSS 数据块(比如 cp、tar、gzip 等)的好时候。在执行外部备份期间,来自主要服务器的逻辑日志暂存于 RS 次要服务器上。该服务器会自动创建一个名为 ifmxlog_XX 的目录。

当 RS 次要服务器阻塞之后,来自主要服务器的逻辑日志暂存于 RS 次要服务器上。RS 次要服务器被阻塞,而逻辑日志位于如下突出显示的位置。

清单 13. 暂存的日志
主要服务器的逻辑日志
-----------------------------------------------------------------------------
Logical Logging
Buffer bufused  bufsize  numrecs    numpages   numwrits   recs/pages pages/io
  L-2  0        32       217224     17834      5488       12.2       3.2     
        Subsystem    numrecs    Log Space used
        OLDRSAM      217141     29202988      
        HA           83         3652          

address       number   flags    uniqid   begin         size     used    %used
4b7ccf50      1        U------  1        1:25263       5000     5000   100.00
4b7ccfb8      2        U------  2        1:30263       5000     5000   100.00
4b7b3f50      3        U------  3        1:35263       5000     2030    40.60
4b7b3fb8      4        U-----L  4        1:40263       5000     5000   100.00
4b687b48      5        U---C--  5        1:45263       5000      804    16.08
4b687bb0      6        A------  0        1:50263       5000        0     0.00
 6 active, 6 total


RS 次要服务器的逻辑日志
-----------------------------------------------------------------------------
Logical Logging
Buffer bufused  bufsize  numrecs    numpages   numwrits   recs/pages pages/io
  L-1  0        32       0          0          0          0.0        0.0     
        Subsystem    numrecs    Log Space used

address       number   flags    uniqid   begin         size     used    %used
4b686f98      1        F------  0        1:25263       5000        0     0.00
4b7ccf50      2        F------  0        1:30263       5000        0     0.00
4b7ccfb8      3        U------  3        1:35263       5000     2030    40.60
4b7b3f50      4        U---C-L  4        1:40263       5000      280     5.60
4b7b3fb8      5        A------  0        1:45263       5000        0     0.00
4b687518      6        A------  0        1:50263       5000        0     0.00
 6 active, 6 total

在这里,来自主要服务器的日志 4 与日志 5 都暂存在 RS 次要服务器上。

清单 14. 显示日志 4 与日志 5 的文件清单
/work/harsha/log_staged_dir/ifmxlog_64> ls -lrt
total 11636
-rw-rw---- 1 root informix 10240000 Jun  3 06:50 ifmxUniqueLog_4
-rw-rw---- 1 root informix  1652736 Jun  3 06:51 ifmxUniqueLog_5

4. 使用 onmode 实用工具解除 RS 次要服务器的阻塞

解除服务器的阻塞时,将在应用 RS 次要服务器上来自主要服务器的已暂存逻辑日志文件之后自动删除它。

清单 15. 使用 onmode 实用工具解除应用日志的阻塞
onmode -c unblock

IBM Informix Dynamic Server Version 11.50.FC7     -- Updatable (RSS) -- Up 04::47
 -- 165576 Kbytes

Message Log File: /usr2/MAIN1110/dbspaces/demo/rss/online.log
06:56:33  Dynamic Server unblocked.
06:56:34  Checkpoint Completed:  duration was 0 seconds.
06:56:34  Fri Jun  3 - loguniq 4, logpos 0x82e018, timestamp: 0x3c940 Interval32


/usr2/MAIN1110/dbspaces/demo/rss/log_staged_dir/ifmxlog_64> ls -lrt
total 0

恢复在 RS 次要服务器上所做的外部备份

恢复在 RS 次要服务器上所做的外部备份与恢复在独立或主要服务器上所做的备份完全一样。

在 RS 次要服务器上所做的外部备份:

  • 可以恢复备份以创建一台主要服务器。
  • 可以恢复备份以创建一台 RS 次要服务器。
  • 可以恢复备份以创建一台 HDR 次要服务器。
  • 可以恢复备份以创建一台独立服务器。

示例 1:恢复在 RS 次要服务器上所做的外部备份以创建新的 RS 次要服务器

  1. 使用 UNIX® 命令(比如 cp、tar 与 unzip)将所有备份数据库复制到 ROOTPATH 位置。
  2. 使用 ontapeonbar 实用工具进行恢复。
    清单 16. 使用 ontapeonbar 进行恢复
    $ontape -p -e or onbar -r -p -e
    Physical restore complete. Logical restore required before work can continue.
    Program over.
    
    Server online Log:
    ---------------------------------------------------------------------
    IBM Informix Dynamic Server Version 11.50.FC6     -- Fast Recovery -- 
    Up 00:00:15 -- 149192 Kbytes
    04:25:36  Event notification facility epoll enabled.
    04:25:36  IBM Informix Dynamic Server Version 11.50.FC6     
    Software Serial Number AAA#B000000
    04:25:37  IBM Informix Dynamic Server Initialized -- Shared Memory Initialized.
    
    04:25:37  Started 1 B-tree scanners.
    04:25:37  B-tree scanner threshold set at 5000.
    04:25:37  B-tree scanner range scan size set to -1.
    04:25:37  B-tree scanner ALICE mode set to 6.
    04:25:37  B-tree scanner index compression level set to med.
    04:25:37  Data replication type and state information reset. To start DR, use
              the 'onmode -d' command and wait for the pair to be operational,
              before shutting down the database server
    
    04:25:37  Physical Recovery Started at Page (1:926).
    04:25:37  Physical Recovery Complete: 0 Pages Examined, 0 Pages Restored.
    04:25:37  Dataskip is now OFF for all dbspaces
    04:25:37  Restartable Restore has been ENABLED
    04:25:37  Recovery Mode
    04:25:38  External restore started.
    04:25:38  External restore  Completed.
  3. 运行 onmode 实用程序:onmode -d RSS [primary server alias]

示例 2:从在 RSS 上制作的备份创建一台 HDR 次要服务器

  1. 执行 示例 1 中的步骤 1。
  2. 运行 onmode 实用工具:onmode -d secondary [primary server alias]

重要提示: 不允许在包含不记入日志的对象(比如不记入日志的 blobspaces 与不记入日志的数据库)的 RSS 服务器上执行外部备份。如果 RSS 服务器拥有不记入日志的对象,onmode -c block 将会失败。

清单 17. 尝试阻塞记录不记入日志的数据库
onmode -c block
onmode could not block server.

07:08:48  Maximum server connections 1 
07:08:48  Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns blocked 0,
 Plog used 21, Llog used 0

07:08:48  The nonlogging database, 'data', is preventing the backup 
on the secondary server.

问题解答

在正在执行外部备份操作期间,如果主要服务器失效而日志被暂存在 RS 次要服务器上,会出现什么情况?

主要服务器故障恢复到一个新的次要节点(SDS 或 HDR)上不会影响存档,或者受存档的影响,而 RSS 节点上会制作一份外部存档。SDS 或 HDR 次要节点可以接管主要服务器,而 RS 次要服务器继续从新的主要服务器接收逻辑日志。

在 RS 次要服务器上如何恢复外部备份?

恢复在 RS 次要服务器上所做的外部备份与恢复在独立或主要服务器上所做的备份完全一样:使用 ontapeonbar 实用工具。示例:ontape -p -e or onbar -r -e。

如何避免阻塞 HDR 环境中主要服务器上的检查点

要了解如何避免阻塞检查点,则需要知道阻塞检查点的情况是如何发生的。请参考 Madison Pruet 以前撰写并发表的一篇文章 Informix replication and availability architect,了解 HDR 的工作原理和阻塞检查点出现的原因(请参阅 参考资料)。

如果我们不能有效处理次要服务器上的工作,那么次要服务器上的问题会反过来影响主要服务器(阻塞主要服务器),于是就会出现阻塞检查点的情况。为了避免阻塞检查点,我们支持在 HDR 次要节点上暂存日志。让我们了解一下如何启用日志暂存及其工作原理。

先决条件

以下先决条件对于是否在检查点期间启用逻辑日志暂存非常重要:

  • 必须将 LOG_STAGING_DIR 设置为 HDR 服务器中的一个有效值。
  • 如果 LOG_STAGING_DIR 指定的目录不存在,服务器将自动创建一个目录。

注意:在存在已暂存的逻辑日志时,不能将 HDR 次要服务器降级为 RSS 次要服务器。

日志暂存于检查点期间如何工作

下图展示了主要服务器与 HDR 次要节点,以及日志暂存在检查点期间的工作步骤。

图 2. 主要服务器与 HDR 服务器的示意图
该图显示了主要服务器与 HDR 次要服务器,它们都有逻辑日志暂存区域;该图说明了在 HDR 次要服务器上的检查点期间,日志暂存是如何工作的
该图显示了主要服务器与 HDR 次要服务器,它们都有逻辑日志暂存区域;该图说明了在 HDR 次要服务器上的检查点期间,日志暂存是如何工作的
  • 当次要服务器遇到检查点时,它将进入一种缓冲模式。处于缓冲模式下时,次要服务器会暂存来自 HDR 的任何日志页面数据,可以使用 onstat -g dri ckpt 显示日志暂存的统计数据,如下所示。
  • 主要服务器将使用暂存目录中的文件,并在实际应用或暂存将保存到主要服务器的日志数据缓存之前,应立即识别对它的接收。
  • 在次要服务器上完成检查点处理之后,次要服务器会进入排出模式 (drain mode)。在这种模式中,次要服务器从暂存文件中读取数据,并从主要服务器直接接收新数据。它将这些数据添加到日志暂存区域。
  • 次要服务器将每个日志文件中的数据保存在单独的暂存文件中。只要在使用排出模式期间读取了所有数据,就会立即删除这些文件。
  • 一旦暂存区域为空,次要服务器就会恢复常规操作。
  • 次要服务器处于排出模式或缓冲模式下时,可能会遇到另一条检查点日志记录,您会看到挂起的检查点在增加。如果服务器处于排出模式下时遇到另一条日志检查点记录,那么它会回到缓冲模式。这意味着状态变化可能为缓冲-排出、排出-缓冲或排出-常规。
清单 18. 缓冲
During normal mode:
----------------------
onstat -g dri ckpt

Data Replication at 0x4c057028: 
Type State Paired server Last DR CKPT (id/pg) Supports Proxy Writes 
HDR Secondary on mysore 16 / 694 N 

DRINTERVAL 30 
DRTIMEOUT 30 
DRAUTO 0 
DRLOSTFOUND /vobs/tristarp/sqldist/etc/dr.lostfound 
DRIDXAUTO 0 
ENCRYPT_HDR 0 

DR Checkpoint processing:
Save State N
Pages Saved 0
Save Area none
Received log id, page 17,68
Saved log id, page 0,0
Drain log id, page 0,0
Processed log id, page 17,68
Pending checkpoints 0

[pinch-cdrkojinnbc] (cdrstat) 1025 % 


During buffering and draining mode:
---------------------------------------
onstat -g dri ckpt 

Type State Paired server Last DR CKPT (id/pg) Supports Proxy Writes 
HDR Secondary on mysore 19 / 318 N 

DRINTERVAL 30 
DRTIMEOUT 30 
DRAUTO 0 
DRLOSTFOUND /vobs/tristarp/sqldist/etc/dr.lostfound 
DRIDXAUTO 0 
ENCRYPT_HDR 0 

DR Checkpoint processing:
Save State D
Pages Saved 25147
Save Area /notnfs/pinch/hdrservers/dbs/amsterdam_sec_drckptlogs/ifmxhdrstage_72
Received log id, page 53,29
Saved log id, page 53,29
Drain log id, page 19,383
Processed log id, page 19,382
Pending checkpoints 2
Pending ckpt log id, page 36,1 53,1

[pinch-cdrkojinnbc] (cdrstat) 1029 %

问题解答

如果主要服务器失效,而日志暂存于 HDR 次要服务器上,会出现什么情况?

在手动故障恢复期间,onconfig 参数 DRAUTO 被设置为 0 (DRAUTO =0)。HDR 次要服务器上有暂存的日志,如果处于排出模式下,则会关闭主要服务器。直到 HDR 次要服务器完成从暂存日志读取数据的操作(在排出模式下)之后,才能在 HDR 次要服务器上执行 onmode -d 标准(等待 HDR 次要服务器变为常规模式)。

在自动故障恢复期间,onconfig 参数 DRAUTO 被设置为 1 (DRAUTO =1)。HDR 次要服务器上有暂存的日志,如果处于排出模式下,则会关闭主要服务器。在从暂存日志读取所有数据之后,HDR 次要服务器将回到标准模式下。

如果 HDR 次要服务器重启,而 HDR 次要服务器记录了暂存数据,则会出现什么情况?

如果 HDR 次要服务器上有暂存数据,重启该服务器(在 onmode -kuy 之后运行oninit)将删除暂存数据,并从主要服务器请求日志。

如果 LOG_STAGING_DIR 已经变为一个新目录,而 HDR 次要服务器有暂存数据,则会出现什么情况?

LOG_STAGING_DIR 修改为新目录,而 HDR 次要服务器有暂存数据,在这种情况下,将继续在旧目录中暂存数据,直到遇到下一个检查点(或者旧区域完全用尽),才会在新的区域中暂存数据。

结束语

本文概括了 Informix MACH 11 群集中针对次要服务器的增强。我们已经解释了在 Informix 群集中停止/暂停复制的步骤和代码语法,帮助 DBA 从问题中快速恢复。我们还说明了如何在 RS 次要服务器上制作外部备份。这样做的主要目的是帮助 DBA 降低主要服务器上的负载。最后,我们对 HDR 环境中主要服务器上阻塞的检查点进行了详细说明。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Information Management
ArticleID=764435
ArticleTitle=Informix MACH 11 高可用性特性中针对次要服务器的新增特性
publish-date=10092011