本页面简要介绍了 Memorystore for Redis 的 RDB 快照。本页面假定您了解开源 Redis RDB 快照和 Memorystore 导入/导出功能。
如需了解如何启用、停用和监控 RDB 快照，请参阅管理 RDB 快照。
Memorystore for Redis 主要用作内存中缓存。将 Memorystore 用作缓存时，您的应用可以容忍缓存数据丢失，也可以非常轻松地从永久性存储区重新填充缓存。但是，存在一些 Memorystore 实例停机或实例数据完全丢失的用例，这可能会导致应用长时间停机。
我们建议将标准层级用作实现高可用性的主要机制。此外，在标准层级实例上启用 RDB 快照还可额外防范可能导致缓存刷新的故障。标准层级提供具有多个副本的高可用实例，并支持在主实例发生故障时使用自动故障切换快速恢复。
在某些情况下，您可能还希望确保在标准层级实例发生灾难性故障时，能够从快照备份中恢复数据。在这些情况下，自动备份和从 RDB 快照恢复数据的功能可以进一步防范数据丢失。启用 RDB 快照后，系统会根据需要从最新的 RDB 快照进行恢复。
RDB 快照适用于可以容忍恢复后一定数量的数据过时的用例。您还可以使用 RDB 快照自动备份和恢复基本层级实例。
RDB 快照概览
RDB 快照功能具有以下行为：
按用户指定的时间间隔将完整的时间点快照存储在永久性存储中。
您可以选择常规快照的频率和时间表。快照间隔的最小值为
1h，最大值为24h。每次因故障、执行扩缩操作或升级实例的 OSS Redis 版本而重启实例时，基本层级实例都会从最近快照恢复数据。
默认情况下，标准层级实例会从副本（而非快照）恢复数据。不过，如果副本不可用且主副本都重启，标准层级实例会从快照恢复数据。
不会增加额外的实例结算费用。
其他行为
快照用于实例恢复，不适用于手动恢复。在任何时间点，只有上一个成功快照可用于恢复。除了 RDB 快照之外，您还可以使用导出和导入功能手动备份和恢复数据。
在标准层级实例上，系统会为副本截取快照以最大限度地减少主实例上的内存和 CPU 使用率。系统绝不会从主节点创建快照。
限制条件
适用于使用 Redis 5.0 版或更高版本的 Memorystore for Redis 实例。
如果您的实例包含很多键（大约 2 亿个或更多），RDB 快照和恢复速度可能会很慢。在这种密钥量下，Redis 服务器本身可能会成为瓶颈，导致快照和恢复速度变慢。
安排 RDB 快照
在实例创建期间启用 RDB 快照时，您必须指定快照间隔。您还可以选择指定开始时间。这些参数共同定义了快照的每日时间表。您可以设置的时间间隔包括 1h、6h、12h 和 24h。例如，如果您将开始时间设为凌晨 4 点，将间隔设为 1 小时，则快照会在启用当天凌晨 4 点开始，之后每小时继续创建一次。
如果未指定开始时间，则尽快截取第一个快照，并遵循时间间隔。例如，如果未指定开始时间，并以 1 小时为时间间隔，则快照可以从上午 6:13 开始，然后在上午 7:13、上午 8:13 继续运行，以此类推。
如果指定了开始时间，则在快照始终成功且不超过指定备份时间间隔的情况下，始终遵循每日时间表。
但是，应尽可能根据每日时间表触发快照。由于以下多种原因，该时间表可能与最初确定的时间表有所不同：
如果快照失败或快照完成时间超过了指定的快照时间间隔，则在当前快照完成后，下一个快照会立即开始运行。
- 为防止快照连续运行和实例过载，建议设置足够长的时间间隔，以便让快照完成。
如果快照已按与每日时间表一致的时间进行，则该快照将完成，下一个快照时间仅根据上一个成功快照开始以来的时间间隔计算。
调整现有时间表
在某些情况下，您可能需要暂时暂停在特定时间段内创建 RDB 快照。这是为了确保在关键事件期间不会对性能产生影响，或者暂时停用快照以排查性能问题。
如需暂时停止截取快照一小段时间，您可以将开始时间调整为未来的日期。将开始时间调整为未来的日期后，下一个快照直到该日期才会开始运行。如果这样做，则最后一个快照会保留至少 7 天，并在恢复时使用。
如需详细了解如何调整快照时间表，请参阅调整快照时间表。
恢复行为
在任何时间重启实例时，基本层级 Redis 实例都会触发恢复。触发重启的常见操作包括扩缩和升级实例的版本。在这些导致重启、计划内维护以及意外的系统故障的操作期间，RDB 快照会保留基本层级实例数据。
标准层级 Redis 实例会作为主要恢复机制故障切换到副本，而不是从快照进行加载。标准层级实例从副本恢复失败时，会从快照进行恢复。
恢复时的数据一致性
启用后，RDB 快照会尽最大努力确保在指定间隔时间内进行备份，但无法保证一定会这样。快照可能会因多种原因而失败。如需了解如何在启用 RDB 快照后配置和监控实例，请参阅最佳实践。
如果快照在多个时间间隔内连续失败，则最后一个可用备份可以任意过时。
从快照恢复的最坏情况数据丢失是自上一个良好快照开始以来指定时间间隔以及将下一个快照保存到存储空间的时间的总和。对于恢复突发事件，请使用 last_success_age 指标查看数据丢失的时间范围。
我们建议您设置提醒，以检测定期快照失败并采取纠正措施。如需详细了解如何设置提醒，请参阅监控快照。
恢复时间
在实例从快照恢复时，实例处于不可用状态。恢复时间取决于快照的大小。如需了解预计恢复时间，请在 Google Cloud 控制台中使用 Cloud Monitoring 查看 RDB recovery remaining time 指标。
缓解恢复速度缓慢
有时，从快照恢复可能需要的时间会超出预期。您可能需要采取措施，让应用尽快重新连接到 Redis。
在这种情况下，您可以创建一个新的 Redis 实例，并将应用流量引导到该实例。然后，在原始实例恢复后，您可以将已恢复的数据转移到新实例。
快照失败和恢复失败
快照失败
任何失败的快照都会报告给 Cloud Monitoring，并且系统会立即重试快照。连续快照故障会增加恢复时丢失的数据量，因为恢复的数据会越来越多的过时。如需了解如何检测和排查快照故障，请参阅监控快照。
恢复故障
恢复故障的情况很少见，但可能会发生。如果发生恢复故障，则实例将恢复，但没有任何数据。
最佳做法
为了通过 RDB 快照备份实例获得最佳结果，您应遵循以下最佳做法：
内存管理
RDB 快照使用进程分叉和“写时复制”机制来获取实例的快照。根据对实例的写入模式，随着写入所涉及的页面被复制，实例的已用内存将会增加。在最糟糕的情况下，内存占用量可能会是实例中数据大小的两倍。
为了确保实例有足够的内存来完成快照，您应将 maxmemory-gb 设置为实例容量的 80%，以便将 20% 预留给开销。如需了解详情，请参阅内存管理最佳实践。除了监控快照之外，这种内存开销还有助于您管理工作负载，以便成功创建快照。
过时快照
从过时快照恢复实例可能会导致应用出现性能问题，因为应用会尝试协调大量过时的密钥或对数据库的其他更改，例如架构更改。
如果您认为快照过于过时，或者实例发生了其他难以与快照协调的重要更改，您可以先停用 RDB 快照，然后再重新启用。这会删除现有快照，从而避免从过时快照恢复。
如需监控过时快照，请针对 RDB 快照 last_status 和 RDB 快照 last_success_age 指标设置提醒。
从快照恢复时间延长
我们建议您为 redis.googleapis.com/server/uptime 指标设置提醒，以便在您的实例不可用时通知您。
如果您的实例不可用，并且从快照恢复所花的时间过长，您可以创建新的 Redis 实例并将流量转到该实例。原始 Redis 实例恢复后，您可以将恢复的数据转移到新实例。
RDB 快照对性能的影响
根据您的工作负载模式，RDB 快照可能会影响实例的性能，并会增加应用的延迟时间。
根据应用可容忍的潜在数据丢失量，您可以将 RDB 快照安排在低实例流量期间运行，以最大限度地降低 RDB 快照的性能影响。
使用开始时间和时间间隔可以将快照安排在所需的时间。例如，如果负载从凌晨 1 点到凌晨 4 点非常低，则可以将开始时间设置为凌晨 3 点，并将时间间隔设置为 24 小时。
如果您的系统具有恒定负载，并且需要频繁的快照，您应仔细评估性能影响，并权衡将 RDB 快照用于工作负载的好处。
监控快照
监控快照并针对失败的快照设置提醒非常重要。失败的快照可能表明过载的实例可能仍然难以从快照恢复。
如需查看可用于监控快照的指标列表，请参阅 RDB 快照指标。如需接收快照失败通知，请为 RDB 快照 last_status 指标设置提醒。您还可以使用 Google Cloud 控制台检查是否有任何失败。
监控性能影响
您可以通过查看 Cloud Monitoring 提供的指标（如 CPU 用量、内存用量等）来监控快照对 Memorystore 实例的性能影响。如果您发现性能降低，您可以使用 RDB 快照 in_progress 指标来确定在检测到性能问题时快照是否正在进行中。
后续步骤
- 了解如何导入和导出备份。
- 按照从 Redis 实例中导出数据指南进行操作。