一台数据库扛不住了？MySQL 主从复制搭建实录，附跳坑指南

站点流量上来后，读写全压在一台 MySQL 上，页面越来越慢，更闹心的是没备份没冗余，机器一挂全站完蛋。主从复制是数据库水平扩展的第一步：主库写、从库读，顺便从库就是一台热备。原理不难，就是主库把变更写进 binlog，从库拉回来重放。

第一步，主库开 binlog 并建复制账号：

# 主库 my.cnf [mysqld] 段
server-id = 1
log-bin = mysql-bin
binlog_format = ROW
 
# 建账号
CREATE USER 'repl'@'从库IP' IDENTIFIED BY '强密码';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'从库IP';
FLUSH PRIVILEGES;
 
# 记下此刻的日志位点
SHOW MASTER STATUS; -- 记住 File 和 Position 两个值

第二步，从库配置并启动复制：

# 从库 my.cnf [mysqld] 段
server-id = 2
read_only = 1
relay-log = relay-bin
 
CHANGE MASTER TO
 MASTER_HOST='主库IP',
 MASTER_USER='repl',
 MASTER_PASSWORD='强密码',
 MASTER_LOG_FILE='mysql-bin.000123', -- 上面记的File
 MASTER_LOG_POS=456789; -- 上面记的Position
START SLAVE;

验证看两个线程状态：

SHOW SLAVE STATUS\G
# 关键看三行，必须都是 Yes
# Slave_IO_Running: Yes
# Slave_SQL_Running: Yes
# Seconds_Behind_Master: 0 -- 延迟秒数

最常见的翻车点是 Slave_IO_Running 一直 Connecting：先查从库能不能连上主库 3306（防火墙和安全组），再核对账号密码和授权的来源 IP。另一个高频问题是复制中断报 1062 主键冲突，通常是主从两边都被人写过数据，紧急恢复可以 SET GLOBAL sql_slave_skip_counter = 1 跳过一条，但跳完必须查清数据是否一致，治标不治本。

应用层接上从库后记得一件事：复制是异步的，刚写完马上读的场景（比如用户改完资料刷新页面）要从主库读，不然用户会疑惑刚保存的数据怎么不见了。读写分离的业务边界想清楚，比搭复制本身更重要。(数据来源：MySQL官方手册)