This page gives an overview of RDB snapshots for Memorystore for Redis.This page assumes you know about open source RedisRDB Snapshots and the Memorystoreimport/exportfeature.

To learn how to enable, disable, and monitor RDB snapshots, seeManaging RDB snapshots.

Memorystore for Redis is primarily used as an in-memory cache. When usingMemorystore as a cache, your application can either tolerate lossof cache data or can very easily repopulate the cache from a persistent store.However, there are some use cases where downtime for a Memorystoreinstance, or a complete loss of instance data, can cause long applicationdowntimes.

We recommend using the Standard Tier as the primary mechanism for highavailability. Additionally, enabling RDB snapshots on Standard Tier instancesprovides extra protection from failures that can cause cache flushes. TheStandard Tier provides a highly available instance with multiple replicas, andenables fast recovery using automatic failover if the primary fails.

In some scenarios you may also want to ensure data can be recovered fromsnapshot backups in the case of catastrophic failure of Standard Tier instances.In these scenarios, automated backups and the ability to restore data from RDBsnapshots can provide additional protection from data loss. With RDB snapshotsenabled, if needed, a recovery is made from the latest RDB snapshot.

RDB snapshots are suitable for use cases that can tolerate some amount of datastaleness after recovery. You can also use RDB snapshots to automate backup andrecovery of Basic Tier instances.

RDB snapshots overview

The RDB snapshots feature has the following behavior:

• Stores complete point-in-time snapshots at user specified intervals onpersistent storage.

• You choose the frequency and schedule of routine snapshots. The minimumsnapshot interval is1h and the maximum is24h.

• Basic Tier instances recover data from the most recent snapshot every time aninstance is restarted due to failure, undergoes ascaling operation,or undergoes anupgrade for the OSS Redis version your instance.

• By default, Standard Tier instances recover data from the replica, not asnapshot. However, Standard Tier instances recover data from a snapshot if areplica is not available and both primary and replica experience a restart.

• Adds no extra cost to your instance billing.

Additional behavior

• Snapshots are used for instance recovery and are not available for manualrestores. At any point in time, only the last successful snapshot is availablefor recovery. In addition to RDB snapshots, you can useExport and Importto manually backup and restore your data.

• On a Standard Tier instance, the snapshot is taken on the replica to minimizememory and CPU usage on the primary. Snapshots are never taken from theprimary node.

Constraints

• Available on Memorystore for Redis instances using Redis version 5.0 orgreater.

• If your instance has many keys (about 200 million or more), RDB snapshots andrecoveries can be slow. At this key volume the Redis server itself can be thebottleneck which slows down snapshots and recoveries.

Scheduling RDB snapshots

When enabling RDB snapshots during instance creation you must specify asnapshot interval. You also have the option to specify a start time. Togetherthese define the daily schedule of the snapshots. The intervals you can set are1h,6h,12h, and24h. For example, if you set the start time to 4 AM andthe interval to 1 hour, the snapshots start at 4 AM on the day they are enabled,and continue every hour after that.

If a start time is not specified, the first snapshot is taken as soon aspossible, and the interval is honored. For example, with an unspecified starttime and an interval of 1 hour the snapshot can start at 6:13 AM and continueat 7:13 AM, 8:13 AM, etc.

If a start time is specified, the daily schedule is consistently honored if thesnapshots always succeed and take no longer than the specified backup interval.

However, triggering the snapshot based on the daily schedule is best-effort. Theschedule can deviate from the initially determined schedule for a number ofreasons:

• If a snapshot fails or takes longer than the specified snapshot interval tocomplete, the next snapshot begins immediately after completion of thecurrent snapshot.

  • To prevent the snapshot from running continuously and overloading theinstance it is recommended to set an interval that is long enough to let thesnapshot complete.

• If a snapshot is already in progress at a time aligned with the dailyschedule, that snapshot completes and the next snapshot time is calculatedsolely on the interval from the start of the last successful snapshot.

Adjusting existing schedule

You may run into scenarios where you want to temporarily pause taking RDBsnapshots for a certain period of time. This could be to ensure there are noperformance impacts during critical events or to temporarily disable snapshotsto troubleshoot performance issues.

To stop taking snapshots temporarily for a short period of time you can adjustthe start time to be a future date. Once you adjust the start time to a futuredate, the next snapshot does not start till that date. If you do this, the lastsnapshot is retained for at least 7 days and is used in the event of a recovery.

To learn more about adjusting snapshot schedules, seeAdjusting snapshot schedule.

Recovery behavior

Basic Tier Redis instances trigger a recovery anytime the instance is restarted.Common operations that trigger restarts arescalingandupgrading the versionof your instance. RDB snapshots preserve Basic Tier instance data during theseoperations that cause restarts, planned maintenance, and unforeseen systemfailures.

