本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
管理服务更新
MemoryDB 服务更新将定期发布。如果您有一个或多个符合这些服务更新的条件的集群，则在更新发布时，您将通过电子邮件、SNS、Personal Health Dashboard（PHD）和 Amazon CloudWatch Events 接收通知。更新也会显示在 MemoryDB 控制台的服务更新页面上。利用此控制面板，您可以查看 MemoryDB 实例集的所有服务更新及其状态。
您可以控制在自动更新开始前应用更新的时间。我们强烈建议，尽快应用 security-update 类型的任何更新以确保始终使用最新的安全修补程序来使 MemoryDB 保持最新。
以下各节详细探索了这些选项。
Amazon MemoryDB 托管维护和服务更新概述
我们会频繁升级 MemoryDB 实例集，无缝地将补丁和升级应用到实例上。我们通过以下两种方式之一进行：
持续托管维护。
服务更新。
这些维护和服务更新是应用那些增强安全性、可靠性和操作性能的升级所必需的。
持续托管维护会不定期在您的维护时段内直接进行，无需您采取任何行动。需要注意的是，维护时段对所有客户都是强制性的，您无法选择退出。我们强烈建议在这些已建立的维护时段内避免任何关键或重要的活动。此外，请注意，关键更新不能跳过，以确保系统的安全性和最佳性能。
服务更新使您能够灵活地自行应用它们。它们是有时间限制的，并且可能在截止日期过后被移到维护时段中由我们应用。
您可以通过在方便时尽早应用更新或通过替换节点来管理更新，因为在替换时会自动应用更新。如果在即将到来的维护时段之前更新已应用到所有节点，则在维护时段内将没有更新活动。
服务更新
MemoryDB 中的服务更新 使您能够自行决定应用某些服务更新。这些更新可以是以下类型：安全补丁或次要软件更新。这些更新有助于增强集群的安全性、可靠性和操作性能。
这些服务更新的价值在于您可以控制何时应用更新（例如，当有需要 MemoryDB 集群 24x7 可用性的重要业务事件时，您可以延迟应用服务更新）。
如果您有一个或多个符合条件的集群适用于这些服务更新，您会在更新发布时通过电子邮件、Amazon SNS、Amazon Health 仪表板和 Amazon CloudWatch Events 事件接收通知。更新也会显示在 MemoryDB 控制台的服务更新页面上。利用此控制面板，您可以查看 MemoryDB 实例集的所有服务更新及其状态。
您可以控制在自动更新开始前应用更新的时间。我们强烈建议，尽快应用 security-update 类型的任何更新以确保始终使用最新的安全修补程序来使 MemoryDB 保持最新。
您的集群可能是不同服务更新的一部分。大多数更新不需要您单独应用它们。对您的集群应用一个更新将在适用的情况下将其他更新标记为已完成。如果状态没有自动更改为“已完成”，您可能需要分别对同一集群应用多个更新。
服务更新的影响和停机时间
当您或 Amazon MemoryDB 对一个或多个 MemoryDB 集群应用服务更新时，更新在每个分片内一次仅应用于一个节点，直到所有选定集群都更新完毕。正在更新的节点将经历几秒钟的停机时间，而集群的其余部分将继续处理流量。
集群配置不会发生任何变化。
您将看到 CloudWatch 指标出现延迟，但会尽快赶上。
节点替换对我的应用程序有何影响？ - 对于 MemoryDB 节点，替换过程旨在保证持久性和可用性。对于单节点 MemoryDB 集群，MemoryDB 会动态启动一个副本，从我们的持久性组件恢复数据，然后失效转移到该副本。对于由多个节点组成的复制组，MemoryDB 会替换现有副本，并将数据从我们的持久性组件同步到新副本。仅当节点数多于 1 个时，MemoryDB 才具有多可用区特性。因此在此场景下，替换主节点会触发到读取副本的失效转移。计划内的节点替换在集群处理传入写入请求的同时完成。如果只有一个节点，MemoryDB 会替换主节点，然后从我们的持久性组件同步数据。在此期间，主节点不可用，会导致写入中断时间较长。
为了确保顺利的替换体验并最大程度减少数据丢失，我应遵循哪些最佳实践？ - 在 MemoryDB 中，数据具有高持久性，即使在单节点部署中预计也不会发生数据丢失。但仍建议实施多可用区和备份策略，以在极不可能发生的故障事件中最大限度地减少丢失的可能性。为确保顺利的替换体验，我们会尝试一次仅替换同一集群中足够数量的节点，以保持集群稳定。您可以通过启用多可用区，在不同的可用区中配置主节点和读取副本。在这种情况下，当某个节点被替换时，主节点角色将失效转移到分片中的某个副本。该分片随后将开始处理流量，并且数据将从其持久性组件中恢复。如果您的配置每个分片仅包含一个主节点和一个副本，我们建议在修补前添加额外的副本。这将防止在修补过程中可用性降低。我们建议在传入写入流量较低的时段安排替换。
我应该遵循哪些客户端配置最佳实践以最小化维护期间的应用程序中断？ - 在 MemoryDB 中，集群模式配置始终启用，这在托管或非托管操作期间提供了最佳可用性。副本节点的各个节点端点可用于所有读取操作。在 MemoryDB 中，集群中始终启用自动失效转移，这意味着主节点可能会更改。因此，应用程序应确认节点的角色并更新所有读取端点，以确保不会给主节点带来重大负载。同样，在维护时段内，避免使副本因读取请求而过载。实现此目的的一种方法是确保您至少有两个读取副本，以避免维护期间发生任何读取中断。
测试客户端应用程序以确认其符合 Redis/Valkey 集群协议，并且请求可以正确地在节点间重定向，这一点很重要。建议实施退避和重试策略，以避免在维护和替换活动期间使 MemoryDB 节点过载。
重新安排 - 您可以通过更改维护时段来推迟服务更新。仅当计划日期与集群的维护时段匹配时，计划更新才会应用到集群。一旦您更改了维护时段并且计划日期已过，服务更新将被重新安排到接下来几周内新指定的时段。您将在新日期到达前一周收到新通知。
Amazon 的安全是共同责任。我们强烈建议您尽早应用更新。
选择退出服务更新 - 您可以通过验证“自动更新开始日期”属性的值来确定是否可以退出服务更新。如果服务更新的“自动更新开始日期”属性值已设置，MemoryDB 将在即将到来的维护时段为任何剩余的集群安排服务更新，并且无法选择退出。尽管如此，如果您在维护时段之前将服务更新应用到剩余集群，MemoryDB 将不会在维护时段期间重新应用该服务更新。有关更多信息，请参阅 应用服务更新。
为什么服务更新不能由 MemoryDB 在维护时段直接应用？ - 请注意，服务更新的目的是让您灵活掌握应用时间。未参与 MemoryDB 支持的合规性计划的集群可以选择不应用这些更新，或在全年以较低的频率应用它们。但建议应用更新以保持符合法规要求。这仅在未设置服务更新的“自动更新开始日期”属性值时才成立。有关更多信息，请参阅 适用于 MemoryDB 的合规性验证。
在维护时段应用的更新与服务更新有何不同？ - 通过持续托管维护应用的更新会直接在您的维护时段中安排，无需您采取任何行动。服务更新是有时间限制的，并让您可以通过“自动更新开始日期”来控制何时应用。如果届时仍未应用，MemoryDB 可能会在您的维护时段安排这些更新。
持续托管维护更新
这些更新是强制性的，会直接在您的维护时段中应用，无需您采取任何行动。这些更新与服务更新提供的更新是分开的。
持续维护的影响和停机时间
节点替换需要多长时间？ - 替换通常会在 30 分钟内完成。在某些实例配置和流量模式下，替换可能需要更长时间。
节点替换对我的应用程序有何影响？ - 持续托管维护更新的应用方式与“服务更新”相同，都是通过节点替换进行的。详情请参阅上文的服务更新影响和停机时间部分。
我如何自行管理节点替换？ - 您还可以选择在计划节点替换时段之前的任意时间自已管理这些替换。如果您选择自行管理替换，可以根据您的使用案例采取各种操作。
替换具有一个或多个分片的集群中的节点：您可以使用备份和恢复，或者先扩展再缩减以替换节点。
更改您的维护时段：此外，您可以更改集群的维护时段。若要将您的维护时段更改为稍后更方便的时间，您可以使用 UpdateCluster API、update-cluster CLI 或在 MemoryDB 管理控制台中单击修改。一旦您更改了维护时段，MemoryDB 将在新指定的时段内为您的节点安排维护。
为了解其实际工作方式，假设当前是星期四 11/09 的 1500，下一个维护时段是星期五 11/10 的 1700。以下是 3 种场景：
您将维护时段更改为星期五 1600（在当前日期时间之后，且在下一个计划维护时段之前）。节点将于 11 月 10 日星期五 16 点替换。
您将维护时段更改为星期六 1600（在当前日期时间之后，且在下一个计划维护时段之后）。节点将于 11 月 11 日星期六 16 点替换。
您将维护时段更改为星期三 1600（在本周内早于当前日期时间）。节点将于 11 月 15 日星期三 16 点替换。
有关更多信息，请参阅 管理维护。
请注意，如果您为这些集群配置的维护时段相同，那么来自不同区域的不同集群中的节点可以同时被替换。
我如何了解即将到来的计划替换？ - 您应该在 Amazon health Dashboard 上收到健康通知。您也可以使用 DescribeServiceUpdates API 查找不同服务升级的状态。请注意，我们会尽一切努力主动通知客户可预见的替换。但是，在发生不可预测故障等特殊情况下，可能会出现未事先通知的替换。
我能否将计划维护更改为更合适的时间？ - 是的，您可以通过更改维护时段将计划维护推迟到更合适的时间。
为什么要执行这些节点替换？ - 这些替换是向您的基础主机应用强制性软件更新所必需的。这些更新有助于增强我们的安全性、可靠性和操作性能。
这些替换是否会同时影响我在多个可用区中的节点以及来自不同区域的集群？ - 替换可以在多个可用区或区域中并行运行，具体取决于集群的维护时段。