什么是冷备、热备，暖备？

#中间件#面试八股

什么是冷备、热备，暖备？

结论先行：这三者按备机的就绪程度分档：冷备只有离线数据，恢复要重建环境；暖备（温备）环境就绪、数据准实时同步，但备机不接流量，切换需人工或半自动；热备数据实时同步、备机随时可接管，能做到秒级自动切换。本质是 RTO / RPO 与成本 的三档权衡。

1. 一张表看清三档

维度	冷备（Cold）	暖备（Warm）	热备（Hot）
数据状态	定期备份到对象存储/磁带	准实时同步（秒~分钟延迟）	实时同步（毫秒级）
环境状态	未部署，需临时创建	已部署，服务常驻但不接流量	已部署，随时接管
切换方式	人工，按手册重建	人工/半自动，改配置或切 VIP	自动探测 + 自动切换
RTO	小时~天	分钟~十分钟	秒级
RPO	上次备份点（小时~天）	秒~分钟	≈0
成本	最低（只花存储）	中（备机常驻，资源闲置）	最高（双份资源，甚至双活）
典型场景	归档、合规、误删恢复	核心库的灾备、灰度验证	支付、网关、注册中心

2. 三档的"就绪度"示意

   冷备                     暖备                        热备
┌──────────┐          ┌──────────────┐            ┌──────────────┐
│ 备份文件  │          │  备机（运行）  │            │  备机（运行）  │
│ 在 OSS   │          │  服务已启动    │            │  实时同步     │
│ 环境未建  │  ──►     │  数据追平     │   ──►      │  健康探测通过  │
│ 恢复需重建 │          │  不接流量     │            │  秒级接管     │
└──────────┘          └──────────────┘            └──────────────┘
   RTO 小时级              RTO 分钟级                  RTO 秒级

3. 冷备：便宜，但要能真恢复

冷备的关键不是"备份成功"，而是恢复演练。没演练过的备份，等于没有备份。

# 每日全量 + binlog 增量，是最常见的冷备组合
mysqldump --single-transaction --source-data=2 -A > /backup/full-$(date +%F).sql
mysqlbinlog --start-datetime="2026-03-01 00:00:00" mysql-bin.000123 > /backup/inc.sql

# 恢复：先全量，再回放增量到故障点
mysql < /backup/full-2026-03-01.sql
mysql < /backup/inc.sql

三个必查项：备份文件能否解压/导入、恢复耗时是多少（决定真实 RTO）、增量链是否完整（缺一个 binlog 就回不到故障点）。

4. 暖备：数据追平但不接流量

最典型的是 MySQL 主从 + 延迟从库：从库实时同步，但故意延迟一段时间，用于防误删。

# 备库 my.cnf
[mysqld]
server-id            = 2
relay-log            = relay-bin
read_only            = 1
super_read_only      = 1          # 连 super 用户也不能写，防误操作
log_slave_updates    = 1

# 需要防误删时，再起一个延迟从库
[mysqld]
server-id            = 3
relay-log            = relay-bin
read_only            = 1

-- 在延迟从库上执行：同步落后主库 3600 秒
STOP SLAVE;
CHANGE MASTER TO MASTER_DELAY = 3600;
START SLAVE;

SHOW SLAVE STATUS\G
-- 关注：Seconds_Behind_Master、Slave_SQL_Running、Retrieved_Gtid_Set

暖备的切换通常是人工确认 + 改配置：提升从库（STOP SLAVE; RESET SLAVE ALL; 并去掉 read_only）、切换应用连接串、校验数据。整个过程分钟级，但避免了自动切换在"网络抖动"上的误判。

5. 热备：自动探测 + 自动接管

以 keepalived 的 VRRP 为例，主备共享一个 VIP，主节点失联后备节点在几秒内抢到 VIP：

vrrp_instance VI_1 {
    state BACKUP               # 两台都配 BACKUP，靠 priority 决定
    interface eth0
    virtual_router_id 51
    priority 100               # 备机 90，主挂后备机升为 MASTER
    advert_int 1
    authentication { auth_type PASS; auth_pass secret }
    virtual_ipaddress { 10.0.0.100/24 }
    track_script { chk_mysql } # 自定义健康检查，避免"机器活着但服务死了"
}

关键点在 track_script：如果只探测主机存活，进程假死（连接池耗尽、GC 停顿）时不会切换。热备必须探到业务可用性（能否执行一条 select 1），而不是 ping 通。

6. 怎么选

系统等级	建议	理由
内部工具、报表	冷备 + 每周演练	停几小时可接受
核心交易库	暖备（同城）+ 冷备（异地）	平衡成本与 RTO，误删可回退
支付网关、注册中心	热备（多副本自动切主）	秒级不可用即资损
强监管业务	异地多活	RPO 要求接近 0 且要地域级容灾

7. 常见追问

Q：备机常年闲置，是不是浪费？ 是。常见的补救是把暖备用于只读流量、报表查询、影子流量验证——既压测了备机可用性，又不影响主库。但注意别让读流量把备机打挂，切换时反而不可用。

Q：双活算热备吗？ 不完全。热备通常是 active-passive（备机待命），双活是 active-active（都接流量）。双活可用性更高，但要求数据同步与冲突处理到位，复杂度上一个台阶。

Q：RPO = 0 怎么做到？ 只能同步复制（如 MySQL 半同步 rpl_semi_sync_master_enabled=1、组复制 MGR），代价是写延迟增加、可用性受副本数约束。异步复制最多做到"秒级 RPO"。

Q：冷备还有必要吗？ 有。热备防的是"机器/机房故障"，防不了"逻辑错误"——误删表、错误发版。延迟从库和冷备是最后一道回退手段，勒索软件场景下离线备份更是唯一解。

小结

冷备=只有数据（RTO 小时级），暖备=环境就绪数据追平但不接流量（分钟级），热备=实时同步可秒级接管。
备机就绪度决定 RTO，数据同步方式决定 RPO，两者共同决定成本。
冷备重在恢复演练，暖备重在数据校验与切换手册，热备重在探活要探到业务层。
逻辑错误只能靠冷备/延迟从库兜底，别以为上了热备就万事大吉。

笔记加载中…