业务单台MySQL总怕宕机丢数据？2026手把手教你配置主从复制提可用性

先说说楼下团队当时踩的前置坑，别不信，真的80%的新手一开始都会犯。第一个是主库服务器没有开binlog，第二个是两台服务器的server-id居然都是默认的1，还有一个更离谱的——主从库的时区居然不一样，导致同步后订单的下单时间差了八个小时，差点以为是遇到恶意刷单了。

前置检查得先做扎实，这是我这6年踩了无数坑出来的第一步。首先看主库有没有开启binlog，直接用root用户登录MySQL敲命令：show variables like ‘log_bin’; 如果显示的Value是OFF，那得赶紧去改配置文件。这里默认大家用的是CentOS 7或者Ubuntu 22.04这类主流的稳定版，配置文件路径分别是/etc/my.cnf（CentOS）和/etc/mysql/mysql.conf.d/mysqld.cnf（Ubuntu）。

然后给两台服务器设置唯一的server-id，这个值范围是1到2^32-1，别偷懒用默认的1或者2，用服务器内网IP的最后两位或者后三位拼接，比如主库IP是192.168.1.10，server-id就设1010，从库是192.168.1.20，就设2020，这样以后加新从库也不会冲突。

时区这个问题也不能忽略，尤其是做跨境或者涉及时间统计的业务，统一用UTC+8的上海时区，MySQL里敲命令set global time_zone = ‘+8:00’; 然后flush privileges; 重启一下MySQL服务确保生效。配置文件里也可以加上default-time-zone=’+8:00’，避免重启后又变回去。

前置检查没问题，接下来就开始主库的配置。先在主库的配置文件里加上这几行：

[mysqld]
server-id = 1010
log_bin = mysql-bin
binlog_format = ROW
binlog_do_db = test_db # 如果只需要同步特定数据库就加这行，多库的话加多行

这里一定要敲黑板，binlog_format别用默认的STATEMENT，ROW模式虽然占的磁盘空间大一点，但同步的是具体的行变更，出错的概率要低很多，中小团队生产环境下我个人直接选ROW。

配置改完后重启MySQL服务，CentOS用systemctl restart mysqld，Ubuntu用systemctl restart mysql。然后在主库上创建一个专门用来同步的用户，权限不能给太高，只给REPLICATION SLAVE就行，用户名叫slave_sync，密码设复杂一点，比如slave@2026_Sync！，敲命令：

CREATE USER 'slave_sync'@'192.168.1.%' IDENTIFIED BY 'slave@2026_Sync!';
GRANT REPLICATION SLAVE ON . TO 'slave_sync'@'192.168.1.%';
FLUSH PRIVILEGES;

这里注意@后面的IP段，要是你的从库在云服务器的同一内网下，就用内网IP段；要是跨云或者跨地域，就改成从库的公网IP，不过跨地域同步延迟会比较高，中小团队尽量不要这么做。

创建完同步用户，接下来要锁主库表，防止在导出数据的时候有新的写入，锁表命令是FLUSH TABLES WITH READ LOCK; 别锁完表就去干别的，这个锁如果断开连接就会自动释放，要保持当前的MySQL连接窗口别关，另外开一个终端窗口导出数据。

导出数据用mysqldump命令，记得加上single-transaction参数（适用于InnoDB引擎，现在基本都是InnoDB了），这样可以保证导出的是一致性数据，中小团队常用的数据库比如用户库、订单库，数据量一般不大，直接敲命令：

mysqldump -uroot -p single-transaction master-data=2 test_db > test_db_backup_20260520.sql

master-data=2这个参数很重要，它会在导出的SQL文件里自动加上CHANGE MASTER TO的注释，里面有主库当前的binlog文件名和Position，不用我们手动去查了，新手操作起来更方便。

数据导出完，就可以解锁主库表了，回到之前锁表的那个MySQL窗口，敲UNLOCK TABLES; 然后把导出的SQL文件传到从库服务器上，用scp命令就行：scp test_db_backup_20260520.sql root@192.168.1.20:/root/。

接下来是从库的配置。先在从库的配置文件里加上这几行：

[mysqld]
server-id = 2020
relay_log = relay-log
read_only = 1 # 开启只读模式，防止普通用户误写从库
super_read_only = 1 # 连超级管理员也不能写，除非手动关闭，更安全

read_only和super_read_only这两个参数，新手一定要加上，不然万一开发人员连错了从库，在上面写了数据，主从同步就会出错，修复起来特别麻烦。配置改完后重启从库的MySQL服务。

然后在从库上导入之前传过来的SQL文件，敲命令：mysql -uroot -p

-CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=154;

接下来在从库的MySQL里执行CHANGE MASTER TO命令，把刚才记下来的信息填进去，还有同步用户的用户名、密码、主库的内网IP，敲命令：

CHANGE MASTER TO MASTER_HOST='192.168.1.10', MASTER_USER='slave_sync', MASTER_PASSWORD='slave@2026_Sync!', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=154;

然后启动从库的同步进程，敲START SLAVE; 最后检查一下同步状态，敲SHOW SLAVE STATUSG; 注意这个命令后面要加G，这样显示的结果是竖排的，方便新手看。

看同步状态的时候，重点看两个参数：Slave_IO_Running和Slave_SQL_Running，这两个都要是YES才算同步正常，如果有一个是NO或者Connecting，就说明有问题，比如防火墙没开3306端口、同步用户的IP段不对、binlog文件名和Position填错了之类的，得根据具体的报错信息去排查。

楼下电商团队补完这个配置后，上周又做了一次主从切换演练，花了不到十分钟就切换完成了，现在他们终于不用再天天盯着主库的监控睡觉了。

你们在运维工作中有没有遇到过类似的主从配置踩坑经历？欢迎在评论区分享你的排查经验。