主从复制必须启用mysql_rpl_semisync插件并配置对应参数；认证推荐sha256_password；replicate_do_db/rewrite_db有严重局限，应优先用GTID+replicate_ignore_table；slave_parallel_workers过高易因依赖冲突导致卡顿。
主从复制必须启用的插件：mysql\_rpl\_semisync
半同步复制不是默认开启的，但生产环境几乎都得开——否则主库提交后不等从库确认就返回成功，断电或主库崩溃时容易丢数据。mysql_rpl_semisync 是 MySQL 官方提供的核心插件，5.7+ 内置，8.0 默认不加载，需手动安装。
- 主库执行：
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so'; - 从库执行：
INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so'; - 插件名在不同系统可能不同：
semisync_master.so（Linux）、semisync_master.dll（Windows） - 加载后必须设参数才生效：
rpl_semi_sync_master_enabled=ON、rpl_semi_sync_slave_enabled=ON，仅加载插件不设参数等于没开
认证方式选 sha256_password 还是 caching_sha2_password？
MySQL 8.0 默认用 caching_sha2_password，但它在主从复制链路中可能引发连接失败，尤其跨版本或旧客户端连新从库时。
- 主库创建复制用户时，显式指定认证插件更稳妥：
CREATE USER 'repl'@'%' IDENTIFIED WITH sha256_password BY 'pwd123'; -
caching_sha2_password要求客户端支持 SSL 或开启require_secure_transport=OFF（不推荐），否则从库 IO 线程报错：ERROR 2026 (HY000): SSL connection error - 如果主库已用
caching_sha2_password，从库配置里加default_authentication_plugin=sha256_password可兼容，但本质是降级处理
复制过滤：用 replicate_do_db 还是 replicate_rewrite_db？
这两个参数看起来能“选库同步”，但行为反直觉，线上出过不少漏同步、错同步事故。
-
replicate_do_db只对USE db_name后的语句生效，不看 SQL 里的库名；比如INSERT INTO other_db.t1 ...在当前库是test时，哪怕写了other_db也会被跳过 -
replicate_rewrite_db是重写库名映射，如把old_db→new_db，但它只作用于USE和部分 DDL，对跨库 DML 无效 - 真正可控的过滤方式是 GTID +
replicate_replicate_ignore_table或用binlog_do_db（主库侧）配合业务规范，避免依赖运行时上下文判断
为什么 slave_parallel_workers 设太高反而卡住复制？
并行复制提速明显，但盲目调高 slave_parallel_workers 常导致从库延迟飙升甚至卡死，根本原因是事务依赖没理清。
- 8.0 默认基于 WRITESET 的并行策略，依赖
transaction_write_set_extraction=XXHASH64，但如果主库没开（或用的是老版本），从库仍走 DATABASE 策略，worker 数再多也只在一个库内并发 - 设为 16 不代表真有 16 个线程干活：实际并发度受限于
slave_preserve_commit_order=ON（保证事务顺序）和 binlog 中的逻辑时钟标记 - 观察
SHOW SLAVE STATUS\G中的Seconds_Behind_Master和Slave_SQL_Running_State，若长期停在Waiting for dependent transaction to commit，说明 WRITESET 没生效或冲突太多
事情说清了就结束。真正麻烦的从来不是配几个参数，而是每个参数背后隐含的执行上下文——比如 replicate_do_db 看似简单，却要求你清楚每条 SQL 执行前有没有 USE、主库 binlog_format 是 STATEMENT 还是 ROW、甚至应用是否用了多库连接池。
