第 9 部分 Inix 复制技术.doc

第 9 部分: Informix 复制技术关于本教程本教程讨论 IDS 11.50 提供的各种复制和高可用性技术。它解释了如何配置 High Availability Data Replication (HDR)、Enterprise Replication (ER)、Remote Standalone secondary (RSS) 服务器、Shared Disk secondary (SDS) 服务器和持续日志恢复。目标本教程主要帮助您熟悉： IDS 提供的各种复制技术 各种复制技术之间的区别 不同的复制术语 如何设置 HDR、ER、RSS、SDS 和持续日志恢复 回页首先决条件本文主要针对初级和中级水平的 IDS 数据库专业人员。您应该能够轻松设置 sqlhosts 文件、设置配置参数和开始使用 IDS。您应该熟悉各种 IDS 实用工具，比如 onmode、onstat、ontape 和 ON-bar 等等。回页首系统需求要运行本教程提供了例子，您需要一个安装了 IDS 并且能够启动两个 IDS 实例的计算机。高可用性数据复制：简介对于提供全天候在线服务的企业，数据的高可用性是必要因素。如果服务器离线，此类公司将损失惨重。Informix Dynamic Server 通过一套完整的技术提供无间断的持续服务，从而将停机和维护时间降至最低。企业可以将复制技术用于： 容量释放：您可以将 OLTP 数据传播到备份站点，可以在报告时将用户引导到备份站点。这样，就可以在主站点上为与 OLTP 相关的用户提供更多的容量。 高可用性：在主站点更新数据，然后再复制到备份站点。当主站点出现故障时，备份站点将成为主站点。 数据合并：您可以将远程数据合并到中央服务器中。例如，您可以合并分支机构的数据。 分布式可用性：您可以从中央服务器将数据分布到不同位置。例如，您可以从总部将数据分发到分支机构。 就地更新：以点对点的方式在任意站点上更新数据，从而保持数据的一致性。 什么是 HDR？HDR 提供一个机制，可以在一个服务器（主服务器）上创建和维护日志数据库的副本，并将该副本映射到另一个服务器（备份服务器）。在 HDR 设置中有一个主服务器和一个备份服务器。如果主服务器失败，应用程序可以连接到备份服务器并继续进行操作。HDR 的最高目标是尽量减少或消除物理服务器故障的影响。HDR 对中的备份服务器仅在只读模式下可用。报告应用程序和工具可以在只读模式下的备份服务器中运行，从而减轻主服务器的负载。回页首HDR 的工作原理当在主服务器的日志数据库中执行 Data Manipulation Language (DML) 语句时，逻辑日志记录将被发送到备份服务器。备份服务器将应用逻辑日志记录，通过主服务器中的更新保持数据库状态是最新的。备份服务器的更新可以是同步或异步的。位于主服务器和备份服务器之间的检查点是同步的；这就是说，仅当检查点在备份数据库服务器上完成之后，它才能在主服务器上完成。回页首HDR 的先决条件HDR 需要满足以下先决条件： 主服务器和备份服务器的操作系统和硬件相同。不能在不同的操作系统之间设置 HDR。 添加到每个服务器的块的磁盘布局必须相同。必须在备份服务器上创建可用的驻留数据库块的设备，并且其 PATH 值必须与主服务器一样。这可以通过符号链接来实现。 HDR 主服务器和备份服务器上的 IDS 的版本必须一样。 必须记录数据库日志。 如果使用 blob 数据库类型，那么它们必须储存在 dbspace 中。将不复制存储在 dbspace 中的 blob 数据类型。 如果根块（chunk）被映射到主服务器，那么也必须将它映射到备份服务器。 HDR 使用 TCP/IP 连接。数据库服务器的名称（DBSERVERANME 配置参数的值）必须设置为 sqlhosts 文件中的 TCP/IP 连接。 主服务器和备份服务器都必须是可信的。为用户 informix 修改 .rhosts 或 /etc/hosts.equiv 以建立可信通信。 回页首影响 HDR 的配置参数以下配置参数能够影响 HDR 及其性能： DRAUTO：DRAUTO 配置参数决定在主服务器失败时备份服务器采取什么操作。该参数的设置在主服务器和备份服务器中必须相同。需要谨慎地使用该参数。如果出现临时的网络失败，每个服务器都能感知对方宕机。对于这种情况，如果 DRAUTO 设置为 1，备份服务器将转变为标准服务器，而主服务器停止复制。客户端将分别尝试在这两个服务器上更新数据。这可能导致服务器不能保持同步。根据 DRAUTO 的设置不同，备份服务器可能执行以下操作之一： o 如果 DRAUTO 设置为 0，备份服务器将保持只读状态，直至手动地将其切换为主服务器或切换到标准模式。 o 如果 DRAUTO 设置为 1（RETAIN_TYPE），备份服务器在主服务器失败时自动切换为标准服务器。当 HDR 对重新启动时，该服务器将重新切换回到备份服务器。 o 如果 DRAUTO 设置为 2（REVERSE_TYPE），备份服务器在主服务器失败时自动切换成主服务器。当 HDR 对重新启动之后，该服务器将切换为主服务器（而原先的主服务器切换为备份服务器）。 DRINTERVAL：DRINTERVAL 指定 HDR 数据缓冲区刷新之间的最大秒数。该参数在主服务器和备份服务器上的设置必须相同。 HDR 有两个主要操作模式：同步和异步。让我们看看更新如何从主服务器传播到备份服务器。当主服务器开始将共享内存中的逻辑日志缓冲区的内容转储到磁盘的逻辑日志时，它同样将逻辑日志缓冲区的内容复制到一个数据复制缓冲区。数据复制缓冲区是主服务器管理的虚拟共享内存的一部分。数据复制缓冲区的大小与逻辑日志缓冲区的大小一样。然后，主服务器以同步或异步的方式将数据复制缓冲区的内容发送到 HDR 备份服务器。配置参数 DRINTERVAL 的值决定服务器使用同步还是异步的方式进行更新。o 如果 DRINTERVAL 设置为 -1，更新就是同步的。 o 如果 DRINTERVAL 设置为 -1 以外的其他值，那么更新就是异步的。 HDR 同步更新：当 DRINTERVAL 设置为 -1 时，到 HDR 备份服务器的数据复制就是同步的。当主服务器向 HDR 缓冲区写入逻辑日志缓冲内容时，它就将这些记录从缓冲区发送到 HDR 备份服务器。仅当主服务器收到来自 HDR 备份服务器关于记录已经接收的确认消息之后，主服务器上的逻辑日志缓冲转移才完成。HDR 异步更新：当 DRINTERVAL 设置为 -1 以外的其他值时，到 HDR 备份服务器的数据复制就是异步的。主服务器在将逻辑日志缓冲区内容复制到 HDR 缓冲区之后才刷新逻辑日志缓冲区。当发生以下情况之一，主服务器将通过网络发送 HDR 缓冲区的内容，并且不受以上操作的影响：HDR 缓冲区变满，或者从最后一次刷新 HDR 复制缓冲区开始，在主服务器上由 DRINTERVAL 指定的时间间隔被错过。 DRTIMEOUT：DRTIMEOUT 指定 HDR 对等待彼此的传输确认消息的时间间隔（单位为秒）。如果检查点没有在配置参数 DRTIMEOUT 指定的时间内完成，主服务器就认为发生了故障。该参数在主服务器和备份服务器上的值必须相同。 DRLOSTFOUND：DRLOSTFOUND 配置参数指定 dr.lostfound.timestamp 文件的路径名。如果主服务器没有在 DRTIMEOUT 配置参数指定的时间内收到备份服务器的确认，它将向一个由 DRLOSTFOUND 配置参数命名的文件添加事务信息。 ENCRYPT_HDR：ENCRYPT_HDR 指定是否启用 HDR 加密。 o 1 表示启用；为服务器之间的数据传输提供安全的办法 o 0 表示禁用 增加安全性会带来额外的开销。加密和解密 HDR 数据要占用额外的 CPU 周期。 DRIDXAUTO：DRIDXAUTO 指定当备份服务器检测到索引损坏时，HDR 服务器是否自动开始索引复制。 o 1 = on；自动复制索引 o 0 = off；需要手动复制索引 LOG_INDEX_BUILDS：LOG_INDEX_BUILDS 指定是否启用索引页日志。 o 1：启用索引页日志。索引页被复制到逻辑日志。主服务器通过日志将索引发送到备份服务器。 o 0：禁用索引页日志。当在主服务器上创建了索引时，将逐页把它传输到备份服务器。 如何设置和管理 HDR首次设置 HDR在进入设置 HDR 的步骤之前，首先要为 informix 用户启用主服务器和备份服务器之间的可信通信。为网络连接更新 $INFORMIXSQLHOSTS 和 /etc/services 文件。确保 onconfig 文件在主服务器和备份服务器上都正确设置。以下配置参数在主服务器和备份服务器上的值必须相同。 ROOTNAME ROOTOFFSET ROOTPATH ROOTSIZE MIRROROFFSET - 如果使用映像 MIRRORPATH - 如果使用映像 PHYSDBS PHYSFILE LOGFILES LOGSIZE DYNAMIC_LOGS DRAUTO DRINTERVAL DRTIMEOUT DRLOSTFOUND LOG_INDEX_BUILDS：可选 表 1. 首次设置 HDR 的步骤步骤主服务器备份服务器1 安装和注册 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 -e5 -onmode -d secondary prim_name 6 -ontape -l or onbar -r -l 下面详细描述表 1 中的步骤：1. 在两个服务器上 安装 用户定义的类型、用户定义的例程和 DataBlade 模块。仅在主服务器上注册它们。 2. 对主服务器 执行 0 级别的部分。 3. 运行 以下命令将服务器设置为主服务器： onmode -d primary sec_name4.5. 在以上命令中，将 sec_name 替换为备份服务器的数据库服务器名（DBSERVERNAME 配置参数的值）。在执行该命令之后，以下消息将打印到 online.log：DR: new type = primary server name = sec_nameDR: Trying to connect to secondary serverDR: Cannot connect to secondary server6.7. 在 备份服务器 上，使用备份时采用的实用工具从在步骤 2 中创建的 0 级别备份执行物理恢复。不要执行逻辑恢复。 o ON-Bar：使用 onbar -r -p 命令执行物理恢复。 o ON-Bar 并执行外部恢复：使用 onbar -r -p -e 命令执行物理恢复。 o ontape：使用 ontape -p 选项。您不能使用 ontape -r 选项，因为它同时执行物理和逻辑恢复。 o ontape 和执行外部恢复：使用 ontape -p -e 命令执行物理恢复。 8. 在 备份服务器 上，运行以下命令将服务器设置为备份服务器： onmode -d secondary prim_name9.10. 在以上命令中，将 prim_name 替换为主服务器的数据库服务器名（DBSERVERNAME 配置参数的值）。如果磁盘上的所有逻辑日志仍然可用的话，备份服务器上的恢复就能够完成；否则需要执行步骤 6。在执行该命令之后，将在备份服务器的 online.log 中打印以下消息：DR: new type = secondary server name = prim_name11.12. 如果 写到主服务器的逻辑日志记录不再存在主服务器磁盘上，那么备份服务器将提示您从磁带备份恢复这些文件。从磁带恢复了所有逻辑日志文件之后，逻辑恢复就完成了，从而可以在主服务器磁盘上使用逻辑日志文件。 当 HDR 设置成功完成之后，将在主服务器的 online.log 打印以下消息：DR: Primary server connected DR: Primary server operational将在备份服务器的 online.log 中打印以下消息：Secondary server operational回页首更改服务器类型您可以将备份服务器的类型更改为主服务器或标准服务器。如果 HDR 在备份服务器上关闭了，那么仅能从备份服务器更改为标准服务器（使用 onmode -d standard 命令）。如果到主服务器的复制连接断开或备份服务器上的复制失败，HDR 将关闭。当您重启标准服务器时，它不会尝试连接到复制对中的另一个服务器。使用 HDR 时，更改一个服务器的模式可能导致需要更改 HDR 对中的另一个服务器。这个小节讨论当 HDR 对中的一个服务器失败时会发生什么。在主服务器上，运行 onmode -k 命令将导致： 备份服务器在消息日志中打印一条消息： DR: Receive error. HDR is turned off. 备份服务器受到的影响取决于 DRAUTO 配置参数的设置： o 如果 DRAUTO 设置为 0，备份服务器将保持只读模式。 o 如果 DRAUTO 设置为 1，备份服务器将切换到标准模式，并且可以接受更新。 o 如果 DRAUTO 设置为 2，备份服务器将在旧主服务器连接丢失时切换到主服务器模式。 在备份服务器上，运行 onmode -k 命令将导致主服务器在消息日志中打印：DR: Turned off on primary serverEnterprise Replication：简介Enterprise Replication (ER) 是一种基于异步日志的复制方法。当复制事务被提交并发送到目标实例（在此处用作常规日志事务）之后，将从源实例的逻辑日志捕捉它们。这种类型的复制对源实例的影响很小。由于信息是从逻辑日志读取的，所以它不影响事务处理。因为复制是异步的，所以源实例将继续进行处理，而不是等待事务被应用到目标实例。Enterprise Replication 的灵活架构支持多种复制方法和网络拓扑： 复制方法： o 主服务器-备份服务器（Primary-target）- 数据库更改发生在主服务器并被复制到目标实例，但目标实例上的更改不会复制到主服务器实例 o 处处更新（Update-anywhere）- 数据库更改应用到所有参与复制的实例，不管它们位于哪个服务器 网络拓扑： o 完全连接（Fully connected）- 所有参与数据库服务器之间持续保持连接 o 层次结构树（Hierarchical tree）- 一种支持持续连接和间断连接的父-子配置 o 森林树（Forest of trees）- 通过根数据库服务器连接起来的多个层次结构树 Enterprise Replication 可以与 HDR、SDS 和 RSS 复制方法结合使用，这进一步增加了它的灵活性。此外，它还可以跨平台、跨 IBM Informix Dynamic Server 的各个版本使用。Enterprise Replication 不需要在实例之间定义相同的储存，甚至不需要使用相同的表模式和名称。Enterprise Replication 的工作原理下面列出了 Enterprise Replication 的 3 个阶段，并通过一个例子详细描述这 3 个阶段： 数据捕捉 数据传输 应用复制数据 让我们通过一个简单的例子了解如何将一个事务从源实例复制到目标实例：1. 客户端应用程序在定义了复制的数据库中执行事务。 2. 该事务被写入逻辑日志。 3. 日志捕捉组件读取逻辑日志并将逻辑记录传递到分组组件。 4. 分组组件计算需要复制的逻辑日志，并将它们分组到描述原始事务的操作的消息中。 5. 分组组件将消息添加到发送队列。在特定情况下，发送队列将消息临时储存到磁盘上。 6. 发送队列通过 Enterprise Replication 网络将复制消息传输到目标服务器。 7. 复制消息被添加到目标服务器的接收队列中。 8. 数据同步组件将该事务应用到目标数据库。如果有必要的话，数据同步组件还会执行冲突解决。 9. 在确认队列中放置一条表示消息已成功应用的消息。 10. 将确认消息发送回到源服务器。 回页首首次设置 Enterprise Replication影响 Enterprise Replication 的配置参数： CDR_EVALTHREADS - 每个 CPU VP 的计算器线程数和额外的线程数，用逗号分隔（必要） CDR_DSLOCKWAIT - 数据同步组件等待数据库锁的秒数（必要） CDR_QUEUEMEM - 发送和接收队列的最大内存量，单位为 KB（必要） CDR_NIFCOMPRESS - 控制网络界面压缩级别（必要） CDR_SERIAL - 指定增量大小和复制连续列的开始值（必要） CDR_DBSPACE - syscdr 数据库的 dbspace 名称（可选） CDR_QHDR_DBSPACE - 事务记录 dbspace 的名称；默认值为根 dbspace（可选） CDR_QDATA_SBSPACE - 临时储存到磁盘的事务数据的 sbdpace 名称，用逗号分隔（必要） CDR_MAX_DYNAMIC_LOGS - ER 在一个数据库会话中能够发出的动态日志请求的最大数量（必要） CDR_SUPPRESS_ATSRISWARN - 数据同步错误，警告在 STS 和 RIS 文件中隐藏的编码号（可选） 现在，我们通过一个例子了解如何在两个带有以下特征的实例中定义复制。这个例子展示处处更新复制。在处处更新复制中，任何服务器上的更改都被复制到其他所有参与服务器中。 在 cook 文件 /u/data/qdatasbspace 中有一个名为 qdatasbspace 的 CDR_QDATA_SBSPACE，它的偏移量为 0，大小为 200MB 源组名 grp_er1，目标组名 grp_er2 源 DBSERVERNAME er1，目标 DBSERVERNAME er2 源数据库名 primary_db，目标数据库名 target_db 源表名 primary_table，目标表名 target_table 源 ATS 目录名 /u/data/atsdir，目标 ATS 目录名 /u/data/atsdir 源 RIS 目录名 /u/data/risdir，目标 RIS 目录名 /u/data/risdir 复制名 repl1 这个例子使用 “timestamp” 冲突解决方法。可用的冲突解决方法包括： always - Enterprise Replication 不解决冲突，但是将应用复制更改，即使操作在源和目标服务器上不一样。仅能用于从源服务器到目标服务器的复制。 ignore - Enterprise Replication 不解决冲突。 timestamp - 出现冲突时，时间戳最新的行或事务具有优先权。 deletewins - 出现冲突时，带有 DELETE 操作或带有最新时间戳的行或事务具有优先权。deletewins 冲突解决规则阻止 upsert。 表 2. 首次设置 ER 的步骤步骤源服务器目标服务器1使用 onspaces 为临时储存到磁盘的事务数据创建 sbspace，由 CDR_QDATA_SBSPACE 指定： onspaces -c -S qdatasbspace -p /u/data/qdatasbspace -o 0 -s 200000 使用 onspaces 为 CDR_QDATA_SBSPACE 定义 sbspace： onspaces -c -S qdatasbspace -p /u/data/qdatasbspace -o 0 -s 200000 2修改 onconfig 文件以设置 CDR_QDATA_SBSPACE： CDR_QDATA_SBSPACE qdatasbspace 修改名为 CDR_QDATA_SBSPACE 的 onconfig 配置文件： CDR_QDATA_SBSPACE qdatasbspace 3配置 sqlhosts 文件，以包含源服务器和目标服务器的连接： grp_er1 group - - i=12 er1 onsoctcp primary 9211 g=grp_er1 grp_er2 group - - i=13 er2 onsoctcp stewie 9212 g=grp_er2 配置 sqlhosts 文件，以包含源服务器和目标服务器的连接： grp_er1 group - - i=12 er1 onsoctcp primary 9211 g=grp_er1 grp_er2 group - - i=13 er2 onsoctcp stewie 9212 g=grp_er2 4为进行复制定义源服务器和目标服务器： cdr define server -c grp_er1 -A /u/data/atsdir -R /u/data/risdir -I grp_er1 cdr define server -c grp_er2 -A /u/data/risdir -R /u/data/risdir -I -S grp_er1 grp_er2 -5定义复制： cdr define replicate -C timestamp -S tran -A -R repl1 primary_dber1.primary_table select * from primary_table target_dber2.target_table select * from target_table 注意：这将把 primary_table 的所有行复制到 target_table。可以在这里使用任何有效的 select 语句，以定义需要复制的数据。 -6开始复制： cdr start replicate repl1 -这是设置复制的简单例子。阅读文档更详细地了解命令行语法和选项。Shared Disk secondary：简介在 Shared Disk (SD) secondary 复制中，主服务器和 SD 备份服务器通过一个高度可用的集群配置共享磁盘空间。在该配置中，不在 SD 备份服务器中储存数据库的物理副本。如果主服务器和 SD 备份服务器驻留在相同的机器上，它们都可以访问本地磁盘。如果它们驻留在不同的物理机器上，那么配置它们以使用共享磁盘设备。不要将主服务器和 SD 备份服务器配置为使用操作系统缓冲区，比如 NFS 装载。主服务器和 SD 备份服务器共享磁盘空间，因此 SD 备份服务器的启动非常快，但它不能在复制环境之外提升为标准服务器，也不能提升为 RS 备份服务器。SD 备份服务器可以和 Enterprise Replication、HDR 和 RS 备份服务器并存。什么时候使用 SD 备份服务器？ 增加容量：使用多个 SD 备份服务器能够减少报告容量，同时不影响主服务器实例。 主服务器失败备份：当主服务器失败时，SD 备份服务器能够快速提升为主服务器。 当磁盘失败时，SD 备份服务器不能用作热点备份。如果需要使用热点备份，推荐使用 HDR 备份服务器或 RS 备份服务器。回页首SD secondary 复制的工作原理因为主服务器和 SD 备份服务器共享磁盘空间，所以不需要在服务器之前传递日志。要保持实例同步，仅需发送日志的位置。回页首首次设置 SD secondary 复制影响 SD secondary 复制的配置参数： SDS_ENABLE - 启用或禁用 SDS 服务器（必要） SDS_TEMPDBS - SDS 服务器使用的临时 dbspace SDS_PAGING - 两个缓冲页文件的路径 SDS_TIMEOUT - 在将 SDS 服务器标记为宕机之前执行页刷新时，主服务器等待来自 SDS 服务器的确认的时间（秒） UPDATABLE_SECONDARY - 控制备份服务器是否能够接受更新、插入和删除操作 TEMPTAB_NOLOG - 控制临时表的日志模式（在 SDS 服务器上要设置为 1） 表 3. 首次设置 SDS 服务器的步骤步骤主服务器备份服务器1在 onconfig 文件中设置 SDS_TIMEOUT 配置参数。-2设置 SD 主服务器的别名： onmode -d set SDS primary alias -3-设置配置参数： SDS_ENABLE SDS_PAGING SDS_TEMPDBS 4-设置以下配置参数，使它们与主服务器上的参数匹配： ROOTNAME ROOTPATH ROOTOFFSET ROOTSIZE PHYSFILE LOGFILES LOGSIZE 5-在 sqlhosts 文件中添加一个主服务器条目： dbservername nettype hostname servicename 6-开始使用 SD secondary 服务器： oninit 查看文档详细了解命令行语法和选项。将 SDS 服务器提升为主服务器当主服务器失败时，通过发出以下命令之一将 SDS 服务器提升为主服务器：onmode -d set SDS primary aliasonmode -d make primaryRemote Standalone 备份服务器：简介RS (Remote Standalone) 备份服务器非常类似于 HDR 备份服务器。它可以在高度可用的集群中用于灾难恢复。它包含数据库的完整副本，以类似于 HDR 的方式接收日志，并且要求主服务器和备份服务器使用相同的硬件和数据布局。使用 RS 备份服务器解决了只能使用一个备份服务器的限制，从而增强了可用性。尽管 HDR 环境和 RS secondary 环境是相似的，但它们也有两个主要区别： HDR 支持同步和异步模式，而 RS secondary 仅支持异步复制。 HDR 使用同步检查点，而 RS secondary 没有使用。 什么时候使用 RS 备份服务器？ 增强服务器可用性：使用多个 RS 备份服务器能够提供更大的可用性。 远程地理位置备份支持：通过将复制节点分布到多个地理位置，单点灾难导致停机的机会减少。 改善报告性能：多个 RS 备份服务器可以将一部分报告转移到备份服务器，从而减轻报告对主服务器的影响。 在不稳定的网络中增强可用性：在不稳定或速度很慢的网络环境中，RS 备份服务器通过利用异步复制消除在主服务器上出现的延迟。主服务器和 RS 备份服务器之间不同步任何事务提交和检查点。 回页首RS secondary 复制的工作原理当在主服务器上对日志数据库执行 Data Manipulation Language (DML) 语句时，逻辑日志记录将被发送到备份服务器。备份服务器应用逻辑日志记录。RS 备份服务器的更新通常是异步的。回页首首次设置 RS secondary 复制影响 RS secondary 复制的配置参数： HA_ALIAS - 高可用性集群的服务器别名 LOG_INDEX_BUILDS - 启用或禁用索引页日志（必要） UPDATABLE_SECONDARY - 控制备份服务器是否可以接受更新、插入和删除操作 FAILOVER_CALLBACK - 当备份服务器切换为标准或主服务器时，指定需要调用的路径和程序名 TEMPTAB_NOLOG - 控制临时表的默认日志模式（在 RS 备份服务器上需要设置为 1） 表 4. 首次设置 RS 的步骤步骤主服务器备份服务器1安装和注册 UDR、UDT 和 DataBlade 模块。安装 UDR、UDT 和 DataBlade 模块。2onmode 命令： onmode -wf LOG_INDEX_BUILDS=1 -3onmode 命令： onmode -d add RSS rss_servername password -4ontape 或 ON-Bar 命令： ontape -s -