能跑通异步主从，核心就三件事：主库开binlog、从库连上并启动IO和SQL线程、server_id全局唯一；需确认log_bin=ON、binlog_format=ROW，CHANGE REPLICATION SOURCE TO参数须严格匹配主库当前位点，启动后必须验证Slave_IO_Running和Slave_SQL_Running均为Yes。
能跑通异步主从，核心就三件事：主库开 binlog、从库连上并启动两个线程、server_id 全局唯一。其他配置都是锦上添花，别一上来就调 timeout 或 parallel_applier。
主库必须确认 log_bin 和 binlog_format 已生效
MySQL 8.4 默认开启 log_bin，但不是所有安装方式都启用——比如某些二进制包解压后未初始化，log_bin 实际是 OFF。别只信文档，执行 SHOW VARIABLES LIKE 'log_bin'; 看返回值是不是 ON。
binlog_format 必须设为 ROW（推荐），否则语句级复制在函数、临时表、非事务引擎等场景下极易不一致。修改后需重启 mysqld 或用 SET PERSIST binlog_format = ROW; 持久化。
- 检查命令：
SHOW VARIABLES LIKE 'binlog_format'; - 错误现象：从库报错
Cannot execute statement: binlog format is not set to ROW - 注意：
binlog_row_image=FULL在 8.4 中默认已是 FULL，不用额外设
从库的 server_id 和 CHANGE REPLICATION SOURCE TO 必须匹配主库状态
主库和从库的 server_id 不仅要不同，还不能为 0，且不能重复（集群内全局唯一）。如果从库之前做过其他复制任务，server_id 可能残留旧值，改完配置后记得重启 mysqld 或执行 SET PERSIST server_id = 2; 并 RESTART;。
CHANGE REPLICATION SOURCE TO 的参数必须严格对应主库当前的 binlog 文件名和 position（或 GTID set）。用 SHOW BINARY LOG STATUS; 查主库当前位点，别抄网上示例里的 mysql-bin.000001 这种过期文件名。
- 常见错误：
ERROR 3021 (HY000): This operation cannot be performed with a running slave io_thread—— 先执行STOP SLAVE;再改 - GTID 场景下，必须先在主库导出
SELECT @@GLOBAL.GTID_EXECUTED;，再在从库SET GLOBAL GTID_PURGED = '...';，否则会报Error 1840 - 密码明文写在 SQL 里？用
SOURCE_USER+SOURCE_PASSWORD是安全的，MySQL 8.4 默认启用了密码脱敏日志
启动复制后必须验证 IO_THREAD 和 SQL_THREAD 是否真在运行
START SLAVE; 命令本身不报错，不代表复制真跑起来了。90% 的“看起来配好了但没数据同步”问题，都卡在这一步。
必须立刻查 SHOW SLAVE STATUS\G，重点盯住两行：
-
Slave_IO_Running: Yes—— 表示从库已连上主库、正在拉日志；如果为Connecting，八成是网络不通、账号权限不足（缺REPLICATION SLAVE）、或主库bind_address没放开 -
Slave_SQL_Running: Yes—— 表示 relay log 正在被回放；如果为No，看Seconds_Behind_Master和Last_SQL_Error，常见是建表语句冲突、从库有同名表、或字符集不一致导致插入失败
别依赖 Seconds_Behind_Master: 0 判断是否正常——刚启动时它可能为 NULL，等几秒再查；真正稳态下应是数字且缓慢增长/归零。
别跳过 FLUSH TABLES WITH READ LOCK 就直接 mysqldump
如果你用逻辑备份（mysqldump）初始化从库，又想保证主从初始数据完全一致，就必须在主库执行 FLUSH TABLES WITH READ LOCK; 后，立刻记下 SHOW BINARY LOG STATUS; 的 File 和 Position，再导出数据。释放锁前完成 dump，否则从库起复制时位置对不上，轻则延迟暴涨，重则主键冲突、复制中断。
这个锁不影响读，但会阻塞所有写操作，所以务必快：开两个终端，一个锁表+查位点，另一个立刻 mysqldump，完成后马上 UNLOCK TABLES;。
- 替代方案：用
mysqlpump或mydumper，它们支持自带 GTID 快照，无需手动锁表 - 生产环境建议跳过锁表，改用
xtrabackup物理备份，它能在不锁表前提下获得一致性位点 - 警告：
mysqldump --single-transaction对 InnoDB 有效，但无法保证 MyISAM 表一致性，而FLUSH TABLES WITH READ LOCK是全引擎安全的
最常被忽略的是：主库 max_allowed_packet 和从库该值不一致，大事务 dump 导入时会静默截断，SQL 线程执行到一半就停住，错误日志里只有一行 Got fatal error 1236，根本看不出哪条语句坏了。
