本页面介绍了 Memorystore for Redis Cluster 如何对集群执行维护。此外，它还提供了客户端应用应了解的信息和配置建议，以便充分利用 Memorystore for Redis Cluster 的零停机维护设计。这些建议同时适用于高可用性集群和无副本集群。不过，我们强烈建议您为所有生产用例采用高可用性配置。
Memorystore for Redis Cluster 会定期更新集群，以确保服务可靠、高效、安全且处于最新状态。这些更新称为维护。维护工作完全由服务全托管式管理，旨在实现零停机时间影响。
维护通常分为以下几类：
- Memorystore 功能。如需发布某些功能，Memorystore 需要进行维护更新。
- 操作系统补丁程序。我们会持续监控操作系统中新发现的安全漏洞。发现漏洞后，我们会修补操作系统，以防范新风险。
- 数据库补丁。维护可能包括 Redis 更新，以提高集群的安全、性能和可靠性特性，这些特性超出了 Redis 提供的特性。
Memorystore for Redis Cluster 不会针对每个维护版本自动更新集群。为了确定安排全面维护的最佳时间， Google Cloud 会定期评估可用更新。如果您需要尽快获取特定维护版本，则可以在有可用更新后使用自助维护。如需详细了解维护版本（包括维护版本号和详细信息），请参阅 Memorystore for Redis Cluster 维护变更日志。
配置客户端应用
如需配置客户端应用，使其在维护期间尽可能实现最佳性能和可用性，请按照以下步骤操作：
- 根据 Redis 客户端最佳实践中的指导使用和配置 OSS Redis 集群客户端，以确保任何计划内维护都不会影响您的客户端应用。我们推荐的客户端配置可以通过定期内嵌拓扑刷新和后台连接轮替来避免连接重置。
- 在主节点和副本节点上运行代表性工作负载时，通过一系列更新操作（例如扩缩、副本数量更改）测试客户端应用，并监控对客户端的影响。这些更新会测试客户端上的内嵌拓扑刷新逻辑、完整同步影响、新节点发现和现有节点移除功能。测试有助于确保客户端配置正确，从而避免对您的应用产生任何负面影响。
计划性维护
Memorystore for Redis Cluster 利用渐进式部署和先创建后销毁生命周期策略，可避免维护造成任何的停机影响。零停机时间维护是通过将 Redis 协议的请求重定向功能与以下 Memorystore 机制结合使用来实现的：
- 协调故障切换，不会丢失任何数据。
- 正常移除节点，使客户端能够跟上集群拓扑更新，而不会影响可用性。
- 集群的 Private Service Connect 端点不受维护影响。如需详细了解这些端点，请参阅集群端点。
以下部分中介绍的服务行为仅适用于计划内维护。如需了解硬件故障等非计划内事件的影响，请参阅非计划内故障切换期间的客户端行为。
逐步部署策略
Memorystore for Redis Cluster 维护部署会逐步扩大范围，并以足够早地检测到故障的速度进行，以减轻影响并建立稳定性信心。在服务规模上，整个 Memorystore 集群舰队都集成了烘焙时间（在认为更新成功并继续之前应用和监控更新的时间）。此外，烘焙时间会集成到区域内各可用区（多个故障域）的集群中，以缩小影响范围（如有）。
对于配置为高可用性的集群，在任何给定时间最多更新一个容错网域/可用区，以确保集群分片（包括主实例和副本）在整个更新过程中都具有高可用性。此外，在任何给定时间，只有少数 Redis 节点会更新。更新使用先创建后销毁生命周期机制，以最大限度地提高集群稳定性。在更新具有多个分片的集群时，此策略可提供最大优势。在任何给定时间，仅将更新应用于整个用户键空间的一小部分，从而最大限度地提高数据可用性。
先创建后销毁生命周期策略
一个 Redis 集群有多个分片。每个分片都有一个主节点和零个或多个副本节点。Memorystore 使用以下流程更新分片中的任何现有主 Redis 节点或副本 Redis 节点：
- Memorystore for Redis Cluster 首先会向分片添加一个具有最新软件更新的全新副本。Memorystore 会创建一个全新的节点，而不是更新现有节点，以确保在发生意外引导失败时保留预配的容量。
- 如果要更新的分片中的节点是主节点，则在移除之前，会先使用协调故障切换将其转换为副本。
- 接下来，Memorystore 会移除使用旧版软件的副本。
- 对集群中的每个节点重复此过程。
与就地更新但会导致客户端应用可用性中断（有时还会导致数据丢失）的典型滚动部署相比，“销毁前创建”策略有助于保留集群的预配容量。对于没有副本的分片，Memorystore for Redis Cluster 仍会先预配一个新副本，协调故障切换，最后替换分片的现有主节点。
第 1 步：添加 Redis 副本
“先创建后销毁”机制的第一步是使用完全同步 OSS Redis 机制添加具有最新软件的副本节点，以将数据从主节点复制到副本节点。这是通过派生子进程并利用无磁盘复制来引导副本完成的。Memorystore for Redis Cluster 支持无磁盘复制。除非您启用持久化，否则 Memorystore for Redis Cluster 在复制期间不会使用磁盘。
您可以通过预配更多分片来减少节点内的键空间大小，从而充分利用集群的横向扩缩架构。每个节点的数据集较小，有助于减少完全同步操作的分支延迟影响。此外，它还能加快跨节点复制数据的速度。
第 2 步：协调的主实例故障切换
如果需要更新的 Redis 节点是主节点，Memorystore 会先执行到新添加的副本节点的协调故障切换，然后继续执行节点移除。在协调故障切换期间，客户端和 Redis 节点会协同工作，并使用以下策略来避免应用停机：
- 传入的客户端请求会在主节点上暂时被屏蔽，从而提供一个时间窗口，以确保现有副本与主节点完全同步。
- 副本完成选举过程，接管主角色。
- 之前的主节点（现在是副本）会解除对现有请求的屏蔽，并使用 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 会在为您的集群安排维护更新之前至少提前 7 天通过电子邮件通知您。
- 如果您的应用使用情况没有影响较小或无影响的时间段，请使用逐步发布的服务默认值。此默认设置包含维护更新的最佳实践。如需了解详情，请参阅计划内维护。
我们何时会建议您立即应用维护更新？
您可以立即在测试集群上应用维护更新，以了解更新对应用的影响。您可以观察此更新的影响。如果更新存在问题，您可以推迟对生产集群的维护，直到问题解决。
如果当前日期和时间适合您的集群，并且您预计集群未来会承受高负载，则可以立即运行维护更新。
维护更新是否始终在维护窗口内完成？
Memorystore for Redis Cluster 会在您指定的维护窗口内启动维护更新。Memorystore for Redis Cluster 通常会在该时间段内完成更新，但并非总是如此。
您能否选择不进行维护，或先安排对某些集群进行维护？
您无法选择停用维护或控制集群的维护顺序。不过，在收到初始维护通知后，您可以重新安排维护，将其最多推迟两周。
后续步骤
- 查看管理集群维护窗口所需的权限。