14.3. 实现高可用性

流程

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

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

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

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

   2. 如果使用：

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

         <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 项中指定相同的配置。下面是一个示例配置。

         <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

      此属性控制备份代理在返回到 live 代理后是否自动重启。此属性的默认值为 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 中获取锁定。获取锁定且有最新数据的第一个代理作为实时代理启动，另一个代理则变为备份。

   属性

   指定 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 服务器选择时间的 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 属性。
   namespace （可选）	如果代理与其他应用程序共享 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 代理上将 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 代理对。如果您丢失了到完整的实时备份对的连接，则剩余的两个实时备份对将不再实现仲裁投票。在这种情况下，任何后续复制中断都可能会导致实时代理关闭，并防止其备份代理启动。通过配置集群，假设五个代理对，集群至少可能会出现两个故障，同时仍确保大多数来自仲裁投票的结果。

   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 组都会重复一次。