Amazon ElastiCache 托管维护和服务更新帮助页面

问：Amazon ElastiCache 中的服务更新是什么？

服务更新是 Amazon ElastiCache 中的一项功能，允许您自行决定应用特定服务更新。这些更新可以是以下类型：安全补丁或较小的软件更新。这些更新有助于增强您的集群的安全性、可靠性和操作性能。

这些服务更新的价值在于，您可以控制何时应用更新（例如，您可以在开展重要业务活动，需要 ElastiCache 集群全天候可用时，延迟应用服务更新）。

有关每个服务更新的详细信息，请参阅“更新说明”属性的值。 

问：我如何得知有 ElastiCache 服务更新可用？

当适用于您的 Memcached 或 Redis 集群的服务更新可用时，我们将通过多种渠道通知您，包括 Amazon ElastiCache 控制台、电子邮件、Amazon Simple Notification Service（SNS）、AWS Personal Health Dashboard 和 Amazon CloudWatch Events。

问：在维护时段中应用的更新与通过服务更新应用的更新有哪些区别？

通过我们的持续托管维护提供的更新与服务更新提供的更新是相互独立的。通过持续托管维护应用的更新直接在您的维护时段中进行安排，无需您执行任何操作。服务更新具有时间限制，您可以通过“建议的应用截止日期”来控制希望什么时候应用更新。如果到了建议的应用截止日期仍未应用更新，ElastiCache 可能会在您的维护时段中安排这些更新。

问：我如何确定是否该应用可用的服务更新？

如果您的 ElastiCache Redis 集群参加了 HIPAA、PCI 或 FedRAMP 合规性计划，您必须在其“建议的应用截止日期”之前应用服务更新才能保持合规。有关更多信息，请参阅用于实现合规性的自助安全更新。

对于其他集群，我们建议您根据您的业务节奏应用服务更新。即使您无法在“建议的应用截止日期”之前应用服务更新，您仍能在“更新到期日期”之前应用。但是，“更新到期日期”可能会因新更新的可用性而随时发生变化。

问：对 ElastiCache for Redis 集群应用服务更新会带来哪些影响？ 我会丢失数据或无法连接我的集群吗？

当您或 Amazon ElastiCache 将某个服务更新应用于一个或多个 Redis 集群时，更新在每个分片内一次只应用于一个节点，直到所有选择的集群更新完毕。正在更新的节点将经历几秒钟的停机时间，而 Redis 集群的其余部分将继续提供流量。

• 集群配置不会发生变化。
• 尽管 CloudWatch 指标会尽快跟上更新进度，但仍存在延迟。

服务更新的应用方式与“持续托管式维护更新”相同，都是通过节点替换。请参阅本页上的持续托管式维护更新部分中的以下问题，以了解有关如何应用更新以及如何准备应用程序以最小化影响的详细信息。

• 问：节点替换对应用程序有何影响？
  
• 为获得顺利的替换体验并最大限度减少数据丢失，我应该遵循哪些最佳实践？
• 为最大限度地减少维护期间的应用程序中断，我应该遵循哪些有关客户端配置的最佳实践？
  

问：对 ElastiCache for Memcached 集群应用更新时，会出现停机吗？

会。节点会被新的空节点取代。缓存内容将不复存在，将重新开始缓存。

问：我可以选择退出服务更新吗？

您可以通过验证“截止日期后自动更新”属性的值来确定是否可以选择退出服务更新。如果服务更新“截止日期后自动更新”属性的值为 “否”，则可以选择退出此服务更新。但是，如果服务更新“截止日期之后自动更新”属性的值为“是”，并且已超过建议的“应用截止日期”，ElastiCache 将自动在即将到来的维护时段内将服务更新安排到所有剩余集群。此自动服务更新将安排在“更新到期日期”之前，您将在更新前一周收到包含安排时间的通知。即使可以选择退出，我们也强烈建议您应用安全更新。  如果选择在维护时段之前对剩余集群应用服务更新，ElastiCache 将不在维护时段内重新应用服务更新。

问：为什么 ElastiCache 不能在维护时段内直接应用服务更新？

