14.3. 实施高可用性

流程

1. 将集群中的代理分组到 live-backup 组中。

   在大多数情况下，live-backup 组应该由两个代理组成：一个实时代理和一个备份代理。如果集群中有六个代理，则需要三个 live-backup 组。

2. 创建一个由一个 live 代理和一个备份代理组成的第一个 live-backup 组。

   1. 打开 live 代理的 < broker_instance_dir> /etc/broker.xml 配置文件。

   2. 如果使用：

      1. 提供共享存储的网络文件系统，验证实时代理的分页、绑定、日志和大型消息目录是否指向备份代理也可以访问的共享位置。

         <configuration>
             <core>
                 ...
                 <paging-directory>../sharedstore/data/paging</paging-directory>
                 <bindings-directory>../sharedstore/data/bindings</bindings-directory>
                 <journal-directory>../sharedstore/data/journal</journal-directory>
                 <large-messages-directory>../sharedstore/data/large-messages</large-messages-directory>
                 ...
             </core>
         </configuration>

      2. 一个提供共享存储的数据库，请确保 master 和 backup 代理都可以连接到同一数据库，并在 broker.xml 配置文件的 database-store 元素中指定相同的配置。示例配置如下所示：

         <configuration>
           <core>
             <store>
                <database-store>
                   <jdbc-connection-url>jdbc:oracle:data/oracle/database-store;create=true</jdbc-connection-url>
                   <jdbc-user>ENC(5493dd76567ee5ec269d11823973462f)</jdbc-user>
                   <jdbc-password>ENC(56a0db3b71043054269d11823973462f)</jdbc-password>
                   <bindings-table-name>BIND_TABLE</bindings-table-name>
                   <message-table-name>MSG_TABLE</message-table-name>
                   <large-message-table-name>LGE_TABLE</large-message-table-name>
                   <page-store-table-name>PAGE_TABLE</page-store-table-name>
                   <node-manager-store-table-name>NODE_TABLE<node-manager-store-table-name>
                   <jdbc-driver-class-name>oracle.jdbc.driver.OracleDriver</jdbc-driver-class-name>
                   <jdbc-network-timeout>10000</jdbc-network-timeout>
                   <jdbc-lock-renew-period>2000</jdbc-lock-renew-period>
                   <jdbc-lock-expiration>15000</jdbc-lock-expiration>
                   <jdbc-journal-sync-period>5</jdbc-journal-sync-period>
                </database-store>
             </store>
           </core>
         </configuration>

   3. 配置 live 代理，以将共享存储用于其 HA 策略。

      <configuration>
          <core>
              ...
              <ha-policy>
                  <shared-store>
                      <master>
                          <failover-on-shutdown>true</failover-on-shutdown>
                      </master>
                  </shared-store>
              </ha-policy>
              ...
          </core>
      </configuration>

      failover-on-shutdown

      如果正常停止这个代理，此属性控制备份代理是否应该变为实时状态，并接管。

   4. 打开备份代理的 < broker_instance_dir> /etc/broker.xml 配置文件。

   5. 如果使用：

      1. 提供共享存储的网络文件系统，验证备份代理的分页、绑定、日志和大型消息目录是否指向与实时代理相同的共享位置。

         <configuration>
             <core>
                 ...
                 <paging-directory>../sharedstore/data/paging</paging-directory>
                 <bindings-directory>../sharedstore/data/bindings</bindings-directory>
                 <journal-directory>../sharedstore/data/journal</journal-directory>
                 <large-messages-directory>../sharedstore/data/large-messages</large-messages-directory>
                 ...
             </core>
         </configuration>

      2. 一个提供共享存储的数据库，请确保 master 和备份代理都可以连接到同一数据库，并在 broker.xml 配置文件的 database-store 元素中指定相同的配置。

   6. 配置备份代理，以将共享存储用于其 HA 策略。

      <configuration>
          <core>
              ...
              <ha-policy>
                  <shared-store>
                      <slave>
                          <failover-on-shutdown>true</failover-on-shutdown>
                          <allow-failback>true</allow-failback>
                          <restart-backup>true</restart-backup>
                      </slave>
                  </shared-store>
              </ha-policy>
              ...
          </core>
      </configuration>

      failover-on-shutdown

      如果这个代理已变为 live，然后被正常停止，则此属性控制备份代理（原始实时代理）是否应实时并接管。

      allow-failback

      如果发生故障转移，并且备份代理已接管用于 live 代理，则此属性控制备份代理在重启并重新连接到集群时是否应返回到原始 live 代理。

      注意

      故障恢复用于实时备份对（一个实时代理通过单一备份代理对）。如果 live 代理配置了多个备份，则不会进行故障恢复。相反，如果发生故障转移事件，备份代理将变为实时，下一个备份将变为备份。当原始的 live 代理重新上线时，它将无法启动故障恢复，因为现在处于活动状态的代理已具有备份。

      restart-backup

      此属性控制备份代理在备份代理失败后是否自动重启。此属性的默认值为 true。

