利用多可用区最大限度地减少 MemoryDB 停机时间 - Amazon 内存 DB

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

利用多可用区最大限度地减少 MemoryDB 停机时间

有许多情况下,MemoryDB 可能需要替换主节点;这些情况包括特定类型的计划维护以及主节点或可用区出现故障的意外事件。

节点故障的响应取决于哪个节点出现故障。但是,在所有情况下,MemoryDB 都确保在节点更换或失效转移期间不会出现任何数据的丢失。例如,如果副本出现故障,则会替换故障节点,并同步事务日志中的数据。如果主节点出现故障,则会触发失效转移到一致副本,从而确保失效转移期间不会发生任何数据的丢失。现在,写入数据通过新主节点提供。随即替换旧主节点,并从事务日志同步。

如果主节点在单节点分片(没有副本)上失效,则在替换主节点并同步事务日志之前,MemoryDB 将停止接受写入。

节点替换会导致集群出现停机时间,但如果多可用区处于活动状态,则会最大限度缩短停机时间。主节点的角色会自动将故障转移到其中一个副本。MemoryDB 会透明地处理这一点,因此无需创建和预置新的主节点。此故障转移和副本提升可确保您在提升完成后立即继续写入新的主节点。

如果由于维护更新或服务更新而启动了计划的节点替换,请注意,在集群处理传入的写请求时,完成计划的节点替换。

MemoryDB 集群上的多可用区提高容错能力。在集群的主节点出于任何原因变得无法连接或发生故障时,此情况尤其如此。MemoryDB 集群上的多可用区要求每个分片具有多个节点,并且可以自动启用。

故障情形及多可用区响应

如果多可用区处于活动状态,则失效的主节点将失效转移到可用副本。副本自动与事务日志同步并变为主节点,这比创建并重新预配置新的主节点快得多。提升过程通常只需几秒钟的时间,然后您可以再次对集群进行写入。

在多可用区处于活动状态时,MemoryDB 将持续监控主节点的状态。如果主节点发生故障,则根据故障的类型执行以下操作之一。

仅主节点出现故障时的故障情形

如果只有主节点失效,则副本将自动变为主节点。然后,将在与发生故障的主节点相同的可用区域中创建和预置替换只读副本。

仅当主节点出现故障时,MemoryDB 多可用区才执行以下操作:

  1. 发生故障的主节点脱机。

  2. up-to-date 副本会自动变为主副本。

    一旦失效转移过程完成(通常只需几秒钟的时间),写入操作就会恢复。

  3. 启动和预配置替代副本。

    将在可用区(发生故障的主节点的位置)启动替换副本,以便维护节点的分配。

  4. 副本与事务日志同步。

有关查找集群的终端节点的信息,请参阅以下主题:

 

当主节点和一些副本发生故障时的故障情形

如果主群集和至少一个副本出现故障,则 up-to-date 副本将升级为主群集。并在与故障节点相同的可用区中创建新副本。

在主节点和一些副本发生故障时,MemoryDB 多可用区执行以下操作:

  1. 发生故障的主节点和发生故障的副本脱机。

  2. 可用副本将变为主节点。

    一旦失效转移过程完成(通常只需几秒钟的时间),写入操作就会恢复。

  3. 创建和预配置替换副本。

    将在可用区(发生故障的节点的位置)创建替换副本,以便维护节点的分配。

  4. 所有节点都与事务日志同步。

有关查找集群的终端节点的信息,请参阅以下主题:

 

整个集群出现故障时的故障情形

如果整个集群全部发生故障,则在与原始节点相同的可用区中重新创建所有节点并预配置。

在此场景中,不会发生数据的丢失,原因在于数据保留在事务日志中。

当整个集群发生故障时,MemoryDB 多可用区将执行以下操作:

  1. 发生故障的主节点和副本脱机。

  2. 已创建并配置替换主节点,并与事务日志同步。

  3. 创建和预置替换副本,并与事务日志同步。

    将在可用区(发生故障的节点的位置)创建替换,以便维护节点的分配。

有关查找集群的终端节点的信息,请参阅以下主题:

测试自动失效转移

您可以使用 MemoryDB 控制台、 AWS CLI和 MemoryDB API 测试自动失效转移。

