Memorystore for Memcached undergoes maintenance approximately once per quarter. Maintenance provides essential software updates to the operating system supporting your Memcached instance. Additionally, maintenance updates can occur in order to add critical security patches to your instance.
If your cluster only consists of one Memcached node, all of the data in your cluster is flushed. Otherwise, the nodes in your cluster are updated sequentially, so other nodes still serve data while they are in the queue to be updated. After a node is updated, it warms up and starts returning cache calls, even as other nodes are undergoing an update.
Memorystore for Memcached does not currently allow you to specify maintenance windows to indicate when maintenance updates to your Memcached instance can occur.
Maintenance updates are rolled out sequentially to nodes in your cluster with a 15 minute interval between each node update, in a maximum of six batches. For example:
|Cluster Shape||Maintenance rollout|
|2 nodes||Node 1 --> 15 mins --> Node 2|
|6 nodes||Node 1 --> 15 mins --> Node 2 --> 15 mins
Node 3 --> 15 mins --> Node 4 --> 15 mins
Node 5 --> 15 mins --> Node 6
|11 nodes||Nodes 1,2 --> 15 mins --> Nodes 3,4 --> 15 mins
Nodes 5,6 --> 15 mins --> Nodes 7,8 --> 15 mins
Nodes 9,10 --> 15 mins --> Node 11
Simulating a maintenance rollout
Before a maintenance event occurs you can test out how sequential unavailability of your keyspace affects your application. Understanding the way missing keyspace affects your application helps you avoid any unexpected negative impact to your application when maintenance for Memorystore for Memcached occurs.
You can simulate a maintenance event by using the
gcloud beta memcache
Simulating a maintenance event with this command requires you to temporarily change a Memcached configuration which triggers a cache flush like the one your nodes undergo during maintenance.
gcloud beta memcache applyparameters command in batches following the
maintenance rollout sequence for your cluster shape.