3. 对集群中的每个剩余的 live-backup 组重复步骤 2。

流程

1. 为 live-backup 对中的两个代理打开 <broker_instance_dir> /etc/broker.xml 配置文件。

2. 为对中的两个代理配置相同的复制配置。例如：

   <configuration>
       <core>
           ...
           <ha-policy>
              <replication>
                 <primary>
                   <coordination-id>production-001</coordination-id>
                   <manager>
                      <properties>
                        <property key="connect-string" value="192.168.1.10:6666,192.168.2.10:6667,192.168.3.10:6668"/>
                      </properties>
                   </manager>
                 </primary>
              </replication>
           </ha-policy>
           ...
       </core>
   </configuration>

   primary

   将复制类型配置为 primary，以指示任一代理可以是主代理，具体取决于代理协调的结果。

   coordination-id

   为 live-backup 对中的两个代理指定一个通用字符串值。具有相同 Coordination-id 字符串的代理，协调激活。在协调过程中，两个代理都使用 Coordination-id 字符串作为节点 Id，并在 ZooKeeper 中尝试获取锁定。第一个获取锁定并有最新数据的代理作为 live 代理启动，其他代理变为备份。

   属性

   指定 property 元素，您可以在其中指定一组键值对，以提供 ZooKeeper 节点的连接详情：

   键	值
   connect-string	指定 ZooKeeper 节点的 IP 地址和端口号的逗号分隔列表。例如，value="192.168.1.10:6666,192.168.2.10:6667,192.168.3.10:6668"。
   session-ms	代理在丢失与大多数 ZooKeeper 节点的连接后等待的持续时间。默认值为 18000 ms。有效值介于 ZooKeeper 服务器 tick 时间的 2 倍和 20 倍之间。 注意 ZooKeeper 暂停垃圾回收的时间必须小于 session-ms 属性的值的 0.33，以便 ZooKeeper heartbeat 能够可靠地正常工作。如果无法确保暂停时间小于这个限制，请增加每个代理的 session-ms 属性的值并接受较慢的故障转移。 重要 代理复制合作伙伴每 2 秒自动交换"ping"数据包，以确认合作伙伴代理可用。当备份代理没有收到来自 live 代理的响应时，备份会等待响应，直到代理的连接时间(ttl)过期为止。默认 connection-ttl 为 60000 ms，这意味着备份代理尝试在 60 秒后失败。建议您将 connection-ttl 值设置为与 session-ms 属性值类似的值，以便更快地进行故障转移。要设置新的 connection-ttl，请配置 connection-ttl-override 属性。
   命名空间（可选）	如果代理与其他应用程序共享 ZooKeeper 节点，您可以创建一个 ZooKeeper 命名空间来存储向代理提供协调服务的文件。您必须为 live-backup 对中的两个代理指定相同的命名空间。

3. 为代理配置任何其他 HA 属性。

   这些额外的 HA 属性具有适合大多数常见用例的默认值。因此，如果您不希望默认行为，您只需要配置这些属性。更多信息请参阅 附录 F, 其他复制高可用性配置元素。

4. 重复步骤 1 到 3，以配置集群中的每个额外的 live-backup 代理对。

流程

1. 将集群中的代理分组到 live-backup 组中。

   在大多数情况下，live-backup 组应该由两个代理组成：一个实时代理和一个备份代理。如果集群中有六个代理，则需要三个 live-backup 组。

