本页介绍了 Memorystore for Redis Cluster 如何对集群执行维护。此外，还提供了信息和配置建议，您的客户端应用应了解这些信息和建议，以便利用 Memorystore for Redis Cluster 的零停机维护设计。这些建议适用于 高可用性集群和 没有副本的集群。不过，我们强烈建议您为所有生产用例配置高可用性。
Memorystore for Redis Cluster 会定期更新集群，以确保服务可靠、高效、安全且最新。这些更新称为“维护” 。维护由服务全代管式，旨在实现零停机影响。
维护通常分为以下几类：
- Memorystore 功能。如需启动某些功能，Memorystore 需要进行维护更新。
- 操作系统补丁程序。我们会持续监控操作系统中新发现的安全漏洞。发现漏洞后，我们会修补操作系统，以保护您免受新风险的影响。
- 数据库补丁程序。维护可以包括 Redis 更新，以提升集群的安全性、性能和可靠性特征，使其超出 Redis 提供的范围。
配置客户端应用
如需在维护期间尽可能获得最佳性能和可用性，请按以下步骤配置客户端应用：
- 按照 Redis 客户端最佳实践中的指南使用和配置 OSS Redis 集群客户端，确保任何计划维护都不会影响您的客户端 应用。我们建议的客户端配置可以通过定期内联拓扑刷新和后台连接轮替来避免连接重置。
- 在主节点和副本节点上运行代表性工作负载时，使用一系列更新操作（例如缩容或扩容、副本计数更改）测试客户端应用，并监控对客户端的影响。这些更新会测试客户端上的内联拓扑刷新逻辑、完全同步影响、新节点发现和现有节点移除功能。测试有助于确保客户端配置正确，以避免对应用产生任何负面影响。
计划性维护
Memorystore for Redis Cluster 利用渐进式部署和先创建后销毁生命周期策略，可避免维护造成任何的停机影响。 通过将 Redis 协议的请求重定向功能与以下 Memorystore 机制结合使用，可以实现零停机维护：
- 协调的故障切换，不会丢失任何数据。
- 平稳移除节点，使客户端能够及时了解集群拓扑更新，而不会对可用性产生任何影响。
- 集群的 Private Service Connect 端点不受维护的影响。如需详细了解这些端点，请参阅集群端点。
以下各部分中描述的服务行为仅适用于计划性维护。如需了解 硬件故障等意外事件的影响，请参阅意外故障切换期间的客户端行为。
渐进式部署策略
Memorystore for Redis Cluster 维护部署以逐步增加的范围执行，并以允许尽早检测到故障的速率执行，以便减轻影响并建立稳定性信心。在服务规模上，Memorystore 集群舰队中集成了烘焙时间（在将更新视为成功并继续之前应用和监控更新的时间）。此外，烘焙时间还集成在集群内，跨区域中的可用区（多个容错网域），以减少影响范围（如果有）。
对于配置为高可用性的集群， 在任何给定时间最多更新一个容错网域/可用区，以确保 集群分片（包括主节点和副本）在整个更新过程中具有高可用性 。此外，在任何给定时间仅更新少量 Redis 节点。更新使用先创建后销毁生命周期机制，以最大限度地提高集群稳定性。此策略在更新具有许多分片的集群时提供最大的优势。在任何给定时间仅将更新应用于整体用户键空间的一小部分，可最大限度地提高数据可用性。
先创建后销毁生命周期策略
Redis 集群有多个分片。每个分片都有一个主节点和零个或多个副本节点。Memorystore 使用以下流程更新分片中的任何现有主节点或副本 Redis 节点：
- Memorystore for Redis Cluster 首先向分片添加一个完全新的副本，其中包含最新的软件更新。Memorystore 会创建一个全新的节点，而不是更新现有节点，以确保在发生意外的启动失败时保留预配的容量。
- 如果要更新的分片中的节点是主节点，则会先 使用协调的故障切换将其转换为副本，然后再移除。
- 接下来，Memorystore 会移除使用较早软件的副本。
- 对于集群中的每个节点，此过程都会重复执行。
与就地更新的典型滚动部署相比，先创建后销毁策略有助于保留集群的预配容量，但会导致客户端应用出现可用性中断（有时还会丢失数据）。对于没有副本的分片，Memorystore for Redis Cluster 仍会先预配新副本，协调故障切换，最后替换分片的现有主节点。
第 1 步：添加 Redis 副本
先创建后销毁机制的第一步是添加一个包含最新软件的副本节点，并使用完全同步 OSS Redis 机制将数据从主节点复制到副本节点。这是通过派生子进程并利用无磁盘复制来启动副本完成的。 Memorystore for Redis Cluster 支持无磁盘复制。除非您启用 持久性，否则 Memorystore for Redis Cluster 在复制期间不会使用磁盘 。
您可以预配更多分片，以减少节点内的键空间大小，从而充分利用集群的横向扩缩架构。每个节点的数据集越小，有助于减少完全同步操作的 fork 延迟影响。它还可以加快跨节点复制数据的速度。
第 2 步：协调的主节点故障切换
如果需要更新的 Redis 节点是主节点， Memorystore 会先对新添加的 副本节点执行协调的故障切换，然后再继续执行节点移除。在协调的故障切换期间，客户端和 Redis 节点会协同工作，并使用以下策略来避免应用停机：
- 传入的客户端请求在主节点上暂时被屏蔽，提供一个窗口以确保现有副本与主节点 100% 同步。
- 副本完成选举过程以接管主节点角色。
- 之前的主节点（现在是副本）会取消屏蔽现有请求，并使用 OSS Redis 集群协议将其重定向到新选出的主节点。发送到之前副本节点的任何新请求都会继续重定向到新的主节点。
- 与 Redis 集群兼容的客户端会刷新其内存中的拓扑。它会了解新主端点的地址，不再需要重定向。
协调的故障切换通常需要数十毫秒。不过，集群总大小可能会增加故障切换延迟时间。待刷新到副本的传输中数据也是如此。集群大小可能会影响主节点之间的收敛，进而影响有关选举新主节点的决策。
第 3 步：移除 Redis 副本
先创建后销毁机制的最后一步是移除使用较早软件的副本节点。突然移除节点会对客户端应用产生影响，因为客户端会缓存端点信息和集群拓扑。Memorystore for Redis Cluster 已将 Redis 副本的移除设计为平稳移除，以便客户端应用在遇到硬节点关停之前刷新其拓扑。拓扑经过自定义，使客户端能够了解新副本。拓扑还会忘记将被移除的副本，然后再将其移除。
运行较早软件的副本节点会保留一段特定的排空时间（通常为几分钟），在此期间，它会开始将传入的读取请求重定向到其分片的主节点。它允许集群客户端刷新集群拓扑并了解新的副本端点。如果客户端在排空时间后尝试访问已移除的节点，则尝试会失败，这反过来会触发集群客户端上的集群拓扑刷新，以便客户端了解副本更改。集群拓扑的新刷新不会看到将被移除的副本节点。
维护设置
借助 Memorystore，您可以自定义维护时间表，以满足应用的需求并最大限度地减少中断。 您可以通过为集群配置维护窗口来实现此目的。
维护窗口是针对每个 Memorystore 集群设置的，并允许以下配置选项：
- 星期几。指定进行维护的日期。
- 起始小时。维护开始的小时。
维护窗口的时长为 1 小时。请注意，在某些情况下，维护可能会超出您选择的窗口。
为集群配置维护窗口后，Memorystore for Redis Cluster 会根据您为维护窗口设置的偏好设置，在未来安排自动维护。
默认维护窗口
如果您未设置维护窗口，Memorystore 会根据集群的时区在以下时间窗口之一更新集群：
工作日时段（星期一至星期五）。晚上 10 点至早上 6 点
周末时段。星期五晚上 10 点至星期一早上 6 点
维护示例
作为在零售商处管理购物车服务的开发者，您有责任监督包含集群的生产环境。为确保在维护期间获得最佳性能，您希望在集群流量最小时（通常在星期日零点左右）安排维护。
在这种情况下，您可以将生产集群的维护窗口设置为：
- 星期几。星期日。
- 起始小时。凌晨 1 点。
即将进行的维护通知
为确保您及时了解集群的维护事件，您可以设置在安排维护前至少一周收到有关即将进行的维护的电子邮件通知。这些通知的主题行将为"Upcoming maintenance for your Cloud Memorystore instance [your-cluster-name]"。
当集群开始维护时，系统也会发送通知。电子邮件的主题行将为"Maintenance
is undergoing for your Cloud Memorystore instance [your-cluster-name]"。
维护完成后，系统会发送完成通知。电子邮件标题为"Completed Maintenance
for your Cloud Memorystore instance [your-cluster-name]"。
如果 Memorystore 重新安排维护，您会收到一封电子邮件，通知您维护已取消。此电子邮件的主题行
将为 "Canceled maintenance for your Cloud Memorystore instance [your-cluster-name]"。
您必须选择接收这些维护通知。如需注册接收维护通知，请按以下步骤操作：
如需接收来自 Memorystore 的维护通知，请确保在为集群安排维护更新前至少一周完成这些步骤。如果您未能完成这些步骤，Memorystore for Redis Cluster 就没有足够的时间通知您即将进行的维护。
Memorystore for Redis Cluster 会向与您的 Google 账号关联的电子邮件地址发送通知。您无法配置自定义邮箱别名（例如团队邮箱别名）。目前，我们不支持向其他电子邮件地址发送通知。
订阅维护通知后，您会收到指定项目中所有安排了维护的 Memorystore 集群的提醒。如果您已订阅，则会收到每个集群的单独通知。
如需了解如何查找计划维护，请参阅查找计划维护。
重新安排维护
如果您的集群配置了维护窗口，本部分将提供有关如何重新安排维护的指南。例如，如果计划在当前维护窗口期间启动新服务，您可能需要将维护窗口推迟到启动后几天内。
您可以在最初安排的时间后的 14 天内重新安排维护。 重新安排维护时，请选择以下选项之一：
- 立即更新：您可以立即将更新应用于集群，而不是等到安排的维护窗口。
- 自定义日期和时间：选择 最初安排的维护时间后的14 天内的任何时间。
重新安排维护时，需要遵循以下限制：
- 如果当前时间距离目前安排的维护不到一个小时，则无法重新安排维护。
- 成功重新安排后，系统会发送一封电子邮件，确认取消之前的维护，并发送一封新的即将进行的维护通知，其中包含更新后的时间表。
如需了解如何重新安排维护，请参阅重新安排维护。
常见问题解答
本部分包含有关 Memorystore for Redis Cluster 维护的常见问题解答 (FAQ)。
如何知道何时为集群安排了维护？
如需了解何时为集群安排了维护，我们建议您订阅通知并配置维护窗口。您还可以
手动检查集群，查看响应中是否显示
maintenanceSchedule 参数。
Memorystore for Redis Cluster 何时通知您即将进行的维护？
如果您订阅了维护通知并设置了维护窗口，则 Memorystore for Redis Cluster 会在维护事件发生前至少一周通过电子邮件通知您。
您可以将维护推迟多长时间？
为集群安排维护后，您可以立即开始更新集群，也可以将更新从最初安排的维护日期和时间开始推迟最多两周。
例如，如果您将维护安排在 10 月 11 日晚上 11 点 15 分，则可以将维护推迟到 10 月 25 日晚上 11 点 15 分。如果您不采取任何操作，则维护将在安排的日期和时间运行。
如需了解详情，请参阅重新安排维护。
哪些最佳实践可以带来流畅的维护更新体验？
为确保获得流畅的维护更新体验，我们建议您执行以下操作：
- 按照说明配置客户端应用。
- 将维护窗口 设置为集群流量最小时的日期和时间（例如 星期日零点）。
- 开启维护通知。这样一来，Memorystore for Redis Cluster 就会在为集群安排维护更新前至少七天通过电子邮件通知您。
- 如果您的应用使用时间没有低影响或无影响的小时，请使用服务默认的渐进式发布。此默认值包含维护更新的最佳实践。如需了解详情，请参阅计划性维护。
我们建议您何时立即应用维护更新？
您可以立即在测试集群上应用维护更新，以了解更新对应用的影响。您可以观察此更新产生的影响。如果更新存在问题，您可以推迟生产集群的维护，直到解决问题为止。
如果当前日期和时间适合您的集群，并且您预计将来集群负载会很高，则可以立即运行维护更新。
维护更新是否始终在维护窗口内完成？
Memorystore for Redis Cluster 会在您指定的维护期内开始维护更新。Memorystore for Redis Cluster 通常会在窗口内完成更新，但并非总是如此。
您可以先停止对某些集群进行维护或安排维护吗？
您无法选择停止对集群进行维护，也无法控制集群的维护顺序。不过，在收到初始维护通知后，您可以 重新安排维护，使其最多推迟 两周。
后续步骤
- 查看管理集群维护窗口所需的权限 。