主从复制的基本原理是什么？
MySQL 主从复制本质是基于二进制日志（binlog）的异步数据同步机制。主库将所有修改数据的 SQL 或行变更事件写入 binlog，从库通过 I/O 线程连接主库、拉取 binlog 内容并写入本地中继日志（relay log），再由 SQL 线程读取 relay log 并重放执行，从而保持数据一致。
主从延迟产生的常见原因及排查方法
主从延迟（Seconds_Behind_Master > 0）是高频考点。常见原因包括：
- 从库硬件性能弱于主库（如磁盘慢、CPU/内存不足）
- 大事务或长事务在主库执行，从库 SQL 线程串行回放耗时久
- 网络不稳定导致 I/O 线程拉取 binlog 不及时
- 从库上存在锁竞争（如表锁、MDL 锁）或慢查询阻塞 SQL 线程
- 开启了 binlog_format=STATEMENT 且含非确定性函数（如 NOW()、UUID()），导致从库执行结果不一致而跳过或重试
排查建议：先用 SHOW SLAVE STATUS\G 查看 Seconds_Behind_Master、Read_Master_Log_Pos、Exec_Master_Log_Pos 是否持续增长；再结合 SHOW PROCESSLIST 观察 SQL 线程状态（如 Waiting for table metadata lock）；必要时启用 slow query log 分析从库慢 SQL。
如何保证主从数据一致性？
MySQL 原生复制无法 100% 保证强一致性，但可通过以下方式提升可靠性：
- 设置 sync_binlog = 1 和 innodb_flush_log_at_trx_commit = 1，确保主库事务提交时 binlog 和 redo log 都落盘
- 使用 半同步复制（semi-sync replication），要求至少一个从库确认收到并写入 relay log 后主库才返回成功
- 避免在从库写入（只读模式：set global read_only=1；注意 super 权限用户仍可写，需配合 super_read_only=1）
- 定期用 pt-table-checksum 工具校验主从数据差异，配合 pt-table-sync 修复
主库崩溃后如何安全切换到从库？
切换前必须确认从库已追平主库（Seconds_Behind_Master = 0，且 IO/SQL 线程均为 Yes）。关键操作步骤：
- 在从库执行 STOP SLAVE，防止后续变动
- 检查 SHOW SLAVE STATUS\G 中的 Master_Log_File 和 Read_Master_Log_Pos，记录当前同步位点
- 若原主库不可恢复，将该从库提升为新主库：RESET MASTER 清空自身 binlog 并开启新序列，再配置其他从库指向它
- 应用端需更新数据库连接地址，建议配合 VIP 或中间件实现自动故障转移
注意：切勿在主库未完全宕机时盲目切换，否则可能引发双写或数据覆盖。
