主备架构核心是控制影响范围而非零中断，采用“读写分离+异步复制+健康探活+应用路由”四层联动模式：报表查询走只读副本，主库仅处理etl与元数据；通过逻辑复制或物化视图实现异步同步；每30秒探活并连续3次失败则标记不可用；api网关自动路由与熔断。
主备架构的核心目标不是完全消除故障，而是控制影响范围
SQL报表系统对数据一致性、查询响应和可用性有强依赖，但报表本身通常容忍短时延迟或少量重复/缺失。因此主备设计重点不在“零中断”，而在于：故障时快速降级、避免单点雪崩、保障核心报表可查、切换过程不引发数据错乱。盲目追求秒级切换反而可能引入事务中断、缓存不一致等新问题。
推荐采用“读写分离 + 异步复制 + 健康探活 + 应用路由”四层联动模式
不依赖数据库原生主备（如MySQL MHA、PostgreSQL Patroni）做全自动切换，而是将控制权部分上移到应用与中间层：
- 读写分离：所有报表查询走只读副本，主库仅承接ETL写入和元数据变更；报表服务启动时通过配置或注册中心加载当前可用只读节点列表
- 异步复制：主库到各报表副本使用逻辑复制（如Debezium + Kafka）或物化视图同步，规避主从延迟导致的“查不到刚生成报表”的问题；副本间不互连，降低故障传播风险
- 健康探活：每30秒向各副本执行轻量SELECT 1 + 检查pg_stat_replication（PostgreSQL）或show slave status（MySQL），失败连续3次标记为不可用
- 应用路由：报表API网关内置简单负载策略（如轮询+熔断），当某副本不可用时自动剔除，无需重启服务；支持按报表类型打标（如“实时类”强制走延迟
主备切换必须区分“计划内”和“非计划”两类场景
两者触发条件、操作粒度和回滚机制完全不同：
- 计划内切换（如版本升级、硬件维护）：提前通知报表服务进入“只读维护窗口”，停止新任务调度；等待所有运行中查询完成、ETL批次落库后，手动触发主库切出、指定副本升主；切换后验证关键报表SQL执行成功率与耗时基线
- 非计划故障（如主库宕机、网络分区）：不主动升主，仅将写入链路（ETL任务）切换至备用写入通道（如Kafka重放队列+离线补数脚本），报表层维持多副本只读服务；待主库恢复后，通过比对binlog位点或时间戳补全缺失数据，再择机回归主写
必须规避三个典型反模式
这些做法在压测或小流量下看似可行，上线后极易引发连锁故障：
- 跨机房双主写入：报表ETL任务分散在多地触发，未做全局幂等或冲突检测，导致同一张汇总表被不同主库覆盖，数据静默损坏
- 依赖VIP漂移自动切换：应用直连VIP，故障时靠Keepalived漂移；但报表查询常带长连接、连接池复用，VIP切换后旧连接仍发往原地址，出现大量超时或脏读
- 无灰度的全量切换：新副本上线即全量导入流量，未设置10%灰度比例观察慢SQL、锁竞争、内存溢出等隐性问题，导致整体查询RT翻倍甚至OOM
关键指标监控要聚焦“业务可感”维度，而非纯数据库指标
DBA关注的“复制延迟
- 各副本上最近1小时“TOP 20报表SQL”的平均执行时间波动（环比±20%告警）
- 用户触发的“导出Excel”类操作成功率（低于99.5%触发副本健康检查）
- ETL写入主库后，对应报表表在各副本中首次可查的时间差（超过SLA阈值如60s则标记该副本为“高延迟”并限流）
- 报表服务JVM中Active Connection数突增且持续>5分钟（预示连接泄漏或慢查询堆积）