服务更新的目的是让您可以灵活决定何时应用更新。未参加 ElastiCache 支持的合规性计划的集群可以选择不应用这些更新，或者在一年中以较低的频率应用更新。仅当服务更新的“截止日期之后自动更新”属性值为“否”时，才能这样做。有关更多信息，请参阅问题“我可以选择退出服务更新吗？”。

问：我可以使用服务更新来选择退出 Amazon ElastiCache 服务维护，并自行应用可用的更新吗？

不可以。服务更新与 Amazon ElastiCache 在您的集群维护时段内直接应用的持续托管维护更新是相互独立的。

问：所有服务更新属性的列表位于哪里？

属性及其描述的完整列表位于应用自助服务更新内。

问：所有服务更新都适用相同的时间表吗？

为了帮助确定多久后应用可用的服务更新，您可以参考“严重性”服务更新属性，该属性具有以下值（按优先级顺序）：

1. 关键：建议立即应用（在 14 天或更短时间内）
2. 重要：建议在业务流程允许的情况下尽快应用（在 30 天或更短时间内）
3. 中等：建议在 60 天或更短时间内应用
4. 较低：建议在 90 天或更短时间内应用

有关更多详细信息，请参阅我们的公开文档 — 应用更新。

问：服务更新多长时间发布一次？

发布计划取决于服务更新的重要性程度。

问：什么是“满足服务更新 SLA”属性？

此属性反应您的集群是否已在“建议的应用截止日期”之前更新。如果服务更新是在“建议的应用截止日期”之后应用的，属性“满足服务更新 SLA”将设置为“否”。

此信息与参加了 HIPAA、PCI 和 FedRAMP 合规性计划的 Amazon ElastiCache Redis 集群密切相关。有关更多信息，请参阅用于实现合规性的自助安全更新。

问：如果我错过一个或多个服务更新，以后还能应用这些更新吗？

可以。除非在服务更新“描述”属性中另有说明，否则，服务更新将一直累积：如果您未在“更新到期日期”之前应用更新，更新将会纳入下一次服务更新。类型为“安全性”的服务更新属于此类累积型更新。

问：我可以选择对 ElastiCache 集群中的特定节点应用服务更新吗？

不可以。服务更新在集群级别应用。如果您取消正在进行的更新，集群中的某些节点可能已更新，而有些节点却未更新。在这种情况下，集群会继续显示在要应用服务更新的集群列表中。此集群将继续正常运行。

问：为什么即使我没有应用服务更新，我的 ElastiCache 集群的一个或多个节点的更新状态也从“未应用”变成了“完成”？

如果发生以下两种情况，会出现此问题：

(a) 如果您没有应用可选的服务更新，而且此更新现处于“已到期”状态。因此，参加了合规性计划的集群必须始终应用所有服务更新。
(b) 如果您的节点由于任何其他原因被取代，例如，计划维护事件或节点故障转移，Amazon ElastiCache 将预置包含最新服务更新的新节点。

在这两种情况下，集群将继续正常运行。

问：如果我想对节点应用已过期的服务更新呢？ 需要等到下一次服务更新吗？

新节点中包含所有适用的服务更新，因此，您可以手动替换尚未更新到最新更新的现有节点。

问：服务更新是特定于引擎的吗？

是的。服务更新可以仅适用于 Redis，仅适用于 Memcached，也可以同时适用于 Redis 和 Memcached。您可以查找“引擎”和“引擎版本”服务更新属性，以确定每项更新适用的范围。

问：我能否将安排好的服务更新改在更合适的时间？ 如果我更改维护时段，安排好的更新会发生什么？

是的，您可以通过更改维护时段来延迟服务更新。如果预定日期与集群的维护时段相符，安排好的更新将只会应用于集群。一旦您更改了维护时段并且已经过了预定日期，服务更新将在接下来的几周内重新安排到新指定的时段。您将在离新日期还有一周时收到新通知。

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

问：为什么我会为同一个集群收到多个更新通知？ 我是否需要应用全部更新？

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

问：如何在“建议的应用截止日期”后预定和应用服务更新？

如果“在到期日期后自动更新”属性的值为“是”，则 ElastiCache 将在“建议的应用截止日期”后安排剩余集群的服务更新。 更新将在集群的维护时段预定，您将会在应用更新前的预定日期提前一星期收到新通知。

