【Redis 神秘大陆】这个系列写到第六篇聊一个平时没人主动提起、真出事时第一个被追问的话题Redis 灾备方案。前五篇谈的是怎么把 Redis 用快、用稳、用得顺手这一篇反过来谈它彻底不可用之后数据还能不能捞回来。促成本篇写的是一次很典型的现场复盘某团队的主从架构跑了一年多监控面板上两个节点一直是绿色所有人都默认它高可用。直到某个凌晨一个本该只连测试库的清理脚本误连了生产实例一条FLUSHALL下去主库瞬间清空两百毫秒后从库同步到位主从双双归零。事后翻配置才发现RDB 快照是有的但上一次写入磁盘是六个小时前AOF 根本没开备份文件从部署那天起就没被复制出过这台机器。这里没有一处可以归因于 Redis 本身。问题全部出在灾备设计上防的是什么事故没想清楚持久化和备份被混为一谈副本被当成了保险箱。所以这篇按这个逻辑走先把事故类型分级再用 RPO/RTO 把“容灾”翻译成可验收的数字接着拆持久化、复制、异地归档三层怎么配最后讲怎么用演练把纸面方案跑成能真正救命的流程。适合已经在跑 Redis、准备补一套容灾体系的读者也适合刚接手别人留下的 Redis 集群、需要快速摸清家底的人。1. 灾备不是“备份”先分清你要防的三类事故做灾备最常见的错误是一上来就问“备份放哪”。这个问题本身没错但顺序反了。正确的起点是你打算防哪几种事故不同事故的应对手段在两个完全不同的层面配错层等于白配。1.1 进程崩溃、机器宕机、机房失联三种事故的应对层完全不同我一般把 Redis 的故障分成四类逐一对照手段事故类型典型场景有效手段无效手段进程级OOM 被系统杀掉、崩溃重启、配置改错RDB / AOF 持久化主从数据仍在内存中重启即失单机级磁盘损坏、主板故障、宿主机下线主从 / 哨兵 / Cluster只在本机持久化磁盘坏了文件也没了机房级供电中断、网络整体不可达异地副本、异地备份归档同机房多副本会一起下线逻辑级误删、脚本错误、脏数据覆盖时间点快照、多版本备份主从错误会立刻同步到所有副本这张表是我每次排查灾备缺口时的第一张检查单。四个格子只要有一个是空的方案就是不完整的。特别说一下第四类也就是逻辑级事故。这是被低估得最厉害的一类。主从在这里不但没用反而会加速故障扩散你删了主库从库跟着删你从从库切主切上去的还是删干净的数据。能救这一类的只有不跟随写入的时间点副本。1.2 用 RPO 和 RTO 把“容灾”翻译成可验收的数字“方案要可靠”是句空话验收不了。能验收的只有两个数字RPORecovery Point Objective最多能接受丢多长时间的数据。它决定了持久化频率和备份频率。RTORecovery Time Objective最多能接受停多长时间。它决定了你选热备、温备还是冷备。这两个数字必须由业务方给出不能由 DBA 自行确定。实际沟通可以先给一个推导起点再让对方确认数据性质典型 RPO典型 RTO建议方案纯缓存缓存失效后可从数据库回源重建小时级10 分钟内单副本 定期快照 快速重建脚本会话 / 登录态秒级1 分钟内主从 哨兵 AOF everysec排行榜 / 统计结果分钟级5 分钟内主从 定期快照可从源数据重算计数 / 队列 / 幂等键接近 01 分钟内必须落库或 AOF always 写完确认这里有个判断标准我一直在用Redis 里的数据到底是不是唯一数据源。如果它只是数据库前面的缓存那丢了就丢了灾备的重点反而变成“重建不能把后端数据库压垮”需要提前准备限流和分批预热。如果 Redis 承担了唯一存储的职责那么再强的灾备也只是缓解真正的解法是把关键数据补一份写到持久化存储里。这一点想不清楚后面所有参数配置都是无源之水。1.3 最常见的错位把持久化当灾备把主从当备份这两个混淆几乎是所有事故现场的共同特征值得单独说明。持久化防的是重启不防事故。RDB 和 AOF 让进程重启后能恢复数据但文件就在本机磁盘上磁盘损坏、误格式化、机器被回收文件一样没了。把持久化当灾备等于把保险柜和房子建在一起。主从防的是单机故障不防逻辑错误。从库是主库的实时镜像同步延迟通常在毫秒级。主库写错了从库五十毫秒后就错了。想靠“出问题从从库切过去”来救误删是行不通的。备份是时间点快照离线不跟随写入。它恢复出来的数据一定是过去的也不实时但正因为这样它才是唯一能对抗逻辑错误的手段。三者的关系可以这么理解持久化是让房子重建之后家具还在主从是隔壁还有一套一模一样的房子备份是老照片房子拆了也能照着老照片把样子还原出来只是还原的是当时的样子。2. 持久化配置的取舍RDB 快照、AOF 日志与混合模式持久化是灾备的地基。这一层配得不对上面搭什么都站不住。Redis 给了两套机制加一种混合模式每一套的价值和代价都非常具体值得逐项说明。2.1 BGSAVE 的 fork 代价与内存水位红线RDB 靠BGSAVE生成快照BGSAVE会 fork 一个子进程。fork 本身的耗时取决于页表规模经验上讲大致在每 GB 内存十几毫秒的量级机器和内核版本不同差异很大32GB 的实例 fork 花上百毫秒并不罕见。这段时间主线程是阻塞的客户端会感知到一次请求毛刺。更关键的是写时复制COW带来的内存放大。BGSAVE期间如果写入量大被修改的内存页会被复制一份给子进程实例的内存占用可能涨到原来的 1.5 倍甚至接近 2 倍。所以有一条必须遵守的水位线used_memory长期不要超过maxmemory的 60% 到 70%。超过这个比例一次BGSAVE加上一次全量同步叠加就很容易触发 OOM 或者 swap那就不是毛刺而是雪崩了。还有一个真实经历过的问题透明大页THP。系统开启 THP 之后COW 的内存复制单位会从 4KB 变成 2MB同样的写入量下COW 复制的内存会放大BGSAVE期间延迟尖刺会明显得多。我的做法是在部署脚本里固定关掉echo never /sys/kernel/mm/transparent_hugepage/enabled echo never /sys/kernel/mm/transparent_hugepage/defragRDB 的常用配置save 900 1 save 300 10 save 60 10000 stop-writes-on-bgsave-error yes rdbcompression yes rdbchecksum yes dbfilename dump.rdb dir /data/redis/stop-writes-on-bgsave-error这一行值得展开说因为它直接站在数据安全和业务可用性的对立面上。设为yes写入磁盘失败时主库拒绝写请求数据安全性好但业务会立刻感知到写入不可用。设为no继续接受写入但此时 RDB 已经坏了你以为什么都没发生其实备份链路早已中断。我的选择是yes加严格的告警。原因很直白你在硬盘损坏时继续写入得到的只是一份看起来正常、实际无法恢复的数据掩盖问题的代价比短暂不可用高得多。但前提是必须监控rdb_last_bgsave_status把这个指标作为重点告警项否则等于给自己埋雷。对于单实例超过 32GB 的情况我更倾向于拆分成多个小实例而不是在一个大实例上调整参数。原因很实在fork 抖动和全量同步的代价都随数据量非线性上升缩小单实例体积比调参有效得多。2.2 appendfsync 三档选择的真实后果AOF 是把写命令追加到日志文件appendfsync决定多久真正调用一次fsync写入磁盘。取值行为最坏情况丢失代价always每条写命令都 fsync基本为 0每次写多一次磁盘往返吞吐可能降到几千 QPS寿命消耗也大everysec后台线程每秒 fsync 一次约 1 秒周期性延迟尖刺通常 1 到 25 毫秒no交给操作系统决定可能 30 秒延迟平滑但丢失量不可控绝大多数生产环境用everysec但它的副作用很多人没意识到。当磁盘 IO 已经很紧张、上一次 fsync 还没完成时主线程在刷新缓冲时会等待表现出来的现象是每隔一两秒出现一次延迟毛刺。如果你的监控里看到 p99 延迟稳定地呈现锯齿状而 CPU 和网络都不高先去看磁盘的await和%util八成就是这个原因。配套的两个参数appendonly yes appendfsync everysec no-appendfsync-on-rewrite yes aof-load-truncated yesno-appendfsync-on-rewrite yes的含义是AOF 重写期间不做 fsync。目的是避免重写的大量磁盘写和 fsync 抢 IO。代价是这段时间的丢失窗口会变大取决于操作系统的刷盘节奏。这个参数属于典型的两害相权我倾向于打开同时把重写时间安排在业务低峰。aof-load-truncated yes允许 AOF 尾部不完整时继续启动。这里的取舍很明确尾部截断说明最后一批写入可能不完整但总比起不来强。生产上建议打开同时监控日志里的截断告警因为它往往意味着进程曾经异常退出或者磁盘写满。2.3 AOF 重写与混合持久化为什么要打开 aof-use-rdb-preambleAOF 是追加写文件会越来越大必须靠重写来压缩。触发条件auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 512mb第一条表示文件比上次重写后增长了一倍就触发第二条是下限保护避免小实例频繁重写。min-size我一般设得比默认的 64MB 大因为小文件重写的收益很低而重写本身有 fork 和 IO 代价。aof-use-rdb-preamble yes这个参数从 4.0 起提供现在应该默认打开。它让 AOF 文件的前半段用 RDB 格式保存全量数据后半段才是增量命令。收益有两个文件体积明显变小加载速度大幅提升。在几十 GB 数据量下纯命令格式的 AOF 加载可能要好几分钟混合格式通常能压到几十秒。7.0 之后还有一个功能值得用起来aof-timestamp-enabled yes。开启后 AOF 里会记录每条命令的写入时间戳恢复时可以按时间点截断把数据恢复到“误操作发生前的那一刻”。对应工具支持按时间戳截断 AOFredis-check-aof --aof-file /data/redis/appendonlydir/appendonly.aof.1.incr.aof \ --truncate-to-timestamp 1735660800这个能力对误删类事故价值极高等于把 RPO 从“最后一次备份”压缩到了“精确到秒的某个时刻”。前提是 AOF 本身要一直开着。2.4 从写入磁盘的文件恢复的完整操作链路与校验恢复不是把文件拷过去启动就完事这套流程我踩过太多次坑现在固定成七步先冻结现场。把当前dir整个目录改名或复制一份不要覆盖。现场一旦丢失后续排查完全没法做。确认要恢复的时间点。从备份清单里挑最近的、在事故之前的那个版本注意核对备份时间戳而不是文件名。校验文件完整性。不要跳过这一步。redis-check-rdb /backup/dump.rdb redis-check-aof --aof-file /backup/appendonly.aof两个工具都会打印文件的基本信息包括redis-ver、库数量、键数量。这一步能在启动之前就发现文件损坏。核对版本兼容性。RDB 格式是向下兼容、向上不兼容的高版本写的 RDB低版本加载不了。恢复前确认目标实例版本不低于备份来源版本。处理文件权限。文件属主必须是运行 Redis 的那个用户。这个问题极其常见尤其是从对象存储拉下来再解压的场景解压出来的文件属主是执行解压操作的用户Redis 读不到启动后dir是空的你可能还以为恢复成功了。注意 AOF 和 RDB 的优先级。如果appendonly yes且 AOF 目录存在Redis 会优先加载 AOF。很多人把新的dump.rdb拷进去结果加载的还是那份旧 AOF数据看起来没变。恢复 RDB 时必须把 AOF 目录一并移走。启动后做验证。至少查四项dbsize是否接近预期、抽样几个 key 的值是否正确、TTL 是否保留、DB 编号分布是否符合预期。还有一个容易忽略的点databases配置数量。如果源实例配了databases 32恢复的目标实例还是默认的 16超出范围的库数据就会出现问题。这个错误在跨环境恢复时特别常见恢复前一定要逐行核对配置文件差异。3. 复制链路主从、哨兵、Cluster 各自的容灾能力与盲区持久化解决了重启问题复制解决的是“机器没了”。这两者叠加才是完整的高可用底座。但复制链路本身有大量参数决定了它在故障时到底能不能顶上配不好就是“看着有两个节点真挂了切不过去”。3.1 全量同步、增量同步与 repl-backlog 的容量估算从库第一次连上主库时走全量同步从库发PSYNC ? -1主库执行BGSAVE生成 RDB传输给从库传输期间的新写入暂存在 backlog 里传完之后再把 backlog 里的增量补发。重连时如果能对上 offset就走增量。关键在 backlog它是一个环形缓冲区默认只有 1MB。这个默认值在实际业务里几乎必然不够。一旦从库断线的时间超过 backlog 能覆盖的时长就会退化成全量同步。而一次全量同步的代价可能是几分钟的传输加一次BGSAVE抖动在业务高峰期相当危险。容量估算有个简单公式repl-backlog-size ≥ 平均写入字节速率(B/s) × 预计最长断线时间(s) × 2举例写入量 5MB/s希望容忍 120 秒的网络抖动需要5MB × 120 × 2 1200MB也就是 1.2GB。这个数字看起来夸张但用默认 1MB 的时候断线 0.2 秒就会退化成全量。repl-backlog-size 512mb repl-diskless-sync yes repl-diskless-sync-delay 5 client-output-buffer-limit replica 1024mb 512mb 300repl-diskless-sync让主库直接把 RDB 通过网络发给从库不写入磁盘省掉一次磁盘写。磁盘性能一般而网络充裕的环境这个参数收益明显。client-output-buffer-limit replica这一行很多人没配过但它会导致一个很难查的现象全量同步反复失败日志里是“从库超时断开”。原因是主库给从库准备的发送缓冲区超过了默认限制硬限 256MB主库直接把连接断了。大实例全量同步时缓冲区堆积到几百 MB 很正常必须调大否则永远同步不完。3.2 哨兵选主quorum 与脑裂防护参数怎么配哨兵负责监控和自动切换。部署上的第一条硬性要求至少三个、且为奇数。两个哨兵的部署看似省钱实际上任何一个挂掉就无法达成多数切换能力直接归零。sentinel monitor mymaster 10.0.0.11 6379 2 sentinel down-after-milliseconds mymaster 30000 sentinel failover-timeout mymaster 180000 sentinel parallel-syncs mymaster 1quorum的取值按“哨兵总数的一半加一”起步三个哨兵配 2。判定下线需要 2 个哨兵都认为主库不可达这个门槛既避免单点误判又保证真故障时能触发。down-after-milliseconds我一般设 30 秒而不是更短。设成 5 秒看起来很敏捷但一次 GC 停顿、一次网络抖动、一次BGSAVEfork 抖动都可能超过 5 秒结果是频繁误切换。切换本身有代价新主选出来之后所有从库要重新同步业务会抖一阵。parallel-syncs 1表示切换完成后一次只有一个从库向新主发起同步。设成 2 或更多会让切换后的数据可用性恢复更快但新主同时服务多个全量同步本身可能被压垮。我在数据量大的环境里坚持用 1。脑裂防护是这一节最该讲的部分。网络分区时老主和哨兵失联但客户端还能连上老主继续写与此同时哨兵选出新主集群里出现了两个接受写入的主库。分区恢复后老主被降级为从库它在这段时间接受的写入会被清空并重新同步那部分数据直接消失。防护参数配在主库上min-replicas-to-write 1 min-replicas-max-lag 10含义是至少要有一个副本在线且延迟不超过 10 秒否则主库拒绝写入。这样老主在被隔离之后会自动变成只读状态避免产生无法合并的写入。代价必须说清楚副本全部挂掉时主库也会拒绝写可用性下降。这个取舍没有标准答案取决于业务是“宁可不可写也不能写乱”还是“先保证能写”。我的经验是交易类、计数类业务用这组参数纯缓存类业务不用。还有一个隐蔽的坑这组参数哨兵切换时不会自动下发到新主。新主是从原来的从库提升上来的如果配置文件里没有同样的两行切换完成后防护就失效了。所以配置必须写进所有节点的配置文件而不是只在主库上临时CONFIG SET。3.3 Cluster 的副本迁移与 cluster-require-full-coverageCluster 模式把数据分到 16384 个槽上至少三主三从。主节点挂掉后对应的从节点在多数主节点达成一致后自动提升不需要外部组件。cluster-node-timeout 15000 cluster-require-full-coverage yes cluster-migration-barrier 1cluster-node-timeout决定多久判定节点失联。设太短一次网络抖动就触发切换和槽迁移集群会反复震荡设太长真故障时恢复慢。15 秒是多数场景能接受的折中。cluster-require-full-coverage是个必须由业务方拍板的参数yes任何一个槽没有可用主节点整个集群拒绝服务。一致性优先但一个分片出问题会拖垮全部。no只有受影响的槽不可用其他槽照常服务。可用性优先但客户端需要能正确处理部分 key 报错。我见过的大多数业务选择no但前提是客户端 SDK 对CLUSTERDOWN和MOVED有正确的处理逻辑否则会出现零星的、难以复现的失败。cluster-migration-barrier控制副本自动迁移当某个主节点没有任何副本时从副本富余的主节点迁一个过来。默认值 1 是合理的。设太大会导致副本迁移不触发某个主节点长期处于没有副本的裸奔状态。Cluster 还有一个经常被灾备方案忽略的限制只有 db0不支持多库。如果原方案依赖多库做数据隔离上 Cluster 之前必须改数据模型。3.4 切换瞬间到底会丢多少数据这个问题必须讲清楚因为它是灾备方案里最容易被高估的部分。Redis 的复制是异步的主库执行完写命令返回客户端成功然后再把命令发给从库。如果在“返回客户端”和“从库收到”这两步之间主库挂了这部分数据就永久丢失了。丢失量可以这么估丢失条数 ≈ 主库写入 QPS × 复制延迟同机房内网复制延迟通常在 1ms 以内10 万 QPS 下丢失量在百条量级。跨机房 RTT 2 到 10ms同样的写入量下丢失量会到几千条。这个数字在选方案的时候必须摆到桌面上。想要更小的窗口Redis 提供了一个原语WAIT。SET order:1001 paid WAIT 1 100WAIT numreplicas timeout会阻塞当前连接直到指定数量的副本确认收到了之前所有写命令或者超时。它把异步复制在关键路径上变成了“近似同步”。代价是每次关键写多一个 RTT吞吐会受明显影响。我的用法是只在真正不能丢的写上调用WAIT比如支付状态、库存扣减的最终标记普通缓存写入完全不碰。全量使用WAIT会把 Redis 的吞吐优势抹平。4. 异地与误删场景延迟从库、冷备归档与备份生命周期前面两层解决的是“机器和机房”这一层解决的是“数据和人的手”。逻辑错误是所有灾备场景里最棘手的一类因为它不触发任何技术告警等你发现的时候错误已经被复制到所有副本上了。4.1 误删场景没有捷径只有时间点快照必须先说清楚一件事Redis 原生没有延迟复制参数。MySQL 有类似MASTER_DELAY的机制可以轻松搭出延迟从库Redis 没有对应能力。想做一个“比主库慢一小时”的副本只能借助外部同步工具做延迟应用或者用定期快照来模拟。想靠延迟从库救误删需要满足两个条件错误在一小时内被发现以及延迟副本没有跟着执行同样的错误。第二个条件在脚本误连的场景里经常不成立因为误操作往往是对着所有节点执行的。所以我的实际方案更朴素也更可靠多时间点快照。具体做法是从库上定时触发快照并归档比如每小时一份保留最近 48 小时。误删发生时你只需要找到事故发生前的那份快照。一个很实用的技巧很多人不知道可以直接用redis-cli从远端拉一份 RDB不需要登录服务器操作文件。redis-cli -h 10.0.0.12 -p 6379 --rdb /backup/redis-$(date %Y%m%d%H).rdb这个命令会触发服务端做一次无盘BGSAVE然后通过网络把 RDB 流式拉到本地。它的好处是在从库上执行时对主库零影响而且不需要在 Redis 服务器上预留大块磁盘空间。把它挂到定时任务里就是一小时一份的归档。还有一个让备份从库不被误提升的小技巧把它的replica-priority设为 0。replica-priority 0哨兵在选主时会跳过优先级为 0 的节点。这样专门用来做备份的从库永远不会被选为新主避免它因为数据落后而成为生产主库。4.2 备份文件往哪放本地、异地与对象存储的分层备份放置的深度决定了你能扛住哪一级事故层级能防的事故恢复速度成本与数据同盘基本防不住什么极快极低同机另一块盘目录误删快低同机房另一台机器单机磁盘损坏、主机下线分钟级低异地对象存储机房级故障取决于下载带宽按量计费实用的分层是本地留最近两份用于快速回滚异地对象存储保留完整历史用于兜底。参考 3-2-1 原则至少 3 份副本、2 种不同介质、1 份异地。上传用常见的命令行工具即可例如rclone copy /backup/redis-2025010100.rdb remote:redis-backup/prod-a/上传完成后要做一次校验把文件的 MD5 也记录下来。我吃过一次亏上传中断留下了个半截文件文件大小看着差不多直到真需要恢复的时候才发现打不开。现在我的脚本里固定在上传后回读校验md5sum /backup/redis-2025010100.rdb # 与远端记录的 md5 比对一致才把备份标记为可用4.3 备份保留策略与版本兼容坑保留策略我一般这么定每小时一份保留 48 小时覆盖“周末才发现”的场景每天一份保留 14 天每周一份保留 8 周每月一份保留 12 个月看起来量很大但 Redis 的 RDB 经过压缩之后体积可控对象存储的成本远低于一次数据丢失的代价。真正占成本的是下载流量和存储请求不是容量本身。版本兼容的坑值得单独强调因为它会在最需要备份的时候咬你一口。RDB 格式是向下兼容、向上不兼容的。用 7.2 写的 RDB拿到 6.2 的实例上加载会直接失败。这不是参数问题是格式版本问题改配置没用。跨版本恢复有两条路把目标实例升级到不低于源版本或者用带格式转换能力的迁移工具做一次数据搬迁。另外两个经常被忽略的兼容点databases数量。前面提过一次这里再说一遍因为它真的是高频错误。源实例 32 个库目标实例默认 16 个恢复出来的数据是不完整的而且不一定报错。配置文件本身的差异。备份里只有数据没有maxmemory、appendonly、maxmemory-policy这些配置。恢复到一个配置完全不同的实例上数据可能刚加载完就大批量过期或被淘汰。恢复前把配置文件也做一份版本化归档和备份文件放在一起。5. 恢复演练灾备方案唯一的验收方式所有前面讲的配置如果没有验证过都只能算“假设”。灾备方案最大的风险不是配置不足而是你以为它能用。唯一的解法是定期演练把它当成一次真实的故障处置。5.1 演练脚本该怎么写演练的目标不是“恢复成功”而是“测量出真实的 RTO 和瓶颈位置”。所以脚本要记录时间线而不只是最后结果。我的演练脚本大致长这样#!/bin/bash set -e T0$(date %s) echo [$(date)] 1. 下载最新备份 rclone copy remote:redis-backup/prod-a/latest.rdb /restore/ echo [$(date)] 2. 校验文件 redis-check-rdb /restore/latest.rdb echo [$(date)] 3. 准备干净的数据目录 rm -rf /restore/data mkdir -p /restore/data cp /restore/latest.rdb /restore/data/dump.rdb chown -R redis:redis /restore/data echo [$(date)] 4. 启动临时实例端口 6399 redis-server /restore/redis-restore.conf --daemonize yes sleep 2 echo [$(date)] 5. 基础校验 redis-cli -p 6399 dbsize redis-cli -p 6399 info keyspace T1$(date %s) echo [$(date)] 演练总耗时: $((T1-T0)) 秒配合关键校验项dbsize与预估量级是否一致抽样 10 个业务关键 key比对值检查 TTL 是否保留很多人只看值不看过期时间检查各 DB 的键分布用真实业务代码连上去跑一个读请求最后一步特别重要。我用过太多次开发环境验证通过、一到生产就出问题的情况原因往往是客户端配置、连接串、序列化方式不一致。演练时一定要让业务方参与验证而不是由运维单方面宣布“恢复成功”。5.2 一次完整演练的时间线与瓶颈定位下面是我经历过的某次演练的真实记录数据量约 6GB阶段耗时说明下载备份3 分 20 秒从对象存储拉 6GB受带宽限制校验文件40 秒redis-check-rdb扫描全文件拷贝与权限处理15 秒容易被忽略但必不可少启动加载55 秒RDB 加载约 110MB/s业务验证4 分钟人工介入最不可控合计约 9 分钟这张表里最有价值的信息是恢复时间的大头不在 Redis 加载而在下载和人工确认环节。加载 6GB 花了 55 秒而下载花了 3 分多钟。这意味着想压缩 RTO优化的方向不是调整 Redis 参数而是把常用备份提前复制到同区域的存储缩短下载路径准备好恢复用的实例模板演练时直接启动而不是现场装 Redis把业务验证做成自动化脚本而不是靠人一条条点我按这个思路优化之后同样的数据量RTO 从 9 分钟压到了 4 分半。这个提升幅度远超任何 Redis 参数调整能带来的收益。5.3 演练里反复出现的几类翻车点这几条都是我在演练中真实遇到过的每一条都能让方案在关键时刻失效备份文件属主不对。从对象存储拉下来的是 root 属主Redis 起不来或者加载到空目录。启动日志里只有一句“no such file”非常容易被误认为是路径配错。AOF 抢在 RDB 前面加载。恢复时appendonly yesappendonlydir里留着半年前的旧 AOFRedis 优先加载 AOF恢复出来的数据完全是旧版本。这个坑我第一次遇到时排查了很久因为dbsize有值看起来“恢复成功”了。备份从库的数据是落后的。恢复用的是从库的备份但那台从库因为网络问题已经落后主库几小时而且没人发现。所以演练时要检查从库的master_repl_offset与主库的差值把“同步延迟”作为备份是否可用的前置判断条件。maxmemory太小导致恢复后数据消失。数据加载进去没问题但实例启动后立刻触发内存淘汰dbsize几秒之内从几十万掉到几万。恢复前必须确认目标实例的内存规格不低于源实例。连接串没改业务还在连旧实例。这个听起来很傻但在紧急处置时极其常见。演练结束后做过一次统计五个团队里有三个没有整理过“连接串切换”的操作清单。备份文件本身是空的。BGSAVE失败、磁盘写满、权限问题都可能留下一个 0 字节文件。所以备份脚本必须在生成之后检查文件大小和可用性校验不通过就告警而不是默默地“备份成功”。6. 把配置落到文件里一套可以直接套用的灾备参数清单讲了这么多最后把参数整理成可以直接放进配置文件的样子。下面这套是我在多个环境里用下来比较稳的基线具体数值需要按实例规格和业务特征调整。6.1 主库配置基线# 持久化 - AOF appendonly yes appendfsync everysec no-appendfsync-on-rewrite yes aof-use-rdb-preamble yes aof-load-truncated yes aof-timestamp-enabled yes auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 512mb # 持久化 - RDB save 900 1 save 300 10 save 60 10000 rdbcompression yes rdbchecksum yes stop-writes-on-bgsave-error yes # 复制 repl-backlog-size 512mb repl-diskless-sync yes repl-diskless-sync-delay 5 repl-timeout 60 client-output-buffer-limit replica 1024mb 512mb 300 # 脑裂防护交易、计数类必配 min-replicas-to-write 1 min-replicas-max-lag 10 # 连接 tcp-keepalive 300 timeout 06.2 备份从库的差异化配置replica-read-only yes replica-serve-stale-data yes replica-priority 0 replica-announced yesreplica-priority 0保证它不会被哨兵选为主replica-serve-stale-data yes让它即使与主库失联也还能响应读请求方便做备份导出。6.3 上线前的灾备自检表检查项判据检查方式AOF 是否开启appendonly为 yesCONFIG GET appendonly最近一次快照是否成功rdb_last_bgsave_status为 okINFO persistenceAOF 重写是否健康aof_last_bgrewrite_status为 okINFO persistencebacklog 是否够用按写入速率估算CONFIG GET repl-backlog-size脑裂防护是否生效两个参数均已配置CONFIG GET min-replicas-*从库同步延迟master_repl_offset差值在毫秒量级INFO replication备份是否出过本机对象存储上有最近 24 小时的文件备份系统核对备份是否校验过有 MD5 记录且回读一致备份日志核对恢复演练是否近期做过90 天内至少一次演练记录连接串切换清单是否存在有文档且演练时用过文档核对这张表我一般放在值班手册的第一页。它不需要任何工具人工十分钟就能走完一遍但能挡掉绝大多数“配置写了但没生效”“备份做了但没人知道能不能用”的问题。一套完整的 Redis 灾备方案最终要回答的其实是三个问题数据最多能丢多少、多久能恢复、最后一份可用的离线数据在哪。这三个问题只要有任何一个答不上来方案就只能算完成了纸面作业。
