启动MySQL复制需先完成主从配置：主库启用binlog且server_id唯一，从库server_id不同并配置relay_log，创建复制用户并授权；再通过CHANGE MASTER TO设置连接参数及binlog位置（或GTID），执行START SLAVE后检查Slave_IO_Running和Slave_SQL_Running均为Yes。
启动 MySQL 复制进程，核心是确保从库（Slave）能正确连接主库（Master），并开始读取和执行主库的二进制日志（binlog）。关键在于配置一致、位置准确、服务正常。
确认主从基础配置已就绪
启动复制前必须完成以下准备，否则 START SLAVE 会失败：
- 主库已启用 binlog（log_bin = ON），且 server_id 唯一（如 1）
- 从库 server_id 与主库不同（如设为 2），且已配置 relay_log（推荐显式指定）
- 主库已创建用于复制的专用用户，并授予 REPLICATION SLAVE 权限
- 从库已通过 CHANGE MASTER TO 正确设置主库地址、端口、用户名、密码及 binlog 文件名与位置（或使用 GTID）
执行 START SLAVE 并验证状态
在从库执行命令启动复制线程：
START SLAVE;
立即检查是否成功运行：
SHOW SLAVE STATUS\G
重点关注两行：
- Slave_IO_Running: Yes —— 表示 I/O 线程已连接主库并拉取 binlog
- Slave_SQL_Running: Yes —— 表示 SQL 线程正在重放 relay log 中的事件
若任一为 No，需查看 Last_IO_Errno / Last_SQL_Errno 和对应错误信息定位问题（如网络不通、权限不足、position 跳跃、表结构不一致等）。
使用 GTID 启动复制（推荐方式）
若主从均开启 GTID（gtid_mode = ON，enforce_gtid_consistency = ON），可跳过手动指定 binlog 文件和 position：
- 在从库执行：CHANGE MASTER TO MASTER_HOST='xxx', MASTER_PORT=3306, MASTER_USER='repl', MASTER_PASSWORD='xxx', MASTER_AUTO_POSITION = 1;
- 再执行：START SLAVE;
- GTID 模式下，从库自动获取缺失事务，容错性更强，也便于故障切换
常见卡点与快速排查建议
复制启动后看似正常，但实际延迟或中断很常见：
- 检查主从时间是否同步（系统时间差过大会影响某些监控判断）
- 确认主库未开启 skip_networking 或防火墙拦截了从库的 3306 连接
- 查看从库错误日志（mysqld.err）中是否有连接
拒绝、SSL 握手失败等底层报错 - 若复制曾中断过，Seconds_Behind_Master 为 NULL 通常意味着 SQL 线程没运行，先看 Slave_SQL_Running_State
拒绝、SSL 握手失败等底层报错