安排好的服务更新将以与“持续托管式维护更新”相同的方式应用于集群。 请参阅以下部分，以详细了解如何应用更新、如何更改安排好的更新以及如何为安排好的更新准备应用程序以将影响降到最低。

问：如果服务更新无法在一个维护时段内应用于整个集群，将会发生什么？

为了维护集群稳定性，ElastiCache 一次仅会在一个分片内将更新应用于一个节点。如果服务更新无法在一个维护时段内应用于整个集群，将会安排该更新在后续时段内继续。您将会在下一个预定日期接收新通知，并且可以相应进行准备。

问：我是否可以回滚服务更新？

客户无法在服务更新开始后对其进行回滚。如果您在应用服务更新后发现问题，请联系 AWS Support 团队。

问：什么是持续托管维护更新？

这些更新是强制性更新，直接在维护时段内应用，不需要您执行任何操作。这些更新与服务更新提供的更新是相互独立的。

问：节点替换需要多长时间？

替换通常在几秒钟内即可完成。对于某些实例配置和流量模式，替换可能需要较长时间。例如，Redis 主节点可能没有足够的可用内存，因此可能会出现较高的写入流量。当某个空副本与该主节点同步时，主节点会尝试在处理传入的写入流量的同时进行副本同步，因此可能导致内存不足。在这种情况下，主节点会断开与副本的连接，并重新启动同步进程。可能需要经过几次尝试，副本才能同步成功。如果传入的写入流量始终较高，副本也有可能一直无法同步。

Memcached 节点不需要同步，因此无论节点大小如何，它们都可更快地完成替换。

问：节点替换对应用程序有何影响？

对于 Redis 节点，替换过程旨在尽最大努力保留您的现有数据，同时需要 Redis 复制成功。对于单一节点 Redis 集群，ElastiCache 会动态启动一个副本并复制数据，然后故障转移至该副本。对于由多个节点组成的复制组，ElastiCache 会替换现有副本，并将主副本中的数据同步至新副本。如果启用了带自动失效转移的多可用区，替换主节点将会触发失效转移至只读副本的操作。对于设置为使用 Redis 集群客户端的 Redis 集群配置和启用了自动失效转移的非集群配置，计划的节点替换将在集群为传入的写入请求提供服务时完成。如果禁用了多可用区，ElastiCache 将替换主副本，然后同步只读副本中的数据。在此期间，主节点不可用，将导致更长时间的写入中断。

对于 Memcached 节点，替换过程中会产生空的新节点，并会终止当前节点。在切换期间，新节点将在短期内不可用。完成切换后，您的应用程序可能会出现性能下降的情况，而空的新节点将通过缓存数据进行填充。

问：为获得顺利的替换体验并最大限度减少数据丢失，我应该遵循哪些最佳实践？

对于 Redis 节点，替换过程旨在尽最大努力保留您的现有数据，同时需要 Redis 复制成功。我们会尝试从同一集群中一次性替换刚好足够的节点，以确保该集群的稳定性。您可以将主副本和只读副本预置在不同的可用区内。这样，在替换某个节点时，系统将从另一个可用区内的对等节点同步数据。我们还建议您将 Redis 引擎版本升级到 5.0.6 或更高，因为这些引擎版本改善了稳定性，让您的集群在启用了故障转移的情况下，能够在修补活动期间持续地为传入的写入请求服务。最后，如果您的配置中仅包含一个主节点且每个分区只有单个副本，我们建议在修补之前添加其他的副本。这样将可防止可用性降低以及修补过程中产生风险。对于单节点 Redis 集群，我们建议您为 Redis 提供足够的内存，如此处所述。对于含有多个节点的 Redis 复制组，我们还建议您将替换安排在传入写入流量较低的时段进行。

对于 Memcached 节点，应将维护时段安排在传入写入流量较低的时间，对应用程序进行故障转移测试，并使用 ElastiCache 提供的“更智能”的客户端。数据丢失无法避免，因为 Memcached 的所有数据都存储在内存中。

问：为最大限度地减少维护期间的应用程序中断，我应该遵循哪些有关客户端配置的最佳实践？

