使用Active-Active数据库实现应用程序故障转移

如何将您的应用程序故障转移到连接到远程副本。

Active-Active Redis 部署没有内置的应用程序连接故障转移或故障恢复机制。 使用 Active-Active 数据库部署的应用程序会连接到地理上较近的数据库副本。 如果该副本不可用，应用程序可以故障转移到远程副本，并在必要时再次故障恢复。 在本文中，我们将解释此过程的工作原理。

Active-Active连接故障转移可以提高数据的可用性，但可能会对数据一致性产生负面影响。 像Redis复制这样的Active-Active复制是异步的。 一个应用程序如果故障转移到另一个副本，可能会错过写操作。 如果故障副本将写操作保存在持久存储中， 那么当故障副本恢复时，这些写操作将被处理。

检测失败

您的应用程序可以检测到两种类型的故障：

  1. 本地故障 - 本地副本已关闭或不可用
  2. 复制失败 - 本地副本可用，但无法复制到或从远程副本复制

本地故障

当应用程序因任何原因无法连接到数据库端点时，会检测到本地故障。本地故障的原因可能包括：多个节点故障、配置错误、连接被拒绝、连接超时、意外的协议级别错误。

复制失败

复制失败在没有引起误报的情况下更难以可靠地检测。复制失败可能包括：网络分裂、复制配置问题、远程副本失败。

最可靠的复制健康检查方法是使用Redis发布/订阅（pub/sub）机制。

注意：
请注意，本文档并不建议Redis的发布/订阅在通常意义上是可靠的。在某些情况下，消息可能会丢失，但在此情况下这是可以接受的，因为通常应用程序在一段时间内无法传递一定数量的消息后才会确定复制已停止。

当你使用发布/订阅数据类型来检测故障时，应用程序：

  1. 连接到所有副本，并为每个副本订阅一个专用通道。
  2. 连接到所有副本并定期发布唯一可识别的消息。
  3. 监控接收到的消息，并确保它能够在预定的时间窗口内接收到自己的消息。

您还可以使用已知的数据集更改来监控复制流的可靠性， 但发布/订阅是首选方法，因为：

  1. 它不涉及数据集的变化。
  2. 它不对数据集做任何假设。
  3. 发布/订阅消息作为复制效果传递，是活动复制链接的更可靠指示器。在某些情况下，即使复制链接失败，数据集键也可能显示为已修改。这是因为键可能通过全状态复制（重新同步）或通过在线复制效果接收更新。

分片对故障检测的影响

如果你的分片配置是对称的，请确保每个分片至少使用一个键（PUB/SUB通道或真实数据集键）。分片是单独复制的，容易发生故障。对称分片配置在所有副本中具有相同数量的分片和哈希槽。 我们不推荐使用非对称分片配置，这需要每个与一对分片相交的哈希槽至少有一个键。

为了确保每个分片至少有一个键，应用程序应该：

  1. 使用Cluster API检索数据库分片配置。
  2. 计算一些关键名称，使得每个分片有一个键。
  3. 将这些键名用作发布/订阅机制的通道名称。

故障转移

当应用程序需要故障转移到另一个副本时，它应该简单地重新建立与远程副本上的端点的连接。由于Active/Active和Redis复制是异步的，远程端点可能没有所有本地执行和确认的写入。

最好您的应用程序不要读取自己最近的写入。这些写入可以是：

  1. 如果本地副本发生双重故障或持久文件丢失等事件，数据将永久丢失。
  2. 暂时不可用，但如果本地副本的故障是暂时的，稍后将可用。

故障恢复决策

您的应用程序可以使用上述相同的检查来继续监控故障转移后失败副本的状态。

为了在故障恢复过程中监控副本的状态，您必须确保副本可用、与远程副本重新同步，并且不处于陈旧模式。PUB/SUB机制是监控此过程的有效方法。

基于数据集的机制可能不太可靠，原因有几个：

  1. 为了确定本地副本不是过时的，仅仅从中读取键是不够的。您还必须尝试向其写入。
  2. 如上所述，某些键的远程写入在复制链接恢复之前以及副本仍处于陈旧模式时出现在本地副本中。
  3. 从未写入的副本永远不会过时，因此在启动时它立即准备就绪，但会在更长的时间内提供过时的数据。

副本配置更改

所有故障转移和故障恢复操作应严格在应用程序端进行，不应涉及对Active-Active配置的更改。 唯一需要重新配置Active-Active部署并移除副本的有效情况是，由于无法执行垃圾回收而导致内存消耗过高。 一旦移除副本，它只能作为新副本重新加入，并且会丢失任何未收敛的写入。

RATE THIS PAGE
Back to top ↑