生产环境中 MySQL 一直在写入却要求在不锁表、不中断业务的前提下增加一个从库这是 DBA 和运维工程师经常面对的场景。很多人第一次处理时第一反应是“用 mysqldump 导出再导入”但执行到一半发现数据库卡住了CPU 飙升业务侧开始出现大量锁等待。问题的根子不在“加从库”本身而在于备份阶段和恢复阶段是否对源库产生了不必要的全局锁、表锁或长时间 IO 压力。本文围绕“数据一直在写 不能锁表”这两个核心约束展开介绍两种可落地的在线加从库方案第一种基于 mysqldump 的一致性快照逻辑适合中小型实例第二种基于物理备份工具 XtraBackup适合大实例和更严格的停写窗口。文中的命令、参数和排查思路都来自实际生产经验落地前需要根据你的 MySQL 版本、数据量和磁盘性能做调整。1. 先理解“加从库”为什么容易锁表加从库本质上分两个阶段先把源库某一个时刻的全量数据复制到新从库再让新从库从那个时刻开始持续追赶源库的 binlog 增量。两个阶段如果处理不当都会对源库产生影响。1.1 备份阶段锁表通常来自导出工具和参数选择备份阶段最容易出现锁表。如果直接执行mysqldump而不加任何参数InnoDB 表可能被加上一致性锁MyISAM 表则需要全表锁才能保证导出数据一致。对于持续写入的线上库这意味着业务侧的 INSERT、UPDATE、DELETE 会被阻塞表现就是“数据库卡住”“连接数飙升”“慢查询突然增多”。更隐蔽的锁表来自--master-data1或--source-data参数执行时需要获取 binlog 坐标这个过程会申请全局读锁。虽然 MySQL 8.0 的--single-transaction能通过 MVCC 避免长时间锁表但坐标获取和快照事务建立之间仍然有一个短时间的FLUSH TABLES WITH READ LOCK如果表数量多、数据量大这个短窗口也会被放大。1.2 同步阶段锁表风险转移到了新从库从库恢复全量数据时如果直接使用传统逻辑导入大量的 SQL 回放会在新从库上产生行锁和表锁。这个阶段源库不受影响但新从库可能因为配置了read_only0而接受外部写入导致数据混乱。另一个常见问题是主从链路启动后从库的 relay log 回放速度跟不上主库写入速度造成持续延迟。延迟本身不是锁表但延迟累积会导致从库 binlog 积压、磁盘写满最终从库宕机重新进入不可用状态。1.3 明确目标加从库的四个核心约束生产环境在线加从库需要同时满足四个约束约束说明源库业务不中断加从库期间应用不能停机读写链路不能断开源库不产生常规锁表尽量不执行长时间FLUSH TABLES WITH READ LOCK避免锁等待数据必须一致从库的数据要和源库在某个时间点完全一致之后能通过 binlog 无缝衔接可回滚从库启动复制后如果数据不一致要能快速重新初始化这四个约束对应到技术选型上就是备份方式、binlog 坐标记录方式和复制启动方式的组合问题。2. 方案一mysqldump 一致性快照适合中小实例如果数据库实例总数据量在几十 GB 以内业务写入量不是极端高并发使用mysqldump配合--single-transaction和--master-data是最简单、最不需要额外安装工具的方式。2.1 为什么--single-transaction能避免锁表--single-transaction会在导出开始前启动一个可重复读隔离级别的事务InnoDB 通过 MVCC 读取这个事务开始时刻的一致性快照。也就是说导出过程中其他连接对数据做的修改不会被导出到备份文件里同时也不会阻塞其他连接的写入。这里要特别注意该参数只对 InnoDB 表有效MyISAM 表仍然需要锁表。所以库内如果有 MyISAM 表需要先评估是否可以接受短时间锁表或者提前把 MyISAM 表迁移成 InnoDB。--single-transaction必须配合--master-data使用时MySQL 执行顺序是先建立快照事务再获取 binlog 坐标。坐标获取本身会有短时间的全局读锁正常情况下这个锁的时间很短但表数量多时会变长。--routines和--triggers参数用于导出存储过程、函数和触发器如果漏掉新从库会缺少这些对象后续复制可能报错。2.2 先准备从库环境从库的 MySQL 版本建议与主库一致至少大版本一致例如主库是 MySQL 8.0.32从库也使用 8.0.x不要用 5.7 的从库去同步 8.0 的主库否则数据类型、默认字符集、binlog 格式的差异会在复制过程中暴露。从库需要提前完成以下准备安装相同版本 MySQL初始化数据目录为空或者使用一个干净的实例。记录从库的 server_id不能与主库或其他从库重复。开启从库的read_only1如果是 MySQL 8.0建议同时设置super_read_only1防止应用误写。确认从库磁盘空间足够至少预留源库数据量的 1.5 到 2 倍因为全量文件、binlog、临时排序空间都可能占用磁盘。从库的gtid_mode和enforce_gtid_consistency配置建议直接对齐主库。如果主库已开启 GTID从库必须提前开启否则复制链路无法建立。2.3 在主库执行一致性备份以下命令在主库上执行建议在业务低峰期进行同时通过网络传输到从库而不是先落地到主库磁盘再清理。mysqldump \ --single-transaction \ --master-data2 \ --routines \ --triggers \ --events \ --hex-blob \ --set-gtid-purgedON \ --databases yourdb \ -uroot -p \ /data/backup/yourdb_full.sql各参数用途如下参数作用--single-transaction使用 InnoDB 一致性快照不加表锁--master-data2在备份文件中记录 binlog 文件名和位置注释形式写入便于从库定位坐标--routines导出存储过程和函数--triggers导出触发器--events导出事件调度器--hex-blob二进制字段以十六进制导出避免乱码和特殊字符问题--set-gtid-purgedON同时记录 GTID 集合配合 GTID 复制使用--databases yourdb只导出目标库如果不指定默认导出全部库通常不建议在生产备份中导出mysql系统库备份完成后查看备份文件头部的 binlog 坐标信息head -n 100 /data/backup/yourdb_full.sql | grep -E CHANGE MASTER TO|GTID_PURGED典型输出类似-- CHANGE MASTER TO MASTER_LOG_FILEmysql-bin.000128, MASTER_LOG_POS51234879; -- GTID state at the beginning of the backup SET GLOBAL.GTID_PURGEDaaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee:1-58213;如果启用了 GTID从库启动复制时可以直接使用MASTER_AUTO_POSITION1不再需要手动填写 binlog 文件名和位置。如果主库没有启用 GTID则必须记录上面输出的MASTER_LOG_FILE和MASTER_LOG_POS。2.4 在从库导入全量数据把备份文件传到从库后执行导入mysql -uroot -p /data/backup/yourdb_full.sql导入过程不要并行mysql 多个文件除非你很明确表之间没有外键依赖。导入后的检查和验证对比主库和从库的表数量、行数SELECT COUNT(*) FROM information_schema.tables WHERE table_schemayourdb;抽查核心表的数据量。检查从库的错误日志是否有异常对象跳过。完成导入后从库上的数据还停留在备份时刻此时不能对外服务需要先启动复制链路。2.5 启动复制链路并验证GTID 模式下启动复制CHANGE MASTER TO MASTER_HOST192.168.10.20, MASTER_PORT3306, MASTER_USERrepl_user, MASTER_PASSWORDyourpassword, MASTER_AUTO_POSITION1; START SLAVE;非 GTID 模式使用备份记录的坐标CHANGE MASTER TO MASTER_HOST192.168.10.20, MASTER_PORT3306, MASTER_USERrepl_user, MASTER_PASSWORDyourpassword, MASTER_LOG_FILEmysql-bin.000128, MASTER_LOG_POS51234879; START SLAVE;启动后检查复制状态SHOW SLAVE STATUS\G重点关注三个字段字段正常状态说明Slave_IO_RunningYesIO 线程正常连接主库拉取 binlogSlave_SQL_RunningYesSQL 线程正常回放 relay logSeconds_Behind_Master0 或持续减小从库延迟数值越小越好如果Slave_IO_Running为 Connecting先检查主库是否能连通、复制账号是否授权、主从 server_id 是否冲突。如果Slave_SQL_Running为 No查看 Last_SQL_Error通常是因为主从 GTID 不一致或从库已有冲突数据。2.6 mysqldump 方案的边界这个方案适合数据量可控、能够在可接受时间内完成导出导入的实例。数据量超过 100 GB 时mysqldump导出的是逻辑 SQL导入阶段每一条语句都要经过解析、执行、事务提交速度远慢于物理文件拷贝。实际场景中100 GB 的库用mysqldump可能要 1 到 3 小时而用后面介绍的物理备份方案可能只需要 20 到 40 分钟。另外--single-transaction虽然不锁表但它在导出一张大表时会保持一个长事务。长事务会导致 undo log 膨胀可能触发undo tablespace truncate占用额外 IO。因此执行前要确认实例的innodb_undo_tablespaces和磁盘空间。3. 方案二XtraBackup 物理备份适合大实例对于百 GB 到 TB 级别的实例逻辑备份的时间窗口和 IO 开销很难接受。Percona XtraBackup 是更主流的方案它通过物理方式复制 InnoDB 数据文件备份速度接近磁盘拷贝速度并且支持在线备份。3.1 XtraBackup 的核心机制XtraBackup 使用 InnoDB 的 redo log 实现备份一致性。备份过程中它拷贝数据文件的同时也会持续拷贝 redo log。备份结束时所有数据文件在时间上可能并不是同一个检查点但通过--apply-log阶段重放 redo log数据文件会被推进到一个一致状态。这个过程从原理上避免了对源库加锁因为它不依赖FLUSH TABLES WITH READ LOCK来保证一致性而是利用 InnoDB 自身的崩溃恢复机制。3.2 安装 XtraBackup根据 MySQL 版本选择对应版本的 XtraBackupMySQL 版本XtraBackup 版本安装源MySQL 8.0Percona XtraBackup 8.0Percona 官方仓库MySQL 5.7Percona XtraBackup 2.4Percona 官方仓库MySQL 8.4Percona XtraBackup 8.4Percona 官方仓库安装示例使用 yumyum install -y https://repo.percona.com/yum/percona-release-latest.noarch.rpm percona-release enable-only tools release yum install -y percona-xtrabackup-80装完后检查版本xtrabackup --version输出中会包含类似xtrabackup version 8.0.35-30的版本信息。安装方式在 Ubuntu/Debian 上使用 apt命令略有不同但包名类似。3.3 主库执行全量物理备份示例命令xtrabackup \ --backup \ --target-dir/data/backup/xtra_full \ --host127.0.0.1 \ --port3306 \ --userbackup_user \ --passwordyourpassword \ --slave-info \ --safe-slave-backup参数说明参数作用--backup执行备份操作--target-dir备份文件存放目录目录需要为空或不存在--host/--port/--user/--password连接主库的连接信息账号需要RELOAD、LOCK TABLES、REPLICATION CLIENT权限--slave-info在备份中记录主从信息便于把备份作为从库数据源--safe-slave-backup如果本实例本身是从库备份时暂停 SQL 线程保证一致性对于从主库直接备份的场景--slave-info不是必须的。如果你是在一个从库上再做下级从库才需要--safe-slave-backup保证复制线程稳定。备份过程如果出现数据集大、磁盘 IO 高的情况可以增加--parallel4或--parallel8加速拷贝但并行数不一定越高越好机械盘上并行 IO 可能相互争抢SSD 上可以适当调大。3.4 应用 redo log 使备份可用备份完成后备份文件处于“正在备份时”的非一致状态需要执行 preparextrabackup \ --prepare \ --target-dir/data/backup/xtra_full这一步会重放 redo log使数据文件达到一致状态。Prepare 可以在主库上执行也可以在传输到从库后再执行。推荐在主库上执行因为 prepare 过程是 IO 密集操作避免占用从库资源。Prepare 完成后备份目录中会出现xtrabackup_binlog_info、xtrabackup_info等信息文件。查看 binlog 坐标cat /data/backup/xtra_full/xtrabackup_binlog_info输出格式类似mysql-bin.000128 51234879 aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee:1-58213第一列是 binlog 文件名第二列是位置第三列是 GTID 集合。如果主库开启 GTID用第三列否则用前两列。3.5 恢复到从库并替换数据目录从库需要先关闭 MySQL清空数据目录再把备份文件移动到数据目录。假设从库数据目录是/var/lib/mysqlsystemctl stop mysqld rm -rf /var/lib/mysql/* xtrabackup --copy-back --target-dir/data/backup/xtra_full chown -R mysql:mysql /var/lib/mysql systemctl start mysqld这里要注意--copy-back是复制文件如果不想立即删除主库上的备份使用复制而不是移动。启动从库后确认 MySQL 能正常启动然后执行CHANGE MASTER TO。从库执行复制启动命令与 2.5 节相同。GTID 模式下使用MASTER_AUTO_POSITION1非 GTID 模式使用xtrabackup_binlog_info中记录的文件名和位置。3.6 物理备份方案的关键点物理备份直接拷贝 InnoDB 数据文件不产生 SQL 回放开销恢复时间远短于逻辑备份。--prepare后的备份目录相当于一个“可启动的数据目录”可以直接替换从库数据目录。如果主库开启了encryption或page compression备份时需要额外指定相关参数比如--keyring-file-data。实际项目中要提前确认这些特性是否开启。物理备份同样需要确认磁盘空间备份目录占用的空间与源数据目录类似。如果磁盘紧张可以考虑通过--stream方式直接通过 SSH 管道传输备份例如xtrabackup --backup --streamxbstream | ssh target cat /data/backup/xtra_full.xbstream但这种方式排错成本更高。4. 加从库前后的高可用与验证闭环备份和恢复完成后最容易被忽略的问题是“复制链路看起来是 Running但数据真的一致吗”。生产中遇到过Slave_IO_Running和Slave_SQL_Running都是 Yes但某张表数据对不上的情况。因此加从库不能只做到SHOW SLAVE STATUS显示两个 Yes 就结束。4.1 在主库准备复制账号主库执行CREATE USER repl_user192.168.10.% IDENTIFIED BY yourpassword; GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO repl_user192.168.10.%; FLUSH PRIVILEGES;注意MySQL 8.0 的默认认证插件是caching_sha2_password从库连接主库时第一次握手需要主库的公钥。如果连接报错Authentication plugin caching_sha2_password cannot be loaded可以在主库复制账号上指定mysql_native_password或者在从库的CHANGE MASTER TO中设置MASTER_SSL1或通过GET_MASTER_PUBLIC_KEY1解决。推荐直接把主从链路的传输加密开启避免明文密码和公钥问题。ALTER USER repl_user192.168.10.% IDENTIFIED WITH mysql_native_password BY yourpassword;这是在测试环境快速解决问题的写法生产环境更推荐配置 SSL 复制。4.2 对比主从数据一致性简单场景下可以通过比对表行数和关键字段的校验值确认。例如检查任意一张表-- 主库执行 SELECT COUNT(*), SUM(CRC32(CONCAT_WS(|, id, name, amount))) FROM yourdb.orders; -- 从库执行相同语句 SELECT COUNT(*), SUM(CRC32(CONCAT_WS(|, id, name, amount))) FROM yourdb.orders;两边结果一致说明该表当前数据一致。正式校验可以用pt-table-checksum它通过主从复制链路逐表计算校验值适合大批量校验。使用前确认从库已经追平主库否则校验值会因延迟而不同。4.3 验证从库对外只读从库开启只读防止应用误写SET GLOBAL read_only ON; SET GLOBAL super_read_only ON;super_read_only的作用是即使有 SUPER 权限的账号也不能写数据除非显式关闭该参数。这个配置必须写入 MySQL 配置文件my.cnf否则重启后失效。[mysqld] read_only 1 super_read_only 14.4 监控复制延迟复制延迟是加从库后最重要的监控指标。可以使用pt-heartbeat做秒级延迟检测也可以直接用SHOW SLAVE STATUS的Seconds_Behind_Master粗粒度观察。生产环境建议在监控系统中加入主从延迟告警阈值可以设置为 30 秒超过 5 分钟触发 P2 告警超过 30 分钟触发 P1 告警。如果从库延迟持续增长优先检查从库所在机器的磁盘 IO、CPU、内存和网络带宽。常见原因是从库磁盘性能低于主库或者从库开启了二进制日志导致写入放大。5. 生产环境中最常见的坑与排查链路5.1 binlog 坐标记录错误导致主从跳过数据现象从库启动复制后跳过大量事务或报错Could not execute Write_rows event on table xxx。原因备份记录的是“备份开始时”的 binlog 坐标如果备份完成后传输到从库这段时间内从库回放时和主库 binlog 的衔接点错位就会漏数据或重复数据。排查方式查看备份文件头部或xtrabackup_binlog_info中的坐标。对比主库当前 binlog 文件列表SHOW MASTER STATUS;。如果使用 GTID确认从库GTID_PURGED与主库的gtid_executed是否匹配。解决方式如果坐标误差很小可以在从库上执行STOP SLAVE;然后重新RESET SLAVE ALL;重新启动复制。如果误差较大需要重新备份并初始化。预防建议备份完成后立即记录坐标不要在备份目录中存放过大临时文件后再做恢复。传输到从库后第一时间查看备份信息文件并确认 GTID 集合。5.2 主从版本不一致复制中途断开现象从库SHOW SLAVE STATUS中Last_SQL_Error提示类似Unknown system variable transaction_isolation或Incorrect usage or use of UNION and ORDER BY。原因主库是 MySQL 8.0从库是 MySQL 5.7或者从库版本过旧无法解析主库产生的 binlog 事件。排查方式确认主从SELECT VERSION();。查看从库错误日志中具体报错语句。使用mysqlbinlog --no-defaults解析主库 binlog检查是否有从库版本不支持的事件类型。解决方式将从库升级到与主库一致的版本重新初始化数据重新建立复制链路。预防建议上线前核对主从版本清单避免 5.7 与 8.0 混用。特别要注意 8.0 的默认字符集是utf8mb4_0900_ai_ci5.7 的从库可能无法使用该排序规则。5.3--single-transaction长事务触发 undo 膨胀现象备份期间主库磁盘使用率快速上升查询变慢。原因长事务让 InnoDB 需要保留大量旧版本数据undo log 膨胀。排查方式执行SHOW ENGINE INNODB STATUS;查看 History list length。查看performance_schema.events_statements_current中备份连接当前的 SQL 类型。解决方式备份结束长事务释放后undo log 会自动收缩但收缩过程会产生 IO 压力。如果磁盘空间不足需要提前清理 binlog 或扩容。预防建议在低峰期执行备份并监控主库磁盘水位。如果库中有超大表可以单独评估使用pt-archiver或分区表按月拆分。5.4 从库开启log_bin导致延迟放大现象从库开启log_bin后写入延迟高于主库Seconds_Behind_Master增长。原因从库的 SQL 线程回放 relay log 时如果开启了log_bin还需要额外写从库自己的 binlog增加写放大。排查方式查看从库my.cnf是否配置log_binmysql-bin。执行SHOW MASTER STATUS;查看从库 binlog 文件增长情况。解决方式如果从库不需要再作为主库的下游可以关闭log_bin只保留relay_log。如果从库需要继续向下游提供数据则要保证从库磁盘性能至少不低于主库。预防建议规划复制拓扑时明确从库角色。普通读从库不开启log_bin级联复制或备份源从库才开启。5.5 备份账号权限不足现象xtrabackup或mysqldump执行时报Access denied; you need (at least one of) the RELOAD privilege(s) for this operation。原因备份账号缺少全局权限。排查方式主库执行SHOW GRANTS FOR backup_user127.0.0.1;解决方式GRANT RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT ON *.* TO backup_user127.0.0.1; FLUSH PRIVILEGES;预防建议为备份单独创建账号不要直接使用 root。5.6 数据校验时主从延迟导致校验失败现象pt-table-checksum校验结果中大量表显示不一致但从库实际数据是对的。原因校验启动时从库尚未追平主库校验期间主库持续写入两边数据的快照时刻不同。排查方式校验前确认Seconds_Behind_Master0。校验过程中观察主从延迟是否始终保持接近 0。解决方式选择业务低峰期先等待从库追平再执行校验。如果数据量太大可以按库分批校验。预防建议把校验脚本放入定期巡检任务每周或每月执行一次发现不一致后能够尽早处理。6. 加从库前的前置检查清单以下清单可以在生产操作前逐项确认减少返工和事故检查项检查内容确认方式MySQL 版本主从大版本一致SELECT VERSION();server_id从库与主库、其他从库不冲突SHOW VARIABLES LIKE server_id;GTID 配置主从gtid_mode、enforce_gtid_consistency一致SHOW VARIABLES LIKE gtid_mode;字符集和排序规则主从一致SHOW VARIABLES LIKE collation_server;表引擎尽量全部 InnoDB避免 MyISAM查询information_schema.tables磁盘空间从库至少 1.5 倍数据量主库备份目录空间充足df -h备份账号已授权RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENTSHOW GRANTS;从库只读read_only1、super_read_only1已配置SHOW VARIABLES LIKE read_only;主库 binlog 保留时长建议至少保留 48 小时以上SHOW VARIABLES LIKE binlog_expire_logs_seconds;监控告警磁盘水位、复制状态、延迟告警已配置确认监控平台操作窗口业务低峰期备份期间监控主库 CPU、IO 负载通过监控曲线确认这 10 项如果全部确认通过再执行备份和恢复操作成功概率会高很多。7. 操作完成后的验证顺序新从库不是启动复制就结束验证要按以下顺序逐步推进确认复制链路状态SHOW SLAVE STATUS\G两个线程均为 Yes。确认主从时间线同步等待Seconds_Behind_Master降为 0可在一段时间内多次查看。确认数据一致性先手工查询核心表的行数和校验值再用pt-table-checksum全量比对。确认从库只读使用普通业务账号尝试写入必须报The MySQL server is running with the --read-only option。确认应用连接访问正常如有需要可以先让部分只读流量切入新从库观察慢查询、连接数、CPU 负载是否正常。纳入监控把新从库的实例状态、磁盘、延迟、复制异常加入现有 MySQL 监控大盘。第 4 步经常被人跳过。很多事故发生在“从库上线第二天数据被应用端误写导致主从数据不一致”。从库只读这个措施从第一天就要配置好不要等出了问题再补。8. 两种方案的选型建议和生产实践要点8.1 选型对照维度mysqldump 逻辑备份XtraBackup 物理备份备份速度慢受 SQL 解析和写入影响快接近文件拷贝速度恢复速度慢需要逐条执行 SQL快文件复制到数据目录即可启动对源库锁影响--single-transaction下 InnoDB 不锁表但可能有短时全局读锁基本不锁 InnoDB 表依赖 redo log 保证一致性数据量适用几十 GB 以内百 GB 到 TB 级别依赖工具MySQL 自带 mysqldump无需额外安装需要安装 Percona XtraBackup对 MyISAM 表需要锁表不支持或需额外处理运维门槛低中高需要理解 prepare、copy-back 流程8.2 实际操作建议总结生产加从库前后有几个经验值得沉淀先演练再动手。加从库的流程至少要在测试环境完整走一遍。重点演练三项备份时间、恢复时间、主从数据校验是否能通过。没有演练过的备份方案进入生产环境后大概率会踩到没见过的坑可能是权限、磁盘、版本也可能是某个参数不支持。时刻关注磁盘水位。备份目录、从库数据目录、binlog 都会在操作期间快速增长。建议操作前记录磁盘初始使用率操作过程中每 10 分钟查看一次。特别是 XtraBackup 的备份目录和prepare阶段临时文件可能占掉比预期更多空间。考虑使用 GTID 简化操作。如果主库还没有开启 GTID可以结合低峰期配置gtid_modeON和enforce_gtid_consistencyON。GTID 模式下新增从库只需要MASTER_AUTO_POSITION1避免手工填写 binlog 文件名的失误。从库参数要在启动复制前就配置完整。read_only、super_read_only、innodb_buffer_pool_size、slave_parallel_workers都应该提前写入配置文件。如果从库打开复制后才发现参数不对修改参数可能要先停止复制链路增加不必要的操作风险。定期演练从库重建。即使主从复制长期稳定也要至少一个月演练一次从库重建流程。这样才能保证当从库磁盘损坏或数据不一致时团队有能力在 30 分钟内重新拉起一个新的从库而不是临时翻文档找命令。备份账号和复制账号要分开。备份账号需要RELOAD、LOCK TABLES、PROCESS等较高权限复制账号只需要REPLICATION SLAVE。两种账号分开管理权限越具体越好避免一个账号权限过大被误用。数据校验不是一次性操作。在线加从库完成后建议后续每周执行一次pt-table-checksum把校验结果记录到监控系统或告警系统。数据不一致是长期隐患越早发现越好修复。对于 MySQL 数据一直在写的场景加从库并不可怕可怕的是没有理解锁从哪里来、数据一致性如何保证、复制坐标如何记录。把本文提到的一致性快照、binlog 坐标、GTID、只读保护、数据校验这条链路完整跑通之后后续再增加第二个、第三个从库就是同一套流程的重复执行复杂度会明显下降。