在测试时,请注意以下内容:

  • 在任意 24 小时期间,此操作最多可以使用五次。

  • 如果在不同集群的分片上调用此操作,您可以让调用同时进行。

  • 在某些情况下,您可能会在同一 MemoryDB 集群中的不同分片上多次调用此操作。在这种情况下,必须先完成第一个节点替换,然后再进行后续调用。

  • 要确定节点替换是否已完成,请使用 MemoryDB 控制台 AWS CLI、或 MemoryDB API 检查事件。查找下列与 FailoverShard 相关的事件,此处按事件的可能发生顺序列出:

    1. 集群消息:FailoverShard API called for shard <shard-id>

    2. 集群消息:Failover from primary node <primary-node-id> to replica node <node-id> completed

    3. 集群消息:Recovering nodes <node-id>

    4. 集群消息:Finished recovery for nodes <node-id>

    有关更多信息,请参阅下列内容:

  • 此 API 旨在测试发生 MemoryDB 故障转移时您的应用程序的行为。它不是用于启动故障转移以解决集群问题的操作工具。此外,在某些情况下,例如大规模运营事件, AWS 可能会阻止此 API。

使用测试自动故障转移 AWS Management Console

使用以下过程测试通过控制台进行自动故障转移。

  1. 登录 AWS Management Console 并打开 MemoryDB 控制台,网址为 https://console.aws.amazon.com/memorydb/。

  2. 选择要测试的集群左侧的单选按钮。此集群必须至少有一个副本节点。

  3. Details 区域中,确认此集群已启用多可用区。如果集群未启用多可用区,则选择其他集群或者修改此集群以启用多可用区。有关更多信息,请参阅 修改 MemoryDB 集群

  4. 选择集群的名称。

  5. 分片和节点页面上,对于要测试失效转移的分片,选择分片的名称。

  6. 在节点上,选择失效转移主节点

  7. 选择 Continue 可对主节点进行故障转移,选择 Cancel 可取消操作,不对主节点进行故障转移。

    故障转移过程中,控制台继续将节点状态显示为可用。要跟踪您的故障转移测试进度,请从控制台导航窗格选择 Events。在 Events 选项卡上,观察指示故障转移已开始(FailoverShard API called)和已完成(Recovery completed)的事件。

 

使用测试自动故障转移 AWS CLI

您可以使用 failover-shard AWS CLI 操作在任何启用多可用区的集群上测试自动故障转移

参数
  • --cluster-name – 必需。要测试的集群。

  • --shard-name – 必需。要在其上测试自动故障转移的分片的名称。在 24 小时滚动期间您最多可以测试 5 个分片。

以下示例使用调failover-shard用 MemoryDB 集群0001中的分片。 AWS CLI my-cluster

对于 Linux、macOS 或 Unix:

aws memorydb failover-shard \ --cluster-name my-cluster \ --shard-name 0001

对于 Windows:

aws memorydb failover-shard ^ --cluster-name my-cluster ^ --shard-name 0001

要跟踪故障转移的进度,请使用 AWS CLI describe-events操作。

返回以下 JSON 响应:

{ "Events": [ { "SourceName": "my-cluster", "SourceType": "cluster", "Message": "Failover to replica node my-cluster-0001-002 completed", "Date": "2021-08-22T12:39:37.568000-07:00" }, { "SourceName": "my-cluster", "SourceType": "cluster", "Message": "Starting failover for shard 0001", "Date": "2021-08-22T12:39:10.173000-07:00" } ] }

有关更多信息,请参阅下列内容:

 

使用 MemoryDB API 测试自动失效转移

以下示例调用 集群 memorydb00 中的分片 0003 上的 FailoverShard

例 测试自动失效转移
https://memory-db.us-east-1.amazonaws.com/ ?Action=FailoverShard &ShardName=0003 &ClusterName=memorydb00 &Version=2021-01-01 &SignatureVersion=4 &SignatureMethod=HmacSHA256 &Timestamp=20210801T192317Z &X-Amz-Credential=<credential>

要跟踪失效转移的进度,请使用 MemoryDB DescribeEvents API 操作。

有关更多信息,请参阅下列内容: