发生故障时的预期行为
本部分将介绍发生在 ThingWorx HA 配置中，对一个或多个组件故障作出响应的操作。
ThingWorx 服务器故障
ThingWorx 主导节点发生故障
已执行的 HA 过程
1. ZooKeeper 未从主导节点收到任何响应。
2. ZooKeeper 从备用 ThingWorx 服务器的池中选择一个新的主导节点。
3. ZooKeeper 通知备用节点变成主导节点。
4. 新主导节点将完全连接到数据库，并对 ThingWorx 模型进行初始化。
5. 新主导节点会将确认消息发送至负载平衡器，以将所有 ThingWorx 请求路由到该主导服务器。
6. 负载平衡器会将所有 ThingWorx 通信流量路由到新主导节点。
负载平衡器故障
操作和结果将取决于已部署的负载平衡器 HA 解决方案。如果负载平衡器具有在所有负载平衡器节点之间共享会话内容这一功能，则不应中断活动会话。
HAProxy 服务器故障
如果只有一个 HAProxy 节点发生故障或所有 HAProxy 节点均发生故障，则会出现以下情况：
• ThingWorx 主导节点仍可通过其 IP 地址 (而非通过 HAProxy IP 地址) 进行访问。
• 通过 HAProxy 访问 ThingWorx 的请求将无法传送到 ThingWorx。
如果多个 HAProxy 节点中有一个节点发生故障，则会出现以下情况：
• 备用 HAProxy 成为新的主节点后，即会在 ThingWorx Composer 中识别现有用户会话。用户不必再次登录。
• 在备用 HAProxy 成为主节点之前，系统不会加载任何混搭。
• 在备用 HAProxy 成为主节点之前，系统不会加载 Composer 中的浏览实体。
• 在备用 HAProxy 成为主节点之前，请求不会传送到 ThingWorx。
Zookeeper 节点故障
一个 ZooKeeper 节点故障
如果三个 ZooKeeper 节点中有一个节点故障，则会出现以下情况：
• 其他 ZooKeeper 节点会检测到要响应的故障。
• 如果发生故障的节点是当前主导节点，则系统会选择新的 ZooKeeper 主导节点。
• 所有 ThingWorx 服务器均不应受到影响。它们将保持活动状态且可供访问。
两个 ZooKeeper 节点故障
• 无法选择 ZooKeeper 主导节点，因为原始的三节点 ZooKeeper 设置预期在两台服务器可用时才可进行选择。允许的最大故障数 = ceil(N/2) - 1
• 其余的 ZooKeeper 实例既不是主导节点实例也不是备用节点实例。
• ThingWorx 主导节点将关闭，因为它无法通过与 ZooKeeper 通信来实现主导节点选择。
• ThingWorx 备用服务器将保持重试与 ZooKeeper 对话，直到至少有另外一个 ZooKeeper 节点变为备用状态为止。
• 有两个或多个 ZooKeeper 节点重新联机后，即会执行 ZooKeeper 主导节点选择。ThingWorx 备用节点将重新连接到 ZooKeeper，用作新的主导节点。
• 先前的 ThingWorx 主导节点必须重新启动才能成为备用节点。
ThingWorx 和 ZooKeeper 故障
当 ZooKeeper 和 ThingWorx 的主导节点发生故障时，会出现以下情况：
• 所有条件列出在“一个 ZooKeeper 节点故障”下。必须首先确定新的 ZooKeeper 主导节点，以便它继而选择新的 ThingWorx 主导节点。
• 所有条件列出在“ThingWorx 主导节点发生故障”下。
PostgreSQL 故障
此处针对 PostgreSQL 故障的讨论基于以下配置：
• 三个 PostgreSQL 节点 (写入器、读取器和备用节点)
• 在 PostgreSQL 节点之间使用流式复制
• 两个 Pgpool-II 节点，用于管理客户端对 PostgreSQL 节点的访问并管理 PostgreSQL 恢复过程
如果 PostgreSQL 服务器发生故障，则活动的 Pgpool-II 节点会检测到该故障并停止向该服务器传送请求。如果在发生故障之前未提交信息并将其复制到其他节点，则在发生故障时保存的用户或设备数据可能会丢失。
当主 PostgreSQL 节点发生故障 (假定同步节点和潜在节点已启动且正在运行) 时，会出现以下情况：
• 通过 Pgpool-II 对同步节点进行故障转移。此时，潜在节点将成为新主节点的同步节点。但仍可写入数据库 (例如创建新实体和将数据写入 BDWS)。
• 如果原始主节点重新启动，则需手动清理环境并将其配置为使用原始主节点。
当两个备用节点均发生故障时 (假定主节点仍处于开启状态且正在运行)，会出现以下情况：
• 不会发生故障转移，且主节点应不存在可用于复制的节点。
• Composer 仍可供访问。实体将会被加载，且可供查看，但无法保存。可以查看日志。
• 需要写入数据库的操作 (例如，创建和保存实体、将值设置为持久化属性以及添加流条目) 将不会成功，这是因为 PostgreSQL 必须将数据复制到备用节点。
当主节点和同步备用节点发生故障时，会出现以下情况：
• 会对潜在节点进行故障转移。现在，潜在节点即为不带可供复制的节点的主节点。
• Composer 将可供访问。实体将会被加载，且可供查看，但无法保存。可以查看日志。
• 需要写入数据库的操作 (例如，创建和保存实体、将值设置为持久化属性以及添加流条目) 将不会成功，这是因为写入会挂起并最终失败。
当所有三个节点均发生故障时，会出现以下情况：
• 由于没有可用节点，因此不会发生故障转移。
• Composer 没有访问数据库的权限。因此，不应加载实体，大多数服务将无法正常工作 (诸如平台子系统之类的子系统服务可能仍会工作)，并且系统功能会受限 (日志、系统监控和混搭可能会起作用)。
• 将无法写入数据库或从中读取数据。
ThingWorx 和 PostgreSQL 故障
当 ThingWorx 主导节点和 PostgreSQL 主节点发生故障时，会出现以下情况：
• ThingWorx 主导节点发生故障后，备用 ThingWorx 实例会成为主导节点，而 PostgreSQL 数据库的同步节点将成为 PostgreSQL 主节点。
◦ PostgreSQL 数据库的潜在节点将成为新的同步节点。
◦ ThingWorx Composer 可用，且可对 PostgreSQL 数据库执行写入操作 (可以创建、编辑和删除实体，也可以添加数据)。
• 如果原始 PostgreSQL 主节点必须重置为主节点，则必须手动清理 PostgreSQL 节点和 Pgpool-II。
Pgpool-II 节点故障
活动 Pgpool-II 节点故障
如果活动的 Pgpool-II 节点发生故障，则备用节点会检测到该故障，并对传送至 PostgreSQL 服务器的所有请求进行处理。登录到活动 ThingWorx 服务器的用户可能会在其应用程序中延迟，并且在 Pgpool-II 节点发生故障时，可能会丢失正在保存的用户或设备数据。
所有 Pgpool-II 节点故障
当所有 Pgpool-II 实例均发生故障时，ThingWorx 会失去对 PostgreSQL 内容的访问权限，而大部分功能将会失败。某些受限的功能可能会在以下区域中提供：
• 日志记录 - 应用程序日志可能仍会有错误消息更新。
• 系统监控 (如 MonitoringPlatformStats 混搭)
• 混搭 - 不依赖于数据库中的服务或数据的小组件可能仍有效。
• 非持久化属性的属性值
• 与数据库无关的服务。
ThingWorx 和 Pgpool-II 故障
当 ThingWorx 主导节点和 Pgpool-II 主节点实例同时发生故障时，会出现以下情况：
• ThingWorx 主导节点将失去主导权，因此其中一个备用节点会成为主导节点。
• Pgpool-II 主节点虚拟 IP 地址丢失。其中一个 Pgpool-II 备用节点将成为主节点，且虚拟 IP 地址将被重新分配给该主节点。
• ThingWorx 备用服务器将尝试完全连接到数据库，且新的 Pgpool 主节点建立之后，连接即会成功。
Pgpool-II 和 PostgreSQL 故障
当 PostgreSQL 和 Pgpool-II 发生故障时，会出现以下情况：
• PostgreSQL 备用节点将成为主节点。
• Pgpool-II 备用节点将成为主节点，且虚拟 IP 地址将转至该主节点。
• 服务在故障转移期间暂时不可用。