对于 Redis，集群模式配置在托管或非托管操作期间具有最佳可用性，并且始终建议使用集群模式支持的客户端，它可连接至集群发现终端节点。对于禁用的集群模式，建议始终使用主终端节点进行所有写入操作。副本节点的单个节点终端节点可用于所有读取操作。如果集群中启用了自动故障转移，主节点可能会发生变化，因此，应用程序应确认节点的角色，并更新所有读取终端节点，确保不会对主数据造成重大负载。禁用自动故障转移后，节点的角色不会发生变化，但是与启用自动故障转移的集群相比，托管或非托管操作中的停机时间更长。避免将读取请求仅定向到只读副本。如果您配置客户端为将读取请求仅定向到只读副本，请确保您至少有两个只读副本，这样可以避免维护期间出现任何读取中断。

问：我如何自行管理节点替换？

我们建议您允许 ElastiCache 在计划维护时段管理您的节点替换。创建 ElastiCache 集群时，您可以通过每周维护时段指定首选替换时间。之后您可以使用 ModifyCacheCluster API 或在 ElastiCache 管理控制台中单击“修改”，将您的维护时段改为更方便的时段。

如果您选择自行管理替换，可以根据您的使用案例和集群配置采取各种措施：

• 更改维护时段。
• 利用备份和还原流程重新启动您的 Redis 实例。
• 如果您的 Redis 集群配置已禁用集群模式

o 替换只读副本（禁用集群模式）– 手动替换 Redis 复制组中只读副本的过程。
o 替换主节点（禁用集群模式）– 手动替换 Redis 复制组中主节点的过程。
o 替换独立节点（禁用集群模式）– 替换独立 Redis 节点的两种不同过程。

• 如果您的 Redis 集群配置已启用集群模式

o 将集群中的节点替换为一个或多个分区 – 您可以利用备份和还原，也可以先扩展再缩减来替换节点。

有关所有这些选项的更多说明，请参阅您在已计划替换节点时可以采取的操作页面。

对于 Memcached，您只需删除集群再重新创建即可。替换后，您的实例不再拥有与之相关联的计划事件。

问：我如何了解即将进行的计划替换？

要接收同时，您可以为重大事件设置 Amazon SNS 通知，例如计划的替换事件。可以使用 ElastiCache 管理控制台的 Events（事件）部分或 describe-events API 来查看即将到来的 ElastiCache:NodeReplacementScheduled 事件，以实现此操作。

要设置 SNS 通知，请使用此处提供的信息。

问：我能否将安排好的维护改在更合适的时间？

能，您可以更改集群的维护时段。您可以使用 API（ModifyCacheCluster 或 ModifyReplicationGroup）或在 ElastiCache 管理控制台中单击“修改”，将维护时段改为日后某个更方便的时间。

如果您更改了维护时段，ElastiCache 服务将在新指定的时段安排节点进行维护。请参阅下文，查看有关这些更改如何生效的示例。

例如，

假设当前是 11 月 9 日星期四 15 点，下一个维护时段是 11 月 10 日星期五 17 点。下面是 3 种情况及其结果：

• 您将维护时段更改为星期五 16 点（在当前日期时间后且在下一个计划维护时段前）。节点将于 11 月 10 日星期五 16 点替换。
• 您将维护时段更改为星期六 16 点（在当前日期时间后且在下一个计划维护时段后）。节点将于 11 月 11 日星期六 16 点替换。
• 您将维护时段更改为星期三 16 点（在当前日期时间所在周早期）。节点将于 11 月 15 日星期三 16 点替换。

问：为什么要进行这些节点替换？

只有在进行这些替换后，才能将强制性的软件更新应用到底层主机。此类更新有助于增强安全性、可靠性和操作性能。

问：这类替换是否会同时影响我在多个可用区内的节点？

我们可以根据集群配置在同一集群中替换多个节点，同时确保集群的稳定性。对于 Redis 分区式集群，我们尽量不在同一分区中同时替换多个节点。此外，我们还尽量不在跨所有分区的集群中替换大多数主节点。
对于非分片式集群，我们会在维护时段将节点替换的时间错开，以尽可能地保持集群的稳定性。

问：来自不同区域的不同集群中的节点能否同时进行替换？

可以。这些节点可以同时进行替换，前提是您为这些集群配置了相同的维护时段。