设计社交系统的数据备份方案，比如冷备份和热备份，以及故障恢复流程，比如主库故障时如何切换到备库，如何保证数据一致性（比如日志同步）。

1) 【一句话结论】社交系统数据备份需结合冷备份（离线全量备份）与热备份（在线日志同步），通过日志（如WAL）保证备库数据一致性，故障时快速切换主备库，恢复流程需确保数据一致性与业务可用性，核心是“备份+日志同步+故障切换”三位一体，兼顾数据安全与系统可用性。

2) 【原理/概念讲解】老师讲解：

• 冷备份：指数据库服务停止后进行的备份，比如关闭MySQL实例，导出数据文件（如mysqldump或直接备份数据目录）。特性是备份时无数据写入，但恢复时需完整还原历史数据，适合定期全量备份（如每周一次）。类比：关掉电脑电源后备份硬盘，此时硬盘数据是静态的，恢复时需还原所有历史文件。
• 热备份：指数据库在线服务时进行的备份，依赖日志（如MySQL的WAL日志、PostgreSQL的WAL），备库实时读取主库日志并重放，保持数据同步。特性是备份期间不影响业务，但需处理日志同步的延迟和丢失风险。类比：边用电脑边用云同步软件，实时同步文件，可能存在几秒延迟或断网时的数据丢失。
• 故障恢复流程：当主库故障时，通过监控（如心跳检测、连接超时）检测到故障，触发切换，将备库提升为主库，应用主库故障前的日志（如补全未同步的日志），确保数据一致性。

3) 【对比与适用场景】

方案	定义	特性	使用场景	注意点
冷备份	数据库停止服务后，备份数据文件（如全量备份）	备份时无数据写入，恢复时需完整还原历史数据	定期全量备份（如每周），用于灾难恢复（DR）	恢复时间长，需停机
热备份	数据库在线时，通过日志（WAL）同步备库数据	备份期间不影响业务，需实时同步日志	日常增量备份，故障时快速切换（RTO低）	需处理日志延迟/丢失，备库负载高

4) 【示例】（以MySQL主从复制为例）：

• 冷备份：每周0点停止主库服务，执行mysqldump备份全量数据，或直接备份数据目录（如/var/lib/mysql）。
• 热备份：主库开启binlog_format=ROW，备库配置从库，实时同步binlog。
• 故障恢复：监控脚本检测主库连接超时，触发切换，将备库的slave模式改为master，应用主库故障前的binlog（补全last_position），更新主从配置。
  伪代码（故障切换）：

def check_master():
    try:
        conn = connect('master_host', 'user', 'pwd')
        conn.ping()
        return True
    except:
        return False

def failover():
    if not check_master():
        new_master = 'backup_host'
        apply_binlog(new_master)  # 应用剩余日志
        notify_app('switch to backup')  # 通知应用切换

5) 【面试口播版答案】（约90秒）：
“面试官您好，社交系统的数据备份方案需结合冷备份和热备份，通过日志同步保证数据一致性。冷备份是数据库停机后备份全量数据（如每周全量备份），用于灾难恢复；热备份是数据库在线时通过WAL日志同步备库，实时保持数据一致，适合日常增量备份。故障恢复流程中，当主库故障时，通过监控检测（如连接超时），快速切换到备库，应用主库故障前的日志（补全未同步的日志），确保数据一致性。具体来说，冷备份用于定期全量备份，热备份用于实时同步，故障时监控触发切换，日志同步保证数据一致，这样既能保证数据安全，又能快速恢复业务。”

6) 【追问清单】

• 问题1：日志同步时，主库故障导致备库未同步部分日志，如何处理？
  回答要点：通过补全last_position，应用剩余日志，确保数据一致性。
• 问题2：冷备份恢复时间较长，如何优化？
  回答要点：采用增量备份（如时间点备份），或使用快照技术（如LVM快照），减少恢复时间。
• 问题3：热备份中，日志同步的延迟如何控制？
  回答要点：通过调整复制延迟（如slave_parallel_workers），或优化网络，减少延迟。
• 问题4：多级备份（主-备-备）如何设计？
  回答要点：主库同步到第一级备库，第一级备库同步到第二级备库，通过日志链保证数据一致性，提高容灾能力。
• 问题5：故障恢复流程中，如何验证数据一致性？
  回答要点：定期进行故障恢复演练，验证流程的有效性。

7) 【常见坑/雷区】

• 坑1：热备份时未处理日志丢失，导致备库数据不一致。
  避免方法：启用binlog_format=ROW，避免格式化错误；定期检查日志同步状态。
• 坑2：故障切换时未考虑日志补全，导致数据不一致。
  避免方法：切换前检查last_position，应用剩余日志。
• 坑3：冷备份恢复时未检查数据一致性，导致数据丢失。
  避免方法：备份前执行checksum验证，恢复后验证数据。
• 坑4：备库负载过高，影响热备份同步。
  避免方法：配置备库的并行复制，或调整主库写负载。
• 坑5：未考虑故障恢复的验证，实际故障时恢复失败。
  避免方法：定期演练故障恢复流程。