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。
