MySQL 主从复制搭建与延迟观察

主从复制是 MySQL 自带的同步机制：主库写入，从库实时重放，读请求可以分流到从库，也顺手多了一份实时热备。整套搭建只需要几个配置项和两条命令。 ## 一、主库三行配置 ``` [mysqld] server-id = 1 log_bin = mysql-bin binlog_format = ROW ``` 重启后用 SHOW VARIABLES LIKE 'log_bin%' 确认 binlog 已开启，ROW 格式记录行级变更，复制和恢复都更可靠。server-id 在复制拓扑里必须唯一，后续再加从库依次往下排，重号会导致复制关系错乱。 ## 二、建复制账号并取位点 ``` CREATE USER 'repl'@'10.0.0.%' IDENTIFIED BY '强密码'; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'10.0.0.%'; SHOW MASTER STATUS; ``` 记下输出的 File 和 Position 两个值，这是从库开始复制的起点。取位点选在业务低峰，从取位点到从库数据齐全之间主库照常写入，位点就是这段差异的起点。库不大的话，也可以用带 --source-data=2 的 mysqldump 导一份全量给从库，位点会自动写在文件里。 ## 三、从库启动复制 从库配置 server-id = 2，导入全量数据后执行： ``` CHANGE REPLICATION SOURCE TO SOURCE_HOST='10.0.0.10', SOURCE_USER='repl', SOURCE_PASSWORD='强密码', SOURCE_LOG_FILE='mysql-bin.000003', SOURCE_LOG_POS=157; START REPLICA; ``` 老版本语法是 CHANGE MASTER TO 加 START SLAVE，8.0.22 之后推荐上面这套新写法。然后验证状态： ``` SHOW REPLICA STATUS\G ``` Replica_IO_Running 和 Replica_SQL_Running 都是 Yes，复制就在正常工作。IO 线程负责拉日志，SQL 线程负责重放，只有 IO 线程在跑，通常是账号或网络的问题。 ## 四、延迟观察与处理 核心指标是 Seconds_Behind_Master，为 0 表示已追平。延迟升高常见三个原因：从库单线程重放跟不上写入（8.0 可调大 replica_parallel_workers 开并行）、单个事务太大（拆小批量提交）、从库磁盘性能差（换更好的盘）。长期延迟的从库既当不了读分流，也当不了热备，监控里要给它单独一条告警。从库的硬件别比主库差太多，重放是单点瓶颈，磁盘慢会长期追不平；大表加索引这类操作放低峰做，否则延迟瞬间飙到小时级。读分流先把报表、后台查询这类容忍延迟的流量切过去，实时性要求高的读留在主库，分级过渡比一刀切稳。 复制不是备份：误删数据的 DELETE 同样会被同步到从库。容灾归容灾，定期备份照旧要做。搭建当天补一份交接文档，主从 IP、复制账号、起始位点各记一行，半年后接手的人会需要它。