MySQL 主从复制的原理？
五个经典回答示范
原理三线程：主库 dump 线程推送 binlog；从库 IO 线程拉取写入 relay log；SQL 线程重放 relay log。关键参数与监控：Seconds_Behind_Master 延迟指标（注意它只反映 SQL 线程口径）；延迟原因常见三类——大事务（一个事务重放慢）、从库单线程重放瓶颈、网络与 IO 争抢。对策对应：拆事务、并行复制（MTS）、资源隔离。
我讲一次延迟处理：大促期间从库延迟 40 分钟，读请求打到从库数据全是旧的。定位：Seconds_Behind 高但 IO 线程正常，SQL 线程重放堆积——中继日志堆积几个 G；根因是白天一批大事务批量 update 千万行。处置：紧急把关键读切回主库（加限流保护），大事务改分批夜间执行；中期开并行复制 slave_parallel_workers=8 加 WRITESET 并行度。复盘：大事务管控进 DBA 规范，延迟告警分级（300 秒警告 1800 秒严重）。
资深视角：复制体系的设计维度。可靠性——半同步复制权衡（after_sync 防主从数据丢失窗口）与无损配置；一致性——读写分离下的会话一致性：Critical 读走主库或 GTID 等待位点（wait_for_executed_gtid_set）；拓扑演进——主从到半自动切换（Orchestrator/MHA 类）：故障转移的脑裂防护与新主数据补偿；GTID 的价值：故障切换与搭建从库的位点管理从手工变自动。复制不只是备份，是高可用与读扩展的地基。
追问『主从数据不一致怎么发现与修复』：pt-table-checksum 校验加 pt-table-sync 修复，定期跑进巡检；『从库只读怎么保证』：read_only 与 super_read_only（防止有 SUPER 权限账号误写）；『一主多从某个从库坏了怎么办』：GTID 重建最快——备份加位点自动对齐，避免手工猜位点的老办法。
『主从复制配好就不用管了，延迟看看 Seconds_Behind 就行，数据以主库为准不用校验，切换的时候手动改下 IP 就能切。』——点评：不校验的数据一致性是信仰问题——异步复制下静默不一致真实存在；手工切换在深夜故障时是灾难剧本，且无脑 promote 可能丢数据。
- 打开 模拟练习，选择「运维/DBA」方向，限时 3 分钟作答本题。
- 对照上方答题框架，逐点检查：哪些要素没覆盖、哪里表达啰嗦。
- 用自己项目的真实经历替换框架中的占位内容，重讲一遍并录音回听。
这类题在真实面试中常被追问细节，
建议进入限时模式练一遍。