维护政策

Memorystore for Memcached 大约每六个月进行一次中断性维护,目的是将最新的安全补丁程序和更新包含在内。中断性更新需要重启节点。Memcached 实例在后台进行非中断性维护更新更频繁。

非中断性更新会自动应用,系统不会发送任何通知。系统会为中断性更新提供 30 天的通知。

手动维护与自动维护

对于中断性更新,您可以选择手动维护或自动维护。

手动维护

手动维护允许您对 Memcached 实例应用更新。您可以在收到即将进行维护的通知后的 30 天内手动应用更新。

如需了解如何手动应用维护更新,请参阅应用维护更新

自动维护

如果您在收到通知后的 30 天内未手动更新实例,系统会自动应用维护更新。如需了解详情,请参阅自动维护发布

中断性更新的维护时间表

  • 您会收到重要的服务通知电子邮件,通知您 30 天的手动维护期已打开。

  • 在 30 天的固定维护期内,您可以对 Memcached 集群中的节点手动应用软件更新

  • 维护期关闭后,自动维护发布可以随时更新 Memcached 集群。

自动维护发布

自动维护会在 30 天手动维护期结束后进行。维护更新会按顺序逐个应用于每个节点。节点更新在六小时的维护期内按等间隔时间进行。下表显示了不同数量的节点的维护发布:

节点数 节点更新之间的延迟 总时长
1 个节点 无延迟 最多 60 分钟
2 个节点 310 分钟 360 分钟
4 个节点 96 分钟 358 分钟
7 个节点 43 分钟 358 分钟
13 个节点 16 分钟 352 分钟
20 个节点 6 分钟 344 分钟

如果您的集群仅包含一个 Memcached 节点,则集群中的所有数据都将被清空。否则,集群中的节点会依序更新,以便其他节点在排队等待更新期间仍然可提供数据。一个节点更新后,即使其他节点正在进行更新,它也会预热并开始返回缓存调用。

手动维护的最佳做法

中断性维护更新需要 Memcached 集群中的每个节点都要更新和重启,导致集群的缓存完全清空。根据您的应用用例,可能最好一次性完成节点维护,或者在短时间内完成。

但是,一次性更新或短时间内更新会减少缓存的可用键空间,这样可能会对提供给传入缓存请求的键数量产生负面影响(缓存命中率较低)。对于节点数较多的的集群,尤为如此。

您可以逐个或批量更新节点,从而减少键空间损失,同时在更新之间为节点解冻键留出时间。

此外,您还应该考虑缓存获取大多数请求的时间段,并尝试在使用量较低期间更新节点。

模拟维护发布

在维护事件发生之前,您可以测试键空间连续不可用对应用的影响。通过了解缺少键空间对应用的影响,您可以避免在对 Memorystore for Memcached 进行维护时对应用造成意外的负面影响。

您可以使用 gcloud memcache applyparameters 命令来模拟维护事件。

要使用此命令模拟维护事件,您需要临时更改 Memcached 配置,以触发与维护期间节点所经历的缓存刷新类似的缓存刷新。

按照集群形状的维护发布顺序批量运行 gcloud memcache applyparameters 命令。