系统架构 · 数据复制与持久化

场景 1 · 半同步静默降级三个月, 切主丢 47 秒订单 (事故排查)

机房网卡抖动 → 半同步等 ACK 超时自动降级异步, 无告警; 两周后主库宕机切主, 客户端已确认的写蒸发。监控补课:

# my.cnf: 半同步开启 + 超时 1s
plugin-load = "rpl_semi_sync_master=semisync_master.so"
rpl_semi_sync_master_enabled = 1
rpl_semi_sync_master_timeout = 1000
# 监控必须盯的两个状态: 降级即告警
SHOW GLOBAL STATUS LIKE 'Rpl_semi_sync_master_status';  -- OFF = 已降级!
SHOW GLOBAL STATUS LIKE 'Rpl_semi_sync_master_no_tx';   -- 降级期异步提交笔数
-- 关键: no_tx 增长就报警 — 这段时间 ACKed 的写切主时可能蒸发

加告警后当月抓到 3 次降级, 每次都在 2 分钟内恢复半同步, 再没出现过切主丢写。

场景 2 · Redis 读写分离, 主挂瞬间独写 (min-replicas 底线)

主库与副本断链后仍在接受写, 切换回去就冲突。redis.conf 两条底线参数把"孤立主库"关进笼子:

# redis.conf: 主从 + 数据安全底线
replicaof 10.0.0.1 6379
min-replicas-to-write 1     # 健康副本 <1 时, 主库拒绝写
min-replicas-max-lag 10     # 副本延迟 >10s 不算健康
replica-read-only yes
# 关键: 没有 min-replicas-to-write, 主库失联副本后还在"独写"
# — 分区恢复后两份"主"数据对不齐, 只能人工比对

场景 3 · Kafka 支付消息单副本, broker 重启丢 2 万笔 (正确用法模板)

topic 建成单副本 + acks=1, broker 重启丢日志段。不丢消息的最低配三件套, 一次配齐:

# producer 侧: ISR 全部确认才算成功
acks=all
enable.idempotence=true          # 幂等生产者, 重试不重复
retries=2147483647
delivery.timeout.ms=120000
# broker/主题侧: 3 副本, 至少 2 个在 ISR 才可写
replication.factor=3
min.insync.replicas=2
# 关键: acks=all + rf=3 + min.insync.replicas=2 — 少一个都可能丢
# ISR 不足 2 时生产者报 NotEnoughReplicasException, 这是保护不是故障

场景 4 · 断电后库起不来? WAL 恢复演练日每年省一次大事故

把"崩溃恢复"变成年度演练: 在 staging 真停电一次, 量出真实 RTO 与日志重放行为:

# PostgreSQL 崩溃恢复演练: 模拟断电 (不走正常 shutdown)
pg_ctl -D /data/pg stop -m immediate
pg_ctl -D /data/pg start
# 观察日志 — 这两行就是 WAL 在救你:
# LOG: database system was interrupted; last known up at ...
# LOG: database system was not properly shut down; automatic recovery in progress
# 关键: 演练记录恢复耗时 = 真实 RTO; 双 1 配置与省 IO 配置分别测一遍

场景 5 · 3-2-1 备份用脚本管起来: 份数 / 介质 / 异地 (部署型)

单机单介质备份在机房级事故面前等于零。每日全量 + 异地对象存储, 账号最小权限:

# 每日: xtrabackup 全量到本地 → rclone 到对象存储 (另一介质+异地)
xtrabackup --backup --target-dir=/backup/$(date +%F) --parallel 4
rclone copy /backup/$(date +%F) oss:db-backup/$(date +%F) --transfers 8
# 保留策略: 本地 7 天 / 异地 35 天; 每月 staging 真恢复一次
# 备份账号只给最小权限 — 备份文件能拖库, 账号也能拖库
# 关键: 3 份、2 种介质、1 份异地 — 任何一条缺失都不叫 3-2-1