Standard Tier Redis instances failover to a replica as the primary recoverymechanism rather than loading from a snapshot. A Standard Tier instance isrecovered from the snapshot when restoring from a replica fails.

Data consistency on recovery

When enabled, RDB snapshots make a best effort to ensure backups occur on thespecified interval, but this cannot be guaranteed. Snapshots can fail for anumber of reasons. See thebest practicesfor how to configure and monitor instances when RDB snapshots is enabled.

If the snapshot fails consecutively on multiple intervals, the last availablebackup can be arbitrarily stale.

The worst case data loss for a recovery from a snapshot is the sum of thespecified interval since the last good snapshot started and the time to save thenext snapshot to storage. In the case of a recovery incident, use thelast_success_age metric to view the timeframe for data loss.

We recommend that you set alerts to detect failure of scheduledsnapshots and take corrective action. To learn more about setting alerts, seeMonitoring snapshots.

Recovery time

The instance is unavailable while the instance recovers from a snapshot.Recovery time depends on the size of the snapshot. To understand thepredicted recovery time, check theRDB recovery remaining timemetric usingCloud Monitoringin the Google Cloud console.

Mitigating slow recovery

Sometimes recovering from a snapshot may take longer than expected. You may needto take action to get your application reconnected to Redis as quickly aspossible.

In this circumstance you can create a new Redis instance and direct applicationtraffic to it. Then you can transfer restored data to the new instance once theoriginal instance recovers.

Any failed snapshot is reported toCloud Monitoring,and the snapshot is retried immediately. Consecutive snapshot failures increasethe amount of data lost in the event of a recovery because recovered databecomes increasingly stale. For information on how to detect and troubleshootsnapshot failure, seeMonitoring snapshots.

Recovery failure

Recovery failures are rare but can happen. If a recovery failure occurs theinstance is recovered with no data.

Best practices

For best results backing up your instance with RDB snapshots, you should followthe best practices described below:

Memory management

RDB snapshots use a process fork and'copy-on-write' mechanism to take a snapshot of the instance. Depending on the pattern of writes to theinstance, theused memoryof the instance will grows as pages touched by the writes are copied. In theworst case, the memory footprint can be double the size of the data in theinstance.

To ensure the instance has sufficient memory to complete the snapshot, youshould setmaxmemory-gb to 80% of the instance capacity so that 20% isreserved for overhead. SeeMemory management best practicesto learn more. This memory overhead, in addition toMonitoring snapshotshelps you manage your workload to have successful snapshots.

Stale snapshots

Recovering your instance from a stale snapshot can cause performance issues foryour application as it tries to reconcile a significant amount of stale keys orother changes to your database such as a schema change.

If you think your snapshot is too stale, or your instance has undergone otherimportant changes that are hard to reconcile with the snapshot, you can disablethen reenable RDB snapshots. This deletes existing snapshots, allowing you toavoid recovering from a stale snapshot.

To monitor for stale snapshots, set an alert on the RDB snapshotlast_statusand RDB snapshotlast_success_agemetrics.

Prolonged recovery from a snapshot

We recommendSetting an alert for theredis.googleapis.com/server/uptimemetric to notify you if your instance becomes unavailable.

If your instance is unavailable and a recovery from a snapshot is taking toolong, you can create a new Redis instance and direct traffic to it. Once theoriginal Redis instance recovers, you cantransferrestored data to the new instance.

Performance impact of RDB snapshots

Depending on your workload pattern RDB snapshots can impact the performance ofthe instance and increase latency for your applications.

Depending on the amount of potential data loss your application can tolerate,you can minimize the performance impact of RDB snapshots by scheduling them torun during periods of low instance traffic.

Use the start time and interval to schedule the snapshots for the requiredtimes. For example if your load is very low from 1 AM to 4 AM you can set thestart time to 3 AM and set the interval to 24 hours.

If your system has a constant load and requires frequent snapshots, you shouldcarefully evaluate the performance impact, and weigh the benefits of using RDBsnapshots for the workload.

Monitoring snapshots

It is important to monitor snapshots, and set alerts for failed snapshots.Failed snapshots can indicate an overloaded instance that may continueto have difficulty recovering from the snapshot.

For a list of metrics available for monitoring snapshots, seeRDB snapshot metrics. To receive notice of a failed snapshot, set analert for the RDB snapshotlast_statusmetric. You can also use the Google Cloud console to check for any failures.

Monitoring performance impact

You can monitor the performance impact a snapshot has on yourMemorystore instance by viewing the metrics available throughCloud Monitoringlike CPU usage, memory usage, etc. If you noticed reduced performance you canuse the RDB snapshotin_progressmetric to determine if a snapshot was in progress when performance issues weredetected.

What's next

• Learn aboutimporting and exporting backups.
• Follow the guide forExporting data from a Redis instance.