This page provides an overview maintenance policies for Memorystore for Redis.
Memorystore for Redis instances undergo two kinds of maintenance updates: disruptive updates and non-disruptive updates. Disruptive updates occur periodically, and require the instance to restart. Memorystore for Redis instances get non-disruptive maintenance updates more frequently in the background.
Maintenance windows allow you to select a time and day of the week when you want disruptive maintenance updates to occur. Disruptive updates only occur during maintenance windows, but non-disruptive updates can occur outside of maintenance windows. They are not limited to windows because their impact on Memorystore for Redis instances is negligible.
For instructions on scheduling maintenance windows, see Managing maintenance updates.
In order to have the maintenance update process run smoothly you must set a maintenance window for your instance, and you should also turn on maintenance notifications. If you have done both of these steps you are notified at least seven days before a maintenance update is scheduled for your instance.
If you have signed up for notifications and you
haven't received an email notification, it means that maintenance has not been
scheduled for an instance. If maintenance notifications are turned off and a
maintenance update has been scheduled for your instance, you can
view the date and time of upcoming maintenance in the console, or
You can then choose to apply the maintenance immediately or
defer it for up to seven days. Deferring maintenance for over seven days is
not currently supported.
Maintenance windows are set in your local timezone when using the console.
When using the
gcloud option, you set the time using UTC time. Setting a
preferred maintenance window does not eliminate the disruption due to
maintenance, but it ensures that the disruption occurs at a time of your choice.
Setting/updating the maintenance window for basic and standard tier instances does not cause any downtime or cache flush and the IP address of the instance does not get changed. Maintenance updates impact basic and standard tier instances differently.
Maintenance impact on basic tier instances and best practices
- When maintenance is applied, the cache is flushed and data is not restored post maintenance. The downtime is usually on the order of 10-15 minutes.
- You can mitigate the key flush by exporting your data and/or using scheduled exports.
- You can simulate the downtime by temporarily scaling the instance to a larger size, and then scaling back to the original size.
Maintenance impact on standard tier instance and best practices
- Standard tier instances minimize downtime by failing over to the replica. This process uses the same connection string and IP address, and typically completes in a couple of minutes.
- A failover always results in a dropped connection. You should use a retry mechanism to reconnect your instance after a failover.
Impacts of maintenance updates
Disruptive maintenance updates affect Basic Tier and Standard Tier instances differently. Standard Tier instances use rolling upgrades, updating the replica node first, initiating a failover, then upgrading the second node. During this time, your application experiences client reconnections.
To learn more about the impact of failover on your application and best practices to minimize the impact, see How failover affects your application.
Basic tier instances experience downtime while the instance undergoes a cache flush and the patch is applied. The downtime is usually on the order of 10-15 minutes.
Since maintenance updates impact performance for both Standard and Basic Memorystore for Redis instances, you should schedule a maintenance window for a time of low instance traffic.
To best ensure a smooth maintenance update experience, we recommend that you take measures so that the System Memory Usage Ratio metric is at 50% or lower at the time of the scheduled maintenance update. You can do this by scheduling for a time when instance traffic is low, or by temporarily scaling up your instance size during the maintenance window so that the System Memory Usage Ratio metric is at 50% or lower.
During a maintenance update, Memorystore for Redis instances may be updated to an OSS Redis patch version that is up to date. OSS Redis patch versions generally do not include breaking or incompatible changes. See Version support policy for more details.
If you wish to observe the impact of maintenance updates on non-production instances before it is applied to production instances, we recommend that you set a maintenance window and turn on maintenance notifications for both the non-production and production instances. Once you receive the maintenance notifications, you have the option to start the update for non-production instances immediately and defer the update for production instances for up to seven days.
A maintenance window is a block of time that you specify in which disruptive maintenance updates can occur. Maintenance windows have the following behavior:
- The window is one hour in length.
- Maintenance does not begin outside of this window.
- The update usually starts near the beginning of the window.
- The update usually completes inside the one hour window, but this is not guaranteed.
When using the Cloud Console, maintenance windows are displayed and set in your local time zone but stored in UTC time; the Cloud Console also displays the maintenance window time relative to UTC time. When setting windows with the
gcloudcommand-line tool, you set the time using UTC time.
- You should schedule windows based off UTC time because the Cloud Console shows the window in the viewer's local time zone. This can cause confusion if users are setting the window in different time zones.
- Maintenance windows do not undergo daylight savings time changes.
If a window is not specified, a maintenance update can begin at any time.
You must turn on maintenance notifications in order to receive them.
Maintenance notifications arrive at least seven days ahead of a scheduled maintenance update.
Maintenance notifications are not sent out by default. If you want to get a notification for an upcoming disruptive maintenance update, you must do both of the following:
Maintenance notifications are set at the project level rather than on instances. All email addresses that need to receive notifications must be added individually.
Checking for upcoming maintenance
If you turn on maintenance notifications,
a notification is sent to your email at least seven days before scheduled
maintenance. If you want to set an email filter for notifications, the email
"Upcoming maintenance for your Cloud Memorystore instance
For instructions on viewing scheduled maintenance in the console, see Viewing scheduled maintenance.
If you receive a maintenance notification, and there is still time before the scheduled maintenance, you have the option to start the update immediately. You also have the option to change the maintenance window. For example, if you have a service release launching, you might want to reschedule the maintenance window to a few days before or after your launch.
For instructions on rescheduling maintenance see How to reschedule maintenance.
Rescheduling maintenance has the following behavior:
You cannot reschedule maintenance if there is less than one hour before the currently scheduled maintenance.
- Example: if your maintenance is currently set for 7:00 PM PST, and it is 6:55 PM PST, you cannot reschedule maintenance.
- Example: if your maintenance is currently set for 7:00 PM PST, and it is 5:00 PM PST, you can reschedule maintenance.
You can only defer a maintenance update for up to one week from when a maintenance update is originally scheduled for your instance.
- You can reschedule maintenance multiple times as long as the new date does not extend past one week from the originally scheduled time.
Bulk rescheduling is not available.You can reschedule maintenance for all Redis instances in your project. However, you can only reschedule one instance at a time.
When re-scheduling maintenance you have three options:
Start the update immediately.
Defer until the next scheduled window. This option delays maintenance until the next maintenance window. The next window is one week from the originally scheduled maintenance window.
Choose a custom day and time. The rescheduled time must be no more than seven days from time of the original maintenance window.
In very rare circumstances, in order to protect against vulnerabilities that are time sensitive, a disruptive update can be applied to a Redis instance outside of your designated maintenance window.
Cancelation of maintenance updates
If Memorystore cancels a maintenance event, you receive a notification that maintenance is cancelled. In rare cases, it might not be possible for Memorystore to send a cancellation notification in advance. In this case, you are notified that maintenance was not applied after the scheduled maintenance window has passed.
The maintenance is then rescheduled for a future maintenance window based on your selected preferences. You receive a new notification of upcoming maintenance when the maintenance event is rescheduled.
- View the permissions required to manage maintenance windows for your Redis instance.