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 命令。