场景 6 · DBA 误删表, 1 小时前的延迟从库救了全公司

误删后 binlog 已 purge, 常规恢复只能回天到昨晚备份; 专用延迟从库把 RTO 从"彻夜奋战"变 10 分钟:

-- 专用延迟从库: 故意落后 3600s, 专治误删/误 UPDATE
CHANGE REPLICATION SOURCE TO SOURCE_DELAY = 3600;  -- 8.0.22+ (旧名 MASTER_DELAY)
-- 事故时: 停复制保住现场 → 从延迟库回灌误删的表 → 恢复制
STOP REPLICA;
-- 关键: 延迟从库不接任何读流量, 只当"时间机器"
-- → 1h 内的误删, 比翻 binlog 逐事务前滚快一个数量级

场景 7 · 快照 + binlog 串成 PITR, 精确恢复到误删前 1 秒 (事故排查)

全量快照停在昨晚 23:00, 误删发生在今天 09:47 — 中间全靠 binlog 前滚, 停在事故点之前:

# 1) 恢复昨晚全量
mysql -h restore < full_20260925.sql
# 2) binlog 前滚, --stop-position 卡在 DROP 语句之前的 pos
mysqlbinlog --start-datetime="2026-09-26 09:00:00" \
  --stop-position=104857600 binlog.000451 | mysql -h restore
# 关键: pos 从 SHOW BINLOG EVENTS 里人工核对 DROP 前的位置
# 前提: 全量之后的所有 binlog 都在 — 没归档 binlog 就没有 PITR

场景 8 · 北京写上海读, 跨机房异步复制的取舍清单 (架构配置)

机房间 RTT 25ms, 半同步跨机房等 ACK 会拖死写性能; 三条底线把延迟和风险都锁住:

# 1) 半同步只在本机房内做: 跨机房等 ACK 会被 RTT 拖死写性能
rpl_semi_sync_master_wait_point = AFTER_SYNC   # 5.7+: 先落日志再等副本
# 2) 机房间 binlog 压缩传输 (8.0.20+)
binlog_transaction_compression = ON
#    旧版本用 slave_compressed_protocol=1 (8.0.23 起已废弃)
# 3) 跨机房 lag 单独告警: 本机房秒级, 机房间分钟级是常态, 阈值分开
# 关键: 机房间链路永远按"随时会断"设计 — 上海读服务要能独立降级

场景 9 · 延迟告警恒为 0, 用户却在骂"改完没生效" (监控型)

Seconds_Behind_Source 空闲时恒 0、大事务重放时不准, 告警形同虚设。用 pt-heartbeat 原理: 让数据自己报告延迟:

-- 主库每秒: 心跳表写入一个时间戳 (随 binlog 复制下去)
UPDATE heartbeat SET ts = NOW(6) WHERE id = 1;
-- 副本侧: 用"数据里的时间"与本地时钟做差 = 真实端到端延迟
SELECT TIMESTAMPDIFF(MICROSECOND, ts, NOW(6)) / 1000000.0 AS true_lag_sec;
-- 关键: 副本自报的秒数不可信 — 空闲时恒 0, 不代表它追得上突发写

场景 10 · __consumer_offsets 无限膨胀, log compaction 保住重建能力 (配置型)

offset 提交日志只增不减, 磁盘月涨 800GB; compact 让同 key 只留最新值, 且新消费者能重放出完整状态:

# Kafka 内部主题 __consumer_offsets: 必须紧凑, 否则提交日志无限涨
cleanup.policy=compact
segment.ms=86400000              # 段 1 天滚动, compact 以段为单位
min.cleanable.dirty.ratio=0.5    # 脏区过半才压, 默认值够用
delete.retention.ms=86400000     # tombstone 保留 1 天, 别设太短
# 关键: compact 让新消费者组重放全量 key 状态 — tombstone 被过早清掉, 状态就断代