管理服务更新

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

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

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

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

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

Amazon MemoryDB 托管维护和服务更新概述

我们经常升级我们的 MemoryDB 队列，将补丁和升级无缝应用于实例。我们通过以下两种方式之一来做到这一点：

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

持续的托管维护会不时地直接在您的维护窗口中进行，而无需您采取任何行动。请务必注意，所有客户都必须使用维护窗口，而且您不能选择退出。我们强烈建议在既定的维护时段内避免进行任何关键或重要的活动。此外，请注意，为确保系统的安全性和最佳性能，不能跳过关键更新。

服务更新使您可以灵活地自行应用。它们是定时的，可能会被移至维护时段，以便在到期日过后由我们应用。

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

服务更新

MemoryDB 中的服务更新允许您自行决定应用某些服务更新。这些更新可以是以下类型：安全补丁或次要软件更新。这些更新有助于增强集群的安全性、可靠性和运行性能。

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

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

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

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

服务更新的影响和停机时间

当您或 Amazon MemoryDB 将服务更新应用于一个或多个 MemoryDB 集群时，在更新所有选定集群之前，该更新一次只能应用于每个分片中的一个节点。正在更新的节点将经历几秒钟的停机时间，而集群的其余部分将继续为流量提供服务。

节点更换对我的应用程序有何影响？ -对于 MemoryDB 节点，更换过程旨在保证耐用性和可用性。对于单节点 MemoryDB 集群，MemoryDB 会动态启动副本，从我们的耐久性组件中恢复数据，然后故障转移到该副本。对于由多个节点组成的复制组，MemoryDB 会替换现有副本，并将数据从我们的耐久性组件同步到新的副本。MemoryDB 只有在节点超过 1 个时才是多可用区，因此在这种情况下，替换主节点会触发向只读副本的故障转移。当集群处理传入的写入请求时，计划中的节点更换已完成。如果只有一个节点，MemoryDB 会替换主节点，然后同步来自我们耐久性组件的数据。在此期间，主节点不可用，从而导致写入中断时间更长。

为了获得顺畅的更换体验并最大限度地减少数据丢失，我应该遵循哪些最佳实践？ -在 MemoryDB 中，数据非常耐用，即使在单节点实现中也不会丢失数据。但是，建议实施多可用区和备份策略，以最大限度地减少在不太可能发生的故障时丢失的机会。为了获得流畅的替换体验，我们尝试一次替换同一集群中刚好足够多的节点，以保持集群的稳定。您可以通过启用多可用区在不同的可用区中配置主副本和只读副本。在这种情况下，当节点被替换时，主角色将故障转移到分片中的副本。该分片现在将为流量提供服务，并且数据将从其耐久性组件中恢复。如果您的配置仅包括每个分片一个主副本和一个副本，我们建议您在修补之前添加其他副本。这将防止在修补过程中降低可用性。我们建议在传入写入流量较低的时段安排更换。

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

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

重新安排-您可以通过更改维护时段来推迟服务更新。仅当预定日期与集群的维护时段相匹配时，计划更新才会应用于集群。更改维护时段并且计划日期已过后，服务更新将在接下来的几周内重新安排到新指定的时段。您将在新日期到来前一周收到新的通知。

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

选择@@ 退出服务更新-您可以通过验证 “自动更新开始日期” 属性的值来确定是否可以选择退出服务更新。如果设置了服务更新的 “自动更新开始日期” 属性的值，则 MemoryDB 将在即将到来的维护时段为所有剩余集群安排服务更新，并且无法选择退出。不过，如果您在维护时段之前将服务更新应用于其余集群，MemoryDB 不会在维护时段内重新应用服务更新。有关更多信息，请参阅 应用服务更新。

为什么 MemoryDB 不能在维护时段内直接应用服务更新？ -请注意，服务更新的目的是让您在何时应用服务更新的灵活性。未参与 MemoryDB 支持的合规计划的集群可以选择不应用这些更新，也可以选择全年以较低的频率应用这些更新。但是，建议应用更新以保持与法规的合规性。仅当服务更新的 “自动更新开始日期” 属性值不存在时，才会出现这种情况。有关更多信息，请参阅 适用于 MemoryDB 的合规性验证。

在维护时段中应用的更新与服务更新有何不同？ -通过持续托管维护应用的更新将直接安排在您的维护窗口中，无需您采取任何措施。服务更新是定时的，您可以在 “自动更新开始日期” 之前控制何时申请。如果届时仍未应用这些更新，MemoryDB 可能会在您的维护窗口中安排这些更新。

持续的托管维护更新

这些更新是强制性的，可以直接应用于您的维护窗口，无需您采取任何措施。这些更新与服务更新提供的更新是分开的。

持续的维护影响和停机时间

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

节点更换对我的应用程序有何影响？ -持续托管维护更新的应用方式与 “服务更新” 相同，即通过更换节点。有关详细信息，请参阅上面的 “服务更新影响和停机时间” 部分。

如何自己管理节点更换？ -您可以选择在预定的节点更换窗口之前随时自行管理这些替换。如果您选择自己管理替换，则可以根据自己的用例采取各种操作。

如何了解即将到来的计划换货？ -您应该在健康控制面板上收到 AWS 健康通知。您还可以使用 DescribeServiceUpdates API 查看不同服务升级的状态。请注意，我们会尽一切努力主动通知买家有关可预见的更换情况。但是，在诸如不可预测的故障之类的特殊情况下，可能会有未经通知的替换。

我能否在更合适的时间更改定期维护？ -可以，您可以通过更改维护时段将定期维护推迟到更合适的时间。

你为什么要替换这些节点？ -需要这些替换才能将强制性软件更新应用到底层主机。这些更新有助于增强我们的安全性、可靠性和运营性能。

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