1. 环境准备与总体架构设计1.1 为什么选CentOS 7 MySQL 8.0.35这套组合先聊点实在的。MySQL 8.0已经发布好几年了很多线上业务还在用5.7但新部署的系统直接上8.0已经是共识尤其8.0.35这个版本修复了不少已知问题稳定性上比早期8.0版本成熟得多。CentOS 7虽然进入了维护周期的尾段但存量服务器数量极大生产环境里大量机器还在跑CentOS 7短期内不可能全部迁移。所以CentOS 7 MySQL 8.0.35这套组合在现网依然有很高的实际需求。如果你手头正好有一批CentOS 7的虚拟机或物理机想搭一套主从复制又不想每次靠记忆敲命令、查文档那这篇SOP就是给你准备的。它解决的核心问题是如何用一套可重复、可校验、出故障能快速定位的标准流程在CentOS 7上把MySQL 8.0.35的主从复制一次搭通。1.2 主从复制架构与规划主从复制的本质是主库把binlog二进制日志推送给从库从库把接收到的binlog事件重放到自己的数据文件里。这里有两个关键组件IO线程负责从主库拉取binlog并写入从库的中继日志relay logSQL线程负责从中继日志读取事件并执行。理解这两个线程后面排查问题会轻松一半。在开始动手前先把架构规划好角色主机名建议IP规划示例端口server-id主库Masterdb-master192.168.10.1033061从库Slavedb-slave192.168.10.1133062注意几个规划要点server-id在整个复制拓扑中必须全局唯一这是硬性要求两台机器如果server-id相同从库启动复制后会直接报错建议提前把防火墙、SELinux的处理方式想清楚免得搭到一半发现主库3306端口根本访问不通。2. MySQL 8.0.35的安装与初始化2.1 安装方式选型Yum仓库vs二进制包CentOS 7上安装MySQL 8.0.35主流有两种方式用官方Yum仓库安装或者用通用二进制包手工部署。Yum方式胜在简单、依赖自动解决二进制方式胜在路径可控、便于大规模标准化交付。作为SOP我更推荐Yum仓库方式。理由很简单它把MySQL的systemd服务脚本、默认配置文件、数据目录初始化都封装好了出错概率最低适合作为标准流程沉淀。你要是做二进制包部署还得自己去官网下载tar包、解压、初始化数据目录、写systemd脚本环节越多越容易出岔子。先配Yum仓库# 下载官方仓库rpm包 wget https://dev.mysql.com/get/mysql80-community-release-el7-7.noarch.rpm # 安装仓库配置 rpm -ivh mysql80-community-release-el7-7.noarch.rpm # 刷新缓存 yum clean all yum makecache # 安装MySQL社区版 yum install -y mysql-community-server装完之后验证版本确认拿到的是8.0.35mysqld --version正常情况下输出类似mysqld Ver 8.0.35 for Linux on x86_64。2.2 初始化数据目录与安全配置CentOS 7的Yum安装方式启动服务前数据目录会自动初始化。直接启动服务即可systemctl start mysqld systemctl enable mysqld启动后MySQL会自动生成一个临时root密码写在日志文件里grep temporary password /var/log/mysqld.log拿到临时密码后第一件事是改root密码并完成安全初始化。这里有个坑要提醒MySQL 8.0默认的密码校验策略是validate_password插件生效状态要求密码至少8位、包含大小写字母数字和特殊字符。你要是图省事设一个简单密码直接会被拒绝。mysql -uroot -p进入MySQL后执行ALTER USER rootlocalhost IDENTIFIED BY YourStrongPass2024; -- 退出后执行安全加固脚本 mysql_secure_installation安全脚本会一步步问你是否修改root密码、是否删除匿名用户、是否禁止root远程登录、是否删除test库、是否刷新权限表。生产环境全部选Yes就对了。3. 主库配置与复制用户创建3.1 主库核心参数详解主库配置文件在/etc/my.cnf编辑前先备份一份原文件这是个好习惯。在[mysqld]段下加入以下参数[mysqld] server-id 1 log-bin mysql-bin binlog_format ROW binlog_row_image FULL gtid_mode ON enforce_gtid_consistency ON log_replica_updates ON max_binlog_size 512M binlog_expire_logs_seconds 604800逐个解释一下这些参数的作用和理由server-id 1是复制拓扑中的唯一标识主从必须不同取值范围1到4294967295。log-bin mysql-bin开启二进制日志这是主从复制的数据源头。没有binlog从库一点数据都拿不到。8.0版本默认就是开启的但写成显式配置更清晰。binlog_format ROW设置binlog格式为行级。MySQL 8.0官方推荐使用ROW格式它的优点是不管delete、update怎么复杂记录的都是每行数据的变化结果不会出现STATEMENT格式那种函数执行结果不一致的问题复制一致性最强。gtid_mode ON和enforce_gtid_consistency ON这两行是关键。GTID全局事务标识符是每个事务的唯一ID做了标准UUID加序列号的组合。开启GTID后从库可以用GTID自动定位复制位点不再依赖binlog文件名加偏移量POS这种脆弱的定位方式。搭新环境直接用GTID这是8.0时代的推荐做法。log_replica_updates ON默认开启它允许从库把应用过来的事务也写进自己的binlog这样从库可以作为更下层从库的主库做级联复制时必须要这个参数。binlog_expire_logs_seconds 604800表示binlog保留7天单位是秒。这个值可以按需调整但它控制着如果主库宕机、从库很久没同步binlog被清理掉从库就得重新全量备份同步代价很大。配置完成后重启MySQL使参数生效systemctl restart mysqld然后登录MySQL验证参数是否已加载SHOW VARIABLES LIKE server_id; SHOW VARIABLES LIKE log_bin; SHOW VARIABLES LIKE gtid_mode;3.2 创建复制专用账号复制账号不要用root最小权限原则是运维的基本素养。专门创建一个用户只给复制的权限CREATE USER repl% IDENTIFIED WITH caching_sha2_password BY ReplPass2024; GRANT REPLICATION SLAVE ON *.* TO repl%; FLUSH PRIVILEGES;这里重点说一个MySQL 8.0的坑8.0默认的认证插件是caching_sha2_password不是以前5.7时代的mysql_native_password。这个新认证插件默认情况下在非SSL连接中不允许明文密码传输从库连接主库时第一次握手交换公钥会有点讲究。如果你在从库执行CHANGE MASTER TO之后IO线程连不上主库大概率就是这个认证方式在作怪。解决办法有两个一是从库配置CHANGE MASTER TO时加GET_MASTER_PUBLIC_KEY 1参数二是创建用户时显式指定mysql_native_password不过MySQL 9.0开始已经把这种认证方式移除了推荐用第一种办法。这篇SOP里用第一种方案后面会讲到。3.3 主库数据一致性备份导出从库要成为主库的副本前提是它先有一份与主库一致的数据。数据备份导出用mysqldumpmysqldump -uroot -p \ --single-transaction \ --master-data2 \ --all-databases \ --routines \ --triggers \ --events \ master_backup.sql参数含义解释一下--single-transaction在InnoDB引擎下利用事务隔离级别的一致性快照备份过程中不会锁表业务可以继续读写在线备份必备。--master-data2会在备份文件里记录下备份那一刻主库的binlog文件名和POS位点注释形式写在文件头部。以前用POS方式做复制时你必须从备份文件里翻出这行信息现在用GTID虽然不需要手动记位置但这个参数依然建议加上方便在极端情况下列位点对照。--all-databases备份所有库。注意MySQL 8.0的系统库mysql库里包含user表备份它能保证从库也有同样的账号密码体系。如果不想迁移账号也可以用--databases指定业务库然后单独建账号。备份文件生成后把它传到从库机器上scp master_backup.sql root192.168.10.11:/root/4. 从库配置与复制链路建立4.1 从库参数配置从库的/etc/my.cnf配置与主库大同小异关键差异在server-id和几个复制相关的参数[mysqld] server-id 2 log-bin mysql-bin binlog_format ROW binlog_row_image FULL gtid_mode ON enforce_gtid_consistency ON log_replica_updates ON relay_log mysql-relay-bin skip_replica_start ON max_binlog_size 512M binlog_expire_logs_seconds 604800relay_log mysql-relay-bin制定中继日志文件名前缀。中继日志是主从复制的中间地带IO线程把binlog拉到本地后先写到这里SQL线程再从这读。skip_replica_start ON这句是个人强烈建议加上的。它的含义是MySQL服务启动后不要自动开始复制线程。不加这个参数如果从库重启后自动连主库但你还没把数据和位点对齐就开始复制大概率会报错。先手工确认状态、再手动启动流程更可控。配置好以后重启从库MySQL然后开始导入主库的备份systemctl restart mysqld # 导入备份数据 mysql -uroot -p /root/master_backup.sql导入过程中留意终端输出通常不会有太多交互信息。导入时间取决于备份文件大小几百MB到几个GB的文件可能要几分钟到几十分钟耐心等待即可。4.2 CHANGE MASTER TO与复制启动数据导入完成后配置复制链路。MySQL 8.0.23版本之后官方把START SLAVE更名为START REPLICA但SLAVE关键字依然兼容可用。SOP里我统一用新写法CHANGE MASTER TO MASTER_HOST 192.168.10.10, MASTER_PORT 3306, MASTER_USER repl, MASTER_PASSWORD ReplPass2024, MASTER_AUTO_POSITION 1, GET_MASTER_PUBLIC_KEY 1;参数逐条说明MASTER_AUTO_POSITION 1告诉从库使用GTID自动寻找同步位点。它会读取主库的gtid_executed集合自动跳过已经执行过的事务极大简化了位点对齐的过程。而老办法要手动指定MASTER_LOG_FILE和MASTER_LOG_POS最怕备份后主库binlog有变化导致位点错乱GTID方案下这些烦恼基本消失了。GET_MASTER_PUBLIC_KEY 1对应前面讲的caching_sha2_password认证。它让从库在建立连接时向主库请求RSA公钥用于加密传输密码。不加这个参数IO线程会卡在认证阶段。执行完后启动复制并查看状态START REPLICA; SHOW REPLICA STATUS\G关注输出中的几行关键信息Replica_IO_Running: Yes Replica_SQL_Running: Yes Retrieved_Gtid_Set: ... Executed_Gtid_Set: ... Seconds_Behind_Master: 0Replica_IO_Running和Replica_SQL_Running都必须是Yes缺一个都是问题。Seconds_Behind_Master表示主从延迟秒数新搭建完成后正常是0如果这个值是负数或不断增长说明同步有积压了。4.3 复制状态的日常监控方法搭建完成后别急着收工。日常运维里你需要在从库上定期观察复制健康度。我习惯用一个SQL把关键信息一次拿出来SELECT VARIABLE_VALUE AS IO线程状态 FROM performance_schema.global_status WHERE VARIABLE_NAME Replica_running; SHOW REPLICA STATUS\G更实际的方式是写一个监控脚本把Seconds_Behind_Master超过阈值就告警的逻辑固化下来。这里分享一个简化版的Shell检查思路#!/bin/bash # 检查从库IO和SQL线程状态 IO_STATUS$(mysql -uroot -p密码 -e SHOW REPLICA STATUS\G | grep Slave_IO_Running: | awk {print $2}) SQL_STATUS$(mysql -uroot -p密码 -e SHOW REPLICA STATUS\G | grep Slave_SQL_Running: | awk {print $2}) if [ $IO_STATUS ! Yes ] || [ $SQL_STATUS ! Yes ]; then echo 错误复制线程异常 exit 1 fi5. 主从同步验证与问题排查实录5.1 端到端同步验证步骤复制链路启动成功不代表万事大吉。一定要做一次端到端的同步验证。我的习惯是建一个测试库、建一张测试表在主库插入几条数据然后到从库上查。主库执行CREATE DATABASE test_sync; USE test_sync; CREATE TABLE t_user ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50), created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); INSERT INTO t_user(name) VALUES (chenyi), (wangfang), (liuyang);过几秒到从库查询USE test_sync; SELECT * FROM t_user;如果能看到三条记录说明复制链路是通的。为了验证DDL和DML都能同步可以再更新、删除各测一遍。如果这些都正常这套主从的基础功能就算真正落地了。5.2 高频故障排查速查表搬运一下我踩过的坑列表。按故障频率排序故障现象常见原因解决办法IO线程显示Connecting连不上主库3306端口被防火墙拦截或主库监听的是内网IP检查firewalldfirewall-cmd --add-port3306/tcp --permanent后重载netstat -tlnp确认mysqld监听地址IO线程报认证插件错误主库用户是caching_sha2_password从库未指定公钥CHANGE MASTER TO补上GET_MASTER_PUBLIC_KEY 1SQL线程报Cannot execute statementbinlog_format不是ROW某些DML含函数或不确定操作主库设置binlog_formatROW重启重新导出导入数据复制报server_id冲突主从server-id相同改从库server_id重启mysql启动复制直接报错The server is not configured for GTIDgtid_mode不是ON检查主从两侧gtid_mode和enforce_gtid_consistency配置主从数据初始不一致导致复制中断导入备份前从库已有业务数据或备份不完整清空从库数据重新用--all-databases做全量备份导入这里面最让我印象深刻的是认证插件那个坑。第一次搭建8.0主从的时候IO线程一直报错看日志里写着Authentication plugin caching_sha2_password cannot be loaded当时第一反应是主库的plugin文件有问题查了一圈才发现是连接建立时公钥交换的问题。后来尝试了很多方法最后就是加上GET_MASTER_PUBLIC_KEY参数解决的。那段排错经历之后凡是涉及MySQL 8.0的复制SOP我都会把这个参数写进去算是给后来者省几步弯路。5.3 主从延迟排查思路Seconds_Behind_Master过大是运维群里被问烂的问题。结合经验说一下排查方向如果延迟持续增加且SQL线程繁忙检查从库是否在大事务或DDL执行中大表ALTER TABLE会阻塞复制很久。如果从库硬件性能远弱于主库延迟是常态考虑升级从库配置或拆分到多从库分担读压力。如果从库上有低频的慢查询锁表也可能挡住SQL线程的DML执行。可以用SHOW PROCESSLIST看SQL线程是否处于Waiting for table metadata lock状态。复制延迟的另一个隐藏原因是不建议在主库上执行长时间未提交的事务事务持锁的时间同样会影响从库应用速度这点和从库配置本身关系不大。6. 从SOP到生产级高可用的思考主从复制搭好只是打好了基础。生产环境里有几件后续工作建议同步考虑主库宕机时如何手动切换先确定从库数据追上主库Seconds_Behind_Master0再在从库执行STOP REPLICA、RESET REPLICA ALL然后让应用指向从库。这个过程建议配合VIP或代理层来做提前演练切换脚本。定时备份不能因为有了主从而松懈从库也建议挂上周期性全量备份任务主从复制不是备份的替代品误删数据的话复制会把误删动作也搬到从库。考虑引入半同步复制rpl_semi_sync来降低主从切换时的数据丢失风险。MySQL 8.0.35已经内置了半同步插件开启方式是安装插件、设置rpl_semi_sync_master_enabled和rpl_semi_sync_slave_enabled变量并在主从都配置相关的动态参数。半同步的代价是写性能有一定损耗取舍看你业务对数据安全的要求。说一下我个人在实际操作中的体会SOP的意义不只是一份命令清单更是一个排错的知识库。真正有价值的不是那几条复制命令而是为什么这样配以及出了问题到哪里看。第一次照着这篇流程搭一套大概半小时能完成搭过两三次之后你会发现真正花时间的都在异常排查上而一个好的SOP能把排查时间从几小时压缩到几分钟。这套主从环境配好之后后续的进阶操作比如级联复制、读写分离中间件对接、MHA或Orchestrator这类高可用管理工具都是在“能稳定同步”这个地基上长出来的。