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

# MemoryDB 中的服务更新
<a name="service-updates"></a>

MemoryDB 会自动监控您的集群和节点实例集，以便在有服务更新可用时应用服务更新。通常，您可以设置预定义的维护时段，以便 MemoryDB 可以应用这些更新。然而，在某些情况下，您可能会发现这种方法过于僵化，并且可能限制您的业务流程。

使用 [MemoryDB 中的服务更新](#service-updates)，您可以控制更新的应用时间和内容。您还可以实时监控对所选 MemoryDB 集群执行这些更新的进度。

# 管理服务更新
<a name="managing-updates"></a>

MemoryDB 服务更新将定期发布。如果您有一个或多个符合这些服务更新的合格集群，则更新发布后，您将通过电子邮件、SNS、Personal Health Dashboard (PHD) 和亚马逊 CloudWatch 事件收到通知。更新也会显示在 MemoryDB 控制台的**服务更新**页面上。利用此控制面板，您可以查看 MemoryDB 实例集的所有服务更新及其状态。

您可以控制在自动更新开始前应用更新的时间。我们强烈建议您尽快应用任何**安全**更新类型的更新，以确保您的 MemoryDB 始终安装最新的安全补 up-to-date丁。

以下各节详细探索了这些选项。

**Topics**
+ [Amazon MemoryDB 托管维护和服务更新概述](#managing-updates-maintenance)

## Amazon MemoryDB 托管维护和服务更新概述
<a name="managing-updates-maintenance"></a>

我们会频繁升级 MemoryDB 实例集，无缝地将补丁和升级应用到实例上。我们通过以下两种方式之一进行：

1. 持续托管维护。

1. 服务更新。

这些维护和服务更新是应用那些增强安全性、可靠性和操作性能的升级所必需的。

持续托管维护会不定期在您的维护时段内直接进行，无需您采取任何行动。需要注意的是，维护时段对所有客户都是强制性的，您无法选择退出。我们强烈建议在这些已建立的维护时段内避免任何关键或重要的活动。此外，请注意，关键更新不能跳过，以确保系统的安全性和最佳性能。

服务更新使您能够灵活地自行应用它们。它们是有时间限制的，并且可能在截止日期过后被移到维护时段中由我们应用。

您可以通过在方便时尽早应用更新或通过替换节点来管理更新，因为在替换时会自动应用更新。如果在即将到来的维护时段之前更新已应用到所有节点，则在维护时段内将没有更新活动。

### 服务更新
<a name="managing-updates-maintenance.service"></a>

[MemoryDB 中的服务更新](service-updates.md) 使您能够自行决定应用某些服务更新。这些更新可以是以下类型：安全补丁或次要软件更新。这些更新有助于增强集群的安全性、可靠性和操作性能。

这些服务更新的价值在于您可以控制何时应用更新（例如，当有需要 MemoryDB 集群 24x7 可用性的重要业务事件时，您可以延迟应用服务更新）。

如果您有一个或多个符合这些服务更新的合格集群，则更新发布后，您将通过电子邮件、[Amazon SNS](mdbevents.sns.md)、[AWS Health 控制面板](https://docs.aws.amazon.com/health/latest/ug/getting-started-health-dashboard.html)和 A [mazon Events CloudWatch 事件](monitoring-cloudwatch.md)收到通知。更新也会显示在 MemoryDB 控制台的**服务更新**页面上。利用此控制面板，您可以查看 MemoryDB 实例集的所有服务更新及其状态。

您可以控制在自动更新开始前应用更新的时间。我们强烈建议您尽快应用任何安全更新类型的更新，以确保您的 MemoryDB 始终安装最新的安全补 up-to-date丁。

您的集群可能是不同服务更新的一部分。大多数更新不需要您单独应用它们。对您的集群应用一个更新将在适用的情况下将其他更新标记为已完成。如果状态没有自动更改为“已完成”，您可能需要分别对同一集群应用多个更新。

#### 服务更新的影响和停机时间
<a name="managing-updates-maintenance.service.impact"></a>

当您或 Amazon MemoryDB 对一个或多个 MemoryDB 集群应用服务更新时，更新在每个分片内一次仅应用于一个节点，直到所有选定集群都更新完毕。正在更新的节点将经历几秒钟的停机时间，而集群的其余部分将继续处理流量。
+ 集群配置不会发生任何变化。
+ 你会看到你的 CloudWatch 指标会有延迟，会尽快赶上。

**节点替换对我的应用程序有何影响？** - 对于 MemoryDB 节点，替换过程旨在保证持久性和可用性。对于单节点 MemoryDB 集群，MemoryDB 会动态启动一个副本，从我们的持久性组件恢复数据，然后失效转移到该副本。对于由多个节点组成的复制组，MemoryDB 会替换现有副本，并将数据从我们的持久性组件同步到新副本。仅当节点数多于 1 个时，MemoryDB 才具有多可用区特性。因此在此场景下，替换主节点会触发到读取副本的失效转移。计划内的节点替换在集群处理传入写入请求的同时完成。如果只有一个节点，MemoryDB 会替换主节点，然后从我们的持久性组件同步数据。在此期间，主节点不可用，会导致写入中断时间较长。

**为了确保顺利的替换体验并最大程度减少数据丢失，我应遵循哪些最佳实践？** - 在 MemoryDB 中，数据具有高持久性，即使在单节点部署中预计也不会发生数据丢失。但仍建议实施多可用区和备份策略，以在极不可能发生的故障事件中最大限度地减少丢失的可能性。为确保顺利的替换体验，我们会尝试一次仅替换同一集群中足够数量的节点，以保持集群稳定。您可以通过启用多可用区，在不同的可用区中配置主节点和读取副本。在这种情况下，当某个节点被替换时，主节点角色将失效转移到分片中的某个副本。该分片随后将开始处理流量，并且数据将从其持久性组件中恢复。如果您的配置每个分片仅包含一个主节点和一个副本，我们建议在修补前添加额外的副本。这将防止在修补过程中可用性降低。我们建议在传入写入流量较低的时段安排替换。

**我应该遵循哪些客户端配置最佳实践以最小化维护期间的应用程序中断？** - 在 MemoryDB 中，集群模式配置始终启用，这在托管或非托管操作期间提供了最佳可用性。副本节点的各个节点端点可用于所有读取操作。在 MemoryDB 中，集群中始终启用自动失效转移，这意味着主节点可能会更改。因此，应用程序应确认节点的角色并更新所有读取端点，以确保不会给主节点带来重大负载。同样，在维护时段内，避免使副本因读取请求而过载。实现此目的的一种方法是确保您至少有两个读取副本，以避免维护期间发生任何读取中断。

测试客户端应用程序以确认它们符合 Redis/Valkey 集群协议非常重要，并且请求可以正确地跨节点重定向。建议实施退避和重试策略，以避免在维护和替换活动期间使 MemoryDB 节点过载。

**重新安排** - 您可以通过更改[维护时段](maintenance-window.md)来推迟服务更新。仅当计划日期与集群的维护时段匹配时，计划更新才会应用到集群。一旦您更改了维护时段并且计划日期已过，服务更新将被重新安排到接下来几周内新指定的时段。您将在新日期到达前一周收到新通知。

安全 AWS 是一项共同的责任。我们强烈建议您尽早应用更新。

**选择退出服务更新** - 您可以通过验证“自动更新开始日期”属性的值来确定是否可以退出服务更新。如果服务更新的“自动更新开始日期”属性值已设置，MemoryDB 将在即将到来的维护时段为任何剩余的集群安排服务更新，并且无法选择退出。尽管如此，如果您在维护时段之前将服务更新应用到剩余集群，MemoryDB 将不会在维护时段期间重新应用该服务更新。有关更多信息，请参阅 [应用服务更新](applying-updates.md)。

**为什么服务更新不能由 MemoryDB 在维护时段直接应用？** - 请注意，服务更新的目的是让您灵活掌握应用时间。未参与 MemoryDB 支持的[合规性](memorydb-compliance.md)计划的集群可以选择不应用这些更新，或在全年以较低的频率应用它们。但建议应用更新以保持符合法规要求。这仅在未设置服务更新的“自动更新开始日期”属性值时才成立。有关更多信息，请参阅 [适用于 MemoryDB 的合规性验证](memorydb-compliance.md)。

**在维护时段应用的更新与服务更新有何不同？** - 通过持续托管维护应用的更新会直接在您的维护时段中安排，无需您采取任何行动。服务更新是有时间限制的，并让您可以通过“自动更新开始日期”来控制何时应用。如果届时仍未应用，MemoryDB 可能会在您的维护时段安排这些更新。

### 持续托管维护更新
<a name="managing-updates-maintenance.continuous"></a>

这些更新是强制性的，会直接在您的维护时段中应用，无需您采取任何行动。这些更新与服务更新提供的更新是分开的。

#### 持续维护的影响和停机时间
<a name="managing-updates-maintenance.continuous.impact"></a>

**节点替换需要多长时间？** - 替换通常会在 30 分钟内完成。在某些实例配置和流量模式下，替换可能需要更长时间。

**节点替换对我的应用程序有何影响？** - 持续托管维护更新的应用方式与“服务更新”相同，都是通过节点替换进行的。详情请参阅上文的服务更新影响和停机时间部分。

**我如何自行管理节点替换？** - 您还可以选择在计划节点替换时段之前的任意时间自已管理这些替换。如果您选择自行管理替换，可以根据您的使用案例采取各种操作。
+ [替换具有一个或多个分片的集群中的节点](nodes.nodereplacement.md)：您可以使用[备份和恢复](snapshots-restoring.md)，或者先扩展再缩减以[替换节点](cluster-resharding-online.md)。
+ [更改您的维护时段](maintenance-window.md)：此外，您可以更改集群的维护时段。要将维护时段更改为以后更方便的时间，您可以使用 [UpdateCluster API](clusters.modify.md)、[更新集群 CLI 或在 MemoryD](https://docs.aws.amazon.com/cli/latest/reference/memorydb/update-cluster.html) B 管理控制台中[单击](clusters.modify.md) “修改”。一旦您更改了维护时段，MemoryDB 将在新指定的时段内为您的节点安排维护。

   为了解其实际工作方式，假设当前是星期四 11/09 的 1500，下一个维护时段是星期五 11/10 的 1700。以下是 3 种场景：
  + 您将维护时段更改为星期五 1600（在当前日期时间之后，且在下一个计划维护时段之前）。节点将于 11 月 10 日星期五 16 点替换。
  + 您将维护时段更改为星期六 1600（在当前日期时间之后，且在下一个计划维护时段之后）。节点将于 11 月 11 日星期六 16 点替换。
  + 您将维护时段更改为星期三 1600（在本周内早于当前日期时间）。节点将于 11 月 15 日星期三 16 点替换。

  有关更多信息，请参阅 [管理维护](maintenance-window.md)。

  请注意，如果您为这些集群配置的维护时段相同，那么来自不同区域的不同集群中的节点可以同时被替换。

**我如何了解即将到来的计划替换？** -您应该在健康控制面板上收到 AWS 健康通知。您还可以使用 DescribeServiceUpdates API 查看不同服务升级的状态。请注意，我们会尽一切努力主动通知客户可预见的替换。但是，在发生不可预测故障等特殊情况下，可能会出现未事先通知的替换。

**我能否将计划维护更改为更合适的时间？** - 是的，您可以通过更改[维护时段](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeServiceUpdates.html)将计划维护推迟到更合适的时间。

**为什么要执行这些节点替换？** - 这些替换是向您的基础主机应用强制性软件更新所必需的。这些更新有助于增强我们的安全性、可靠性和操作性能。

**这些替换是否会同时影响我在多个可用区中的节点以及来自不同区域的集群？** - 替换可以在多个可用区或区域中并行运行，具体取决于集群的维护时段。

# 应用服务更新
<a name="applying-updates"></a>

您可以从服务更新具有 **available**（可用）状态起开始向实例集应用服务更新。服务更新为累积更新。换句话说，您尚未应用的任何更新都包含在您的最新更新中。

如果服务更新启用了自动更新，则可以选择在其可用时不执行任何操作。MemoryDB 将安排在**自动更新开始日期**之后的集群维护时段内应用更新。您将收到更新每个阶段的相关通知。

**注意**  
您只能应用那些具有 **available**（可用）或 **scheduled**（已安排）状态的服务更新。

有关查看并向适用的 MemoryDB 集群应用任何特定于服务的更新的更多信息，请参阅 [使用控制台应用服务更新](#applying-updates-console-APIReferenceconsole)。

当您的一个或多个 MemoryDB 集群有新的服务更新可用时，您可以使用 MemoryDB 控制台、API 或 AWS CLI 来应用更新。以下各节说明了可用于应用更新的选项。

## 使用控制台应用服务更新
<a name="applying-updates-console-APIReferenceconsole"></a>

要查看可用服务更新的列表和其他信息，请转到控制台中的 **Service Updates**（服务更新）页面。

1. 登录 AWS 管理控制台 并打开 MemoryDB 控制台，网址为。[https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/)

1. 在导航窗格中，选择 **Service Updates**（服务更新）。

在**服务更新详细信息**下，您可以查看以下内容：
+ **Service update name**（服务更新名称）：服务更新的唯一名称
+ **更新描述**：提供有关服务更新的详细信息
+ **自动更新开始日期**：如果设置了此属性，则在此日期之后，MemoryDB 将安排在适当维护时段中自动更新集群。您将提前收到确切的计划维护时段的通知，这可能不是**自动更新开始日期**之后的即时通知。您仍然可以随时对您的集群应用更新。如果未设置该属性，则服务更新将不会启用自动更新，且 MemoryDB 亦不会自动更新集群。

在 **Cluster update status**（集群更新状态）部分中，您可以查看尚未应用服务更新或最近才应用服务更新的集群的列表。您可以查看每个集群的以下内容：
+ **Cluster name**（集群名称）：集群的名称
+ **Nodes updated**（已更新节点）：特定集群中已更新或仍对特定服务更新可用的各个节点的比率。
+ **Update Type**（更新类型）：服务更新的类型，可以是 **security-update** 或 **engine-update**
+ **Status**（状态）：集群服务更新的状态，为下列状态之一：
  + *available*（可用）：更新适用于必需的集群。
  + *in-progres*（进行中）：正在对此集群应用更新。
  + *已计划*：已计划更新日期。
  + *完成*：已成功应用更新。完成状态的集群将在完成后显示 7 天。

  如果您选择任何或所有具有 **available**（可用）或 **scheduled**（已安排）状态的集群，然后选择 **Apply now**（立即应用），将开始对这些集群应用更新。

## 使用应用服务更新 AWS CLI
<a name="applying-updates-cli-redis"></a>

在收到服务更新可用的通知后，您可以使用 AWS CLI检测和应用这些更新：
+ 要检索可用的服务更新的描述，请运行以下命令：

  `aws memorydb describe-service-updates --status available`

  有关更多信息，请参阅 [describe-service-updates](https://docs.aws.amazon.com/cli/latest/reference/memorydb/describe-service-updates.html)。
+ 要对集群列表应用服务更新，请运行以下命令：

  `aws memorydb batch-update-cluster --service-update ServiceUpdateNameToApply=sample-service-update --cluster-names cluster-1 cluster2`

  有关更多信息，请参阅 [batch-update-cluster](https://docs.aws.amazon.com/cli/latest/reference/memorydb/batch-update-cluster.html)。