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

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

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

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

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

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

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

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

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

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

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

不会。Redis 集群将会继续处理流量，但会有几秒钟的停机时间。您选择要应用服务更新的一个或多个 Redis 集群后，Amazon ElastiCache 会一次将更新应用于一个节点，所有分片并行进行，直到所有选定集群更新完毕。

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

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

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

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

可以。但是，如果服务更新的“截止日期之后自动更新”属性的值为“是”，并且已超过“建议的应用截止日期”，ElastiCache 将为所有剩余集群安排下一个维护时段的服务更新。此外，如果在维护时段之前对剩余集群应用服务更新，ElastiCache 将不在维护时段内重新应用服务更新。

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

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

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

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

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

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

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

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

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

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

问：服务更新多久发布一次？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

对于 Redis 节点，替换过程旨在尽量保留现有数据，同时需要 Redis 复制成功。我们会尝试从同一集群中一次性替换刚好足够的节点，以确保该集群的稳定性。您可以将主副本和只读副本预置在不同的可用区内。这样，在替换某个节点时，将通过另一个可用区内的对等节点同步数据。对于单节点 Redis 集群，我们建议您为 Redis 提供足够的内存，如此处所述。对于具有多个节点的 Redis 复制组，我们还建议在传入写入流量较低的时段安排替换。
对于 Memcached 节点，将维护时段安排在传入写入流量较低的时段，对应用程序进行故障转移测试，并使用 ElastiCache 提供的“更智能”的客户端。数据丢失无法避免，因为 Memcached 的所有数据都存储在内存中。

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

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

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

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

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

• 更改维护时段。
• 使用备份和还原过程重新启动 Redis 实例。
• 如果 Redis 集群配置已禁用集群模式
  o 替换只读副本（禁用集群模式）– 手动替换 Redis 复制组中只读副本的过程。
  o 替换主节点（禁用集群模式）– 手动替换 Redis 复制组中主节点的过程。
  o 替换独立节点（禁用集群模式）– 替换独立 Redis 节点的两种不同过程。
• 如果 Redis 集群配置已启用集群模式
  o 将集群中的节点替换为一个或多个分片 – 您可以使用备份和还原，也可以先扩展再缩减来替换节点。

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

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

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

ElastiCache 会在计划替换您的节点之前向您发送电子邮件通知。您可以使用 ElastiCache 管理控制台的“缓存事件”部分或 describe-events API 来查看即将发生的 ElastiCache:NodeReplacementScheduled 事件。最后，您可以使用此处提供的信息在 Redis 中为此事件设置 Amazon SNS 通知。

要在 Memcached 中设置 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 分片集群，我们尽量不在同一分片中同时替换多个节点。此外，我们还尽量不在跨所有分片的集群中替换大多数主节点。
对于非分片集群，我们尽量在维护时段将节点替换的时间错开，以尽可能地保持集群的稳定性。

问：可以同时替换来自不同区域的不同集群中的节点吗？

可以。如果您为这些集群配置了相同的维护时段，则可以同时对这些节点进行替换。