2. 创建一个由一个 live 代理和一个备份代理组成的第一个 live-backup 组。

   1. 打开 live 代理的 < broker_instance_dir> /etc/broker.xml 配置文件。

   2. 将 live 代理配置为使用其 HA 策略的复制。

      <configuration>
          <core>
              ...
              <ha-policy>
                  <replication>
                      <master>
                          <check-for-live-server>true</check-for-live-server>
                          <group-name>my-group-1</group-name>
                          <vote-on-replication-failure>true</vote-on-replication-failure>
                          ...
                      </master>
                  </replication>
              </ha-policy>
              ...
          </core>
      </configuration>

      check-for-live-server

      如果 live 代理失败，此属性控制客户端在重启时应该会失败。

      如果将此属性设置为 true，则当 live 代理在之前的故障切换后重启时，它会搜索具有相同节点 ID 的集群中的另一个代理。如果 live 代理找到另一个具有相同节点 ID 的代理，这表示在 live 代理失败时成功启动备份代理。在这种情况下，live 代理将其数据与备份代理同步。然后，实时代理会请求备份代理关闭。如果为故障恢复配置了备份代理，如下所示，它会关闭。然后，实时代理恢复其活跃角色，客户端会重新连接它。

      警告

      如果您没有在 live 代理上将 check-for-live-server 设置为 true，则在之前的故障切换后重启 live 代理时可能会遇到重复的消息传递处理。特别是，如果您重启 live 代理，并将此属性设置为 false，则 live 代理不会将数据与其备份代理同步。在这种情况下，实时代理可能会处理备份代理已经处理的相同消息，从而导致重复。

      group-name

      此 live-backup 组的名称（可选）。要组成 live-backup 组，必须使用相同的组名称配置 live 和 backup 代理。如果没有指定 group-name，则备份代理可以使用任何 live 代理进行复制。

      vote-on-replication-failure

      此属性控制实时代理是否在中断复制连接时启动名为 live vote 的仲裁投票。

      实时投票是一种实时代理，用于判断它还是其合作伙伴是中断复制连接的原因。根据投票的结果，实时代理会保持运行或关闭。

      重要

      要使仲裁投票成功，集群的大小必须允许实现大多数结果。因此，当您使用复制 HA 策略时，您的集群应 至少有三个 live-backup 代理对。

      您在集群中配置的更多代理对，提高集群的整体容错能力。例如，假设您有三个 live-backup 代理对。如果您丢失了与完整的 live-backup 对的连接，剩余的两个 live-backup 对无法再实现大部分的仲裁投票。这种情况意味着后续复制中断都可能会导致实时代理关闭，并阻止其备份代理启动。通过配置集群（例如 5 个代理对），集群可以至少遇到两个故障，同时仍然确保任何仲裁投票中的大多数结果。

   3. 为 live 代理配置任何其他 HA 属性。

      这些额外的 HA 属性具有适合大多数常见用例的默认值。因此，如果您不希望默认行为，您只需要配置这些属性。更多信息请参阅 附录 F, 其他复制高可用性配置元素。

   4. 打开备份代理的 < broker_instance_dir> /etc/broker.xml 配置文件。

   5. 配置备份代理，以使用其 HA 策略的复制。

      <configuration>
          <core>
              ...
              <ha-policy>
                  <replication>
                      <slave>
                          <allow-failback>true</allow-failback>
                          <group-name>my-group-1</group-name>
                          <vote-on-replication-failure>true</vote-on-replication-failure>
                          ...
                      </slave>
                  </replication>
              </ha-policy>
              ...
          </core>
      </configuration>

      allow-failback

      如果发生故障转移，并且备份代理已接管用于 live 代理，则此属性控制备份代理在重启并重新连接到集群时是否应返回到原始 live 代理。

      注意

      故障恢复用于实时备份对（一个实时代理通过单一备份代理对）。如果 live 代理配置了多个备份，则不会进行故障恢复。相反，如果发生故障转移事件，备份代理将变为实时，下一个备份将变为备份。当原始的 live 代理重新上线时，它将无法启动故障恢复，因为现在处于活动状态的代理已具有备份。

      group-name

      此 live-backup 组的名称（可选）。要组成 live-backup 组，必须使用相同的组名称配置 live 和 backup 代理。如果没有指定 group-name，则备份代理可以使用任何 live 代理进行复制。

      vote-on-replication-failure

      此属性控制实时代理是否在中断复制连接时启动名为 live vote 的仲裁投票。已激活的备份代理被视为实时代理，并可启动实时投票。

      实时投票是一种实时代理，用于判断它还是其合作伙伴是中断复制连接的原因。根据投票的结果，实时代理会保持运行或关闭。

   6. （可选）配置备份代理启动的仲裁投票的属性。

      <configuration>
          <core>
              ...
              <ha-policy>
                  <replication>
                      <slave>
                      ...
                          <vote-retries>12</vote-retries>
                          <vote-retry-wait>5000</vote-retry-wait>
                      ...
                      </slave>
                  </replication>
              </ha-policy>
              ...
          </core>
      </configuration>

      vote-retries

      此属性控制备份代理重试仲裁投票的次数，以便接收允许备份代理启动的大部分结果。

      vote-retry-wait

      此属性控制备份代理在每次仲裁票重试之间等待的时间（毫秒）。

   7. 为备份代理配置任何其他 HA 属性。

      这些额外的 HA 属性具有适合大多数常见用例的默认值。因此，如果您不希望默认行为，您只需要配置这些属性。更多信息请参阅 附录 F, 其他复制高可用性配置元素。

3. 对集群中的每个额外的 live-backup 组重复步骤 2。

   如果集群中有六个代理，请多次重复这个过程；每个剩余的 live-backup 组一次。