MySQL复制需主从精准配置：主库启用log-bin、server-id、binlog-format等参数以生成日志；从库配置server-id、relay-log、read_only等确保稳定同步；启动前需执行SHOW MASTER STATUS与CHANGE REPLICATION SOURCE TO等命令建立链路，并通过SHOW REPLICA STATUS验证状态。
MySQL 复制的核心在于主从节点的参数协同，关键不是堆砌参数，而是按角色精准配置。主库侧重日志生成与暴露，从库侧重接收、重放与容错。
主库必须开启的复制基础参数
主库不启用二进制日志，复制就无从谈起。以下参数需写入 my.cnf 的 [mysqld] 段并重启生效：
-
log-bin = mysql-bin：启用二进制日志，文件前缀建议用有意义的名称（如实例名），避免默认的
binlog； - server-id = 1：全局唯一 ID，整数，不可为 0，主从之间必须互异；
- binlog-format = ROW：推荐使用 ROW 格式，语义明确、主从数据一致性高，避免 STATEMENT 模式下函数/时间类非确定性操作引发的不一致；
- expire_logs_days = 7（可选但建议）：自动清理过期 binlog，防止磁盘占满；
- max_binlog_size = 100M（可选）：控制单个 binlog 文件大小，便于管理与传输。
从库关键复制控制参数
从库参数决定同步行为和稳定性，部分可动态设置，但建议写入配置文件以保持久：
- server-id = 2（或其它唯一值）：必须与主库不同，且集群内全局唯一；
- relay-log = mysql-relay-bin：指定中继日志路径和前缀，便于定位和清理；
-
read_only = ON：防止从库被误写，仅对普通用户生效（root 仍可写，如需彻底只读可加
super_read_only = ON）； - skip_slave_start = OFF（默认）：确保 MySQL 启动时自动拉起复制线程；
- relay_log_purge = ON（默认）：中继日志应用完成后自动删除，节省空间。
启动复制前的必要操作
参数只是前提，真正建立复制链路需手动执行：
- 在主库执行 SHOW MASTER STATUS;，记录
File和Position； - 从库执行 CHANGE REPLICATION SOURCE TO（MySQL 8.0.23+）或 CHANGE MASTER TO（旧版本），指定主库 IP、端口、用户名、密码、binlog 文件名与位置；
- 运行 START REPLICA;（新版）或 START SLAVE;（旧版）；
- 用 SHOW REPLICA STATUS\G 检查
Slave_IO_Running和Slave_SQL_Running是否均为Yes，重点关注Seconds_Behind_Master和错误信息字段。
常见问题对应的参数微调
遇到延迟、中断或数据不一致时，可针对性调整：
- 主从延迟大 → 调大从库 slave_parallel_workers = 4（需配合
slave_parallel_type = LOGICAL_CLOCK）提升并行回放能力； - 网络不稳定导致 IO 线程频繁断连 → 增加 master_retry_count = 86400（默认 86400，即永久重试），并设 master_connect_retry = 10（秒级重连间隔）；
- 需跳过某条出错 SQL → 临时停复制，执行 SET GLOBAL sql_slave_skip_counter = 1;（ROW 格式下慎用，建议优先修复主库问题）；
- 从库磁盘空间紧张 → 启用 relay_log_space_limit = 2G 限制中继日志总占用。
参数本身不复杂，但组合逻辑和生效时机容易忽略。配置后务必验证复制状态与数据一致性，不能只看线程是否 running。
