sql数据库主从复制通过binlog日志实现增量同步：主库记录写操作至binlog，从库IO线程拉取并写入relay log，SQL线程重放更新数据；推荐ROW格式、启用GTID，需避免从库写入，配合工具实现高可用。
SQL数据库的主从复制，核心是让一个或多个从库（Slave）实时或准实时地同步主库（Master）的数据变更，从而实现读写分离、负载分担、高可用与灾备。它不是简单拷贝文件，而是基于日志的增量同步机制。
主从复制是怎么工作的
主库把所有写操作（INSERT/UPDATE/delete等）记录到二进制日志（binlog）中；从库的IO线程连接主库，拉取这些binlog事件并写入本地中继日志（relay log）；SQL线程再读取relay log，重放其中的语句或事件，完成数据更新。
- binlog格式有STATEMENT、ROW、MIXED三种，推荐用ROW模式，避免因函数、时间戳等非确定性操作导致主从不一致
- 从库同步是单线程回放（mysql 5.6起支持多线程复制，但需按库或按事务组划分）
- 主从之间没有自动冲突检测和解决机制，写入从库会直接破坏复制链路
主从复制的典型应用场景
主从结构不是万能架构，但在以下场景中价值明确：
- 读写分离：应用层将select请求路由到从库，减轻主库压力，适合读多写少业务
- 数据备份与恢复：从库可作为热备节点，也可停机做逻辑备份（mysqldump）或物理备份（xtrabackup）
- 版本升级与维护：先升级从库，验证无误后再切换主从角色，降低停机风险
- 报表与分析：在专用从库上跑慢查询或etl任务，不影响主库在线业务
常见问题与关键注意事项
主从延迟、数据不一致、复制中断是高频痛点，根源常在配置或使用习惯：
- 主库开启binlog且设置唯一server-id；从库必须设不同server-id，否则无法启动复制
- 网络抖动、大事务、从库负载过高都会导致Seconds_Behind_Master持续增长，需监控并定位瓶颈
- 避免在从库执行写操作；若误操作，建议通过pt-table-checksum+pt-table-sync校验修复，而非手动改数据
- GTID（全局事务标识）能简化故障切换和位置追踪，MySQL 5.6+建议启用，但需主从统一开启
主从复制不是高可用的全部
主从本身不提供自动故障转移能力。主库宕机后，需人工或借助MHA、Orchestrator、proxySQL等工具完成选主、从库提升、客户端重定向等动作。真正的高可用方案往往是在主从基础上叠加编排与感知能力。
基本上就这些。机制不复杂，但细节容易忽略，尤其是权限配置、时钟同步、网络稳定性这些基础项，往往比调优更影响复制质量。