搞数据库的早晚会和“主从复制”这四个字打交道。MySQL里说的主从复制简单讲就是让一台从库持续跟随主库的数据变化主库负责写入从库负责同步和读取。很多人第一次接触这个概念觉得无非是把数据抄一份到另一台机器可真动手搭建时会发现server-id、binlog、relay log、GTID这些名词全部砸过来很容易踩坑。这篇内容是围绕“3.2主从复制概念及其搭建”这一节展开的完整实操笔记把主从复制的核心概念、环境准备、搭建步骤和故障排查完整走一遍适合刚学MySQL复制的同学也适合配好了却时不时报错的老手对照检查。1. 主从复制的核心概念与工作原理1.1 主从复制是“复制”不是“备份”先说一个最常见的误区。不少人在讨论主从复制的时候会把“复制”和“备份”混为一谈。从效果上看从库确实保存着主库的数据副本但复制这个动作的本质是持续地把主库上产生的变更同步到从库让从库成为主库的实时镜像而备份是定期把数据固化到某个时间点。主从复制解决的核心问题是读写分离、高可用切换、以及灾备演练这些高频需求而不是数据归档。打个比方主库像是一个不停接单的老板从库像是一个随时记录老板决定的事务助理。老板每做一个决定助理就抄下来保证自己和老板的信息一致。但助理手里的记录不能替代财务的月度报表因为报表需要的是一个时间点的完整账目而不是不断滚动的流水。理解了这一点你就不难理解为什么很多生产环境既要做主从复制还要做每日备份因为两者解决的问题不一样。从数据链路上看主从复制有一个很现实的约束它复制的是一段时间窗口内的变更而不是某个时间点的全量快照。所以从库的数据最终会追上主库但由于网络延迟、从库硬件性能或者大事务的影响从库的实时程度是相对的不可能是绝对零延迟。这也是为什么我们在搭建之前要先做初始数据同步把主库已有的数据整体搬到从库再让复制从某个位点继续否则从库追不上。初始同步的粒度要根据业务数据量决定数据量小直接mysqldump数据量大则要考虑Percona XtraBackup这类物理备份工具后者在停服务时间上有明显优势。不过这属于后续优化先把基础链路跑通更重要。1.2 一条写入语句在主从两端到底经历了什么理解了复制和备份的区别之后我们来看复制链路的核心机制。MySQL主从复制的底层依赖三个东西主库的二进制日志binlog、从库的中继日志relay log、以及从库上两个协作的复制线程。我把完整过程拆成下面几步讲。当主库执行一条INSERT、UPDATE或者DELETE时这条语句最终会写入主库的binlog。binlog记录的是一系列事件每个事件都对应一个文件位置Position位置由文件编号加偏移量组成比如mysql-bin.000001。这个位置信息在整个复制链路里非常关键因为从库就是从某个位置开始拉取数据的。从库上有两个线程IO线程和SQL线程。IO线程连接主库请求从指定的binlog文件位置开始读取日志拿到主库binlog的事件之后把事件原样写到从本地的relay log里。SQL线程再读取relay log把里面对应的事件一条一条地重放到从库上。所以一条主库的写入语句经过“主库binlog - IO线程拉取 - 从库relay log - SQL线程重放”这条链路最终落在从库的数据文件里。这里有个容易困惑的点很多人以为从库IO线程读取的是主库最后写入的数据其实它读的是主库的binlog事件流中间可能隔着网络延迟也可能隔着主库binlog的刷盘策略。换句话说从库看到的永远是主库“某一段时间之前”的状态。这也是为什么做主从复制时binlog的完整性和落盘策略非常重要如果主库binlog没刷完极端情况下从库可能丢失部分事件。1.3 三种复制形态怎么选原理通了之后还要知道复制并不只有一种模式。按主库在写入时对复制结果的要求MySQL复制可以分成异步复制、半同步复制和全同步复制它们在可用性和性能上的取舍完全不同。异步复制是最常见的默认模式。主库提交事务时只管写入binlog并返回成功不会等待从库确认。这种模式性能最好主库几乎感知不到复制的存在但缺点是如果主库在binlog尚未同步到从库时崩溃从库落后的事件就会永久丢失。很多对数据丢失容忍度较低的业务会在此基础上启用半同步复制。半同步复制的思路是折中主库在提交事务后至少要等待一个从库确认已经收到binlog事件才向客户端返回成功。这样做的好处是显著降低了数据丢失的概率代价是主库的提交延迟会受从库确认速度的影响。MySQL自5.7开始原生支持半同步复制生产环境单主多从架构里经常使用这种组合。全同步复制在传统MySQL主从架构里其实不原生支持更多出现在MySQL Cluster或者使用分布式数据库产品中原理是主库要等所有从库都提交成功才响应。全同步方案对一致性和可靠性要求极高但性能折损也最大。作为入门阶段的取舍我的建议是测试环境用默认异步复制先跑通流程生产环境如果对丢失容忍度低优先考虑半同步复制。2. 搭建前必须搞懂的关键参数与环境准备2.1 环境规划与版本选择正式动手之前一定要先把环境规划清楚否则中间改配置来回重启MySQL时间全浪费在折腾上了。我做这组实验用的是两台CentOS 7虚拟机分别安装MySQL 8.0主库192.168.56.101从库192.168.56.102。如果你本地只有一台机器也可以用Docker起两个MySQL容器把端口分开就行但不建议在生产里图省事用Docker直接做主从存储和网络环境都和物理部署有差异。版本选择上我推荐MySQL 8.0。一方面8.0是当前的主流长期支持版本另一方面8.0从默认参数上就更适合复制binlog默认是ROW格式对GTID的支持也更完善。如果你还在用5.7搭建步骤大同小异区别主要体现在创建复制账号的认证插件和某些参数命名上例如8.0.22之后CHANGE MASTER TO改成了CHANGE REPLICATION SOURCE TO我会在实操部分专门标注。两台机器的防火墙需要注意从库要能连通主库的3306端口至少确保主库对外放行MySQL端口。如果是云服务器还要注意安全组的入站规则。这个点看着基础但我在给朋友排查复制问题时遇到过不止一次因为云安全组只放行了应用服务器的IP漏掉从库IP导致IO线程一直重连的情况。2.2 主库配置server-id 和 binlog 缺一不可主库需要开启两个核心能力一个唯一的server-id一个binlog。开启binlog之后MySQL会把所有可能导致数据变更的语句记录到二进制日志文件里。打开主库的my.cnf或my.ini取决于操作系统在[mysqld]段下调整配置。[mysqld] server-id 1 log_bin /var/log/mysql/mysql-bin binlog_format ROW sync_binlog 1server-id是复制环境中每个实例的唯一标识主库和从库的值必须不同否则从库会报错说server id冲突。log_bin指定了binlog文件的目录和前缀这里写的是明文路径也可以用log_bin/data/mysql/mysql-bin。binlog_formatROW是MySQL 8.0的默认值但显式写出来可以避免版本差异带来的困惑。ROW格式记录的是每一条行数据的实际修改内容比STATEMENT格式记录SQL语句更精确能避免因为函数、存储过程等在不同机器上执行结果不一致的问题。sync_binlog1表示每次事务提交都强制把binlog同步到磁盘这是数据可靠性最稳的设置。改完之后需要重启MySQL服务。重启之后可以执行SHOW VARIABLES LIKE log_bin;确认binlog已开启再执行SHOW MASTER STATUS;查看当前binlog文件名和位置。这里输出的File和Position就是后面从库复制要用的起始点。2.3 从库配置relay log 和只读保护从库同样需要一个唯一的server-id但不需要主动开启binlog也可以用复制。不过生产环境里的从库经常要承担备份角色或者被其他从库级联同步所以一般也会把从库的binlog打开同时配置relay log。从库的my.cnf参考配置如下。[mysqld] server-id 2 log_bin /var/log/mysql/mysql-bin binlog_format ROW relay_log /var/log/mysql/mysql-relay-bin read_only 1read_only1的作用是让从库拒绝普通用户的写操作避免应用误连从库后写入数据导致主从数据不一致。但注意这里有个坑read_only对拥有SUPER权限的用户不生效也不影响复制线程本身。也就是说如果你手滑在主库执行了一条更新后果还是照样同步到从库如果你用超级用户登录从库执行更新同样也会写入。想要更严格地挡住超级用户在MySQL 8.0里可以再加上super_read_only1确保从库上非复制线程的写全部被拒绝。从库配置完成后也要重启MySQL然后确认server-id生效可以执行SHOW VARIABLES LIKE server_id;。有个容易漏的点MySQL里配置文件参数用的是下划线server_id如果你复制粘贴配置时不小心写成连字符server-id明明改了文件MySQL却不认这个参数折腾半天才发现。另外如果从库未来要给其他从库级联同步log_slave_updates参数也要打开否则从库重放后的变更不会写入从库自己的binlog下级从库就没法继续复制。这是很多级联复制环境里让人困惑的现象。2.4 为什么 binlog_format 要选 ROWbinlog格式的选择经常被新手忽略实际上它对复制的可靠性影响非常大。MySQL支持三种binlog格式STATEMENT、ROW、MIXED。STATEMENT格式直接把执行的SQL语句写进binlog简单粗暴日志量小。但问题是同一条SQL语句在从库重放时不一定产生和主库完全相同的结果。比如语句里用了UUID()、NOW()这类非确定性函数或者依赖了查询结果顺序主从就可能出现数据分叉。想想看一条INSERT语句在主库执行时插入的是2024年的日期复制到从库重放时又生成一次当前日期两边数据必然对不上。ROW格式记录的是每一行实际被插入、更新或删除后的值重放时按行应用从库的执行不依赖SQL上下文结果更可控。它的缺点是日志量比STATEMENT大尤其是大批量更新时binlog体积会明显膨胀。MIXED是两种格式的混合体MySQL会在判断语句有不确定性问题时切到ROW其余情况用STATEMENT。虽然8.0默认是ROW但我在生产实践中仍然建议显式固定为ROW避免某些环节触发MIXED判定逻辑时出现意外。3. 主从复制搭建实操全流程3.1 在主库创建复制专用账号环境准备好、两台MySQL都重启完成后就可以开始搭建了。第一步是在主库上创建复制专用账号后面从库的IO线程会拿着这个账号连接主库拉取binlog。账号权限不需要太大只需要REPLICATION SLAVE权限即可这是最小的权限集合符合安全最小化原则。MySQL 8.0默认的认证插件是caching_sha2_password如果直接用MySQL 5.7的老客户端连接可能因为不支持插件导致认证失败。为了兼容性更稳我习惯在创建复制账号时显式指定mysql_native_password尤其是在可能涉及跨版本或者第三方驱动的情况下。CREATE USER repl192.168.56.% IDENTIFIED WITH mysql_native_password BY YourPassword123; GRANT REPLICATION SLAVE ON *.* TO repl192.168.56.%; FLUSH PRIVILEGES;创建之后可以先用mysql -urepl -p -h主库IP试连一下确认网络和认证都通再继续后面的步骤。别嫌多这一步它可以把问题提前暴露如果这一步连不上后面的IO线程一定也连不上直接排查方向就是防火墙、账号权限或者认证插件而不是去翻日志。如果MySQL启用了validate_password组件创建账号时密码要满足策略要求否则会报错测试环境可以临时调整策略生产环境建议用一个合规密码。3.2 获取一致位点并导出初始数据复制不是空手套白狼如果从库上已经有业务数据或者主库本身有存量数据你必须先把主库的完整数据同步到从库否则从库从某个binlog位点开始追追到的只是一部分变更和已有数据拼不到一起去。举个例子你的主库有一个用户表里面有100万行数据如果你不导入这些数据只配置复制位点结果就是从库只拿到配置之后新增的几行整个用户表基本等于废的应用根本没法读。所以先同步数据是必须跨过的一道坎。获取一致位点最简单可信的方式是用mysqldump做一次全量逻辑备份同时让备份记录下当时正在写入的binlog文件和位置。关键参数是--master-data2它会把CHANGE MASTER TO的信息写到备份文件的头部。常见做法是这样的mysqldump -uroot -p --single-transaction --master-data2 --all-databases backup.sql--single-transaction参数利用InnoDB的MVCC机制在不锁表的情况下获得一致性快照适用于InnoDB表--master-data2既记录了位点信息又不会在导入时自动执行CHANGE MASTER。备份完成之后用grep看一下备份文件前面的注释部分你能看到类似这样的一行-- CHANGE MASTER TO MASTER_LOG_FILEmysql-bin.000003, MASTER_LOG_POS157;记下这个文件编号和位置号码到从库配置时要用。有一点要注意--master-data2生成的位点信息能够准确反映导出开始时主库的binlog位置但并不是固定不变的。如果你对备份生成过程中事务的影响没有把握可以在低峰期操作减少主库压力如果导出过程中主库产生了大量binlog从库启动后需要追的日志会更多但这不影响一致性因为位点已经在快照开始时固定所有快照之后产生的事件都能从该位点读到。3.3 在从库执行 CHANGE MASTER TO从库拿到备份文件之后先把数据导进来。导入前最好确认从库是个干净实例或者至少目标库没有冲突数据否则可能出现主键冲突之类的导入失败。mysql -uroot -p backup.sql数据导入完成之后执行复制配置。MySQL 8.0.22之前用CHANGE MASTER TO8.0.22及以后推荐用CHANGE REPLICATION SOURCE TO我下面写的是新版本命名同时注释里标注了旧版写法方便你用5.7或早期8.0版本时对照。CHANGE REPLICATION SOURCE TO SOURCE_HOST192.168.56.101, SOURCE_USERrepl, SOURCE_PASSWORDYourPassword123, SOURCE_LOG_FILEmysql-bin.000003, SOURCE_LOG_POS157, SOURCE_PORT3306;参数含义很清楚SOURCE_HOST是主库IPSOURCE_USER和SOURCE_PASSWORD是复制账号SOURCE_LOG_FILE和SOURCE_LOG_POS就是刚才从备份文件里读到的位点。执行完之后如果返回Query OK说明配置已经写入从库的元数据里但此时复制线程还没启动需要下一步手动拉起。如果执行后提示Unknown system variable很可能是把8.0.22之前的旧版参数名用在了新版上或者反过来。遇到这种情况先确认当前MySQL版本的文档命名再重新执行。另外SOURCE_LOG_FILE和SOURCE_LOG_POS如果填错从库能启动但会卡在IO线程找文件那一步所以这个位点要反复核对。3.4 启动复制线程并验证万事俱备只欠启动。在从库执行START REPLICA老版本是START SLAVE然后马上检查复制状态。START REPLICA; SHOW REPLICA STATUS\G重点看输出里的几个字段Replica_IO_Running老版本是Slave_IO_Running和Replica_SQL_Running老版本是Slave_SQL_Running正常情况下都应该是Yes。但更重要的其实是Last_IO_Errno、Last_IO_Error、Last_SQL_Errno、Last_SQL_Error这几个字段因为一旦出错真正能定位问题的就是这些错误信息而不是Running的状态。如果两个线程都显示Yes再看看Seconds_Behind_Master字段。它表示SQL线程执行到的relay log位置与IO线程拉取到的位置之间的时间差刚启动复制时这个值可能不是0因为从库需要先把主库复制开始之后继续产生的新变更追回来。等它稳定到0说明从库已经追平。验证读写分离效果也很简单在主库建个测试表插入几行数据然后去从库查能看到同样的数据说明复制链路正常。接着再试着做一个反向操作直接往从库写数据正常情况下会被read_only挡住这正好验证了只读保护生效。到这里一个最小可用的主从复制环境就算真正搭建完成了后续只要定期监控状态字段一般来说不会出大问题。4. 常见问题与故障排查实录4.1 三个状态字段决定了复制健不健康搭建过程中和日常运维里我会优先看SHOW REPLICA STATUS输出中的三个组合字段两个Running状态加一个Seconds_Behind_Master。它们组合起来能快速判断复制的健康程度。正常情况是三组都正常Replica_IO_Running是Yes、Replica_SQL_Running是Yes、Seconds_Behind_Master接近0。如果IO线程显示No通常意味着从库连不上主库或者主库的binlog已经被清掉从库找不到指定的文件或位置。如果SQL线程显示No大概率是relay log里有语句执行失败比如表结构不一致、主键冲突或者从库被read_only挡住了部分写入。这里有个必须要提的细节Seconds_Behind_Master显示0并不绝对代表从库和主库完全一致它只是一个估算值基于从库当前执行的relay log事件时间戳和主库IO线程拉到的最新事件时间戳算出来的。如果主库本身长时间没有写入这个值天然是0而实际的relay log可能已经在本地暂停等待了。所以判断复制健康还要结合业务写入频率来理解。提示我仍然建议每次搭建后执行一次STOP REPLICA再START REPLICA实际触发一次复制线程的完整重启确认没有隐藏的配置错误。很多问题在首次START时不会暴露但会在后续复制中断时突然蹦出来。4.2 从库延迟越来越高的排查思路延迟是复制场景里最让人头疼的问题之一。一开始从库还能跟得上跑几天后Seconds_Behind_Master越来越离谱甚至从几秒涨到几百秒。这时候别急着加从库先定位延迟的根源。常见的原因有这些主库产生了大事务比如一次DELETE删了几百万行或者批量UPDATE全表binlog事件巨大从库重放消耗大量时间从库硬件性能弱比如磁盘是机械盘而主库是SSD重放速度跟不上写入速度还有一个容易被忽视的问题就是早期版本从库默认只有一个SQL线程在串行重放日志即使IO线程拉得再快SQL线程也是单车道跑车天然容易积压。解决方案可以分层做。首先从源头减少大事务把一次处理几百万行的任务拆成小批次提交。其次给从库配置多线程复制MySQL 8.0支持基于库和基于事务的并行复制可以在配置里调整replica_parallel_workers等相关参数。再次监控从库的磁盘IO和CPU排除硬件性能瓶颈。最后如果延迟确实无法避免应用层可以设置一个“从库延迟阈值”延迟过高时暂时把读请求切回主库避免读到特别旧的数据。4.3 复制中断的常见原因速查表把我在实际过程中踩过和帮人排查过的复制中断原因整理成一张表方便你对照检查。这些问题的共同点是不会在搭建当天暴露而是在某次业务变更、备份清理或者网络波动后突然跳出来。这张表虽然不能覆盖所有情况但覆盖了90%的常规问题排查时先对照症状缩小范围再结合错误日志精确定位。症状可能原因快速检查方法IO线程一直重连网络不通、账号密码错误、主库防火墙拦截用复制账号在从库手动连接主库确认3306能通IO线程报server_id冲突从库是从主库克隆的auto.cnf里UUID相同在从库删除auto.cnf文件后重启mysqldIO线程找不到binlog文件主库binlog被purge清理或者手工删除了查看主库binlog列表原位置已经不存在只能重建复制SQL线程报主键冲突从库有数据或者主从重复执行了插入检查错误日志中的具体SQL结合业务逻辑比对数据SQL线程报表不存在初始数据没同步全复制从中间位置开始确认备份导入是否完整必要时重建从库从库读不到最新数据延迟过高或者应用连接到了旧从库查看Seconds_Behind_Master和relay log积压情况复制账号连接报认证插件不支持MySQL 8.0默认插件与客户端兼容性差创建账号时显式指定mysql_native_password这张表里我想特别强调一下auto.cnf的问题。很多时候我们部署从库图省事直接从主库的备份恢复数据连数据目录里的auto.cnf也一起恢复了。这个文件里保存着MySQL实例的UUID如果从库和主库的UUID相同复制启动时主库会拒绝连接IO线程循环报错。解决办法很简单删除从库数据目录下的auto.cnf重启mysqld它会自动生成新的UUID。4.4 数据不一致怎么补救复制中断可以修修完之后最怕的是主从数据已经不一致了。比如SQL线程在重放某条UPDATE时报错跳过后主库和从库的数据就出现了偏差而且只要不处理偏差会越来越大。先说规避措施初始化从库时的数据源一定要用带--master-data2的一致性备份而不是直接在从库上手工乱导数据。日常运维中可以用pt-table-checksum这类工具定期校验主从数据一致性发现差异后结合pt-table-sync生成修复SQL。如果已经出现偏差常规思路是先定位差异范围再用主库数据作为基准修复从库。修复方式取决于差异大小差异小可以手工UPDATE或DELETE差异大更稳妥的方案是重建从库重新跑一次全量备份和复制配置。这里我强烈建议不要在生产环境直接跳过SQL错误继续复制很多人在SQL线程报错时第一反应是执行STOP REPLICA然后SET GLOBAL SQL_SLAVE_SKIP_COUNTER1再START REPLICA把错误跳过。短期内复制恢复了但那条没执行成功的变更已经没了等于制造了一颗数据地雷。尤其是涉及金额、库存这类状态的变更跳过之后表面上主从都可用实际数据已经是错的后续报表、对账、业务查询都会暴露问题。真要做跳过处理必须先把主库对应的binlog事件手工补到从库确保数据一致后再继续复制。最后再分享一点实际操作中的体会主从复制不是一个配完就完事的功能它需要持续的监控和应对策略。我见过太多团队搭建时一切正常上线后因为一个主键冲突或者一次大事务就断了复制然后数据悄悄分叉。建议你从搭建第一天就开始记录主库binlog的保留时长、从库延迟的基线值和常见报错的处理方式把这些沉淀成一份运维手册。真等到某天凌晨被复制中断的告警叫醒时这份手册会帮你省下至少两小时的排查时间。