本页面简要介绍了 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 metrics设置提醒。
从快照恢复时间延长
我们建议为 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 实例中导出数据指南进行操作。