mysql主从复制是主库写、从库读的异步日志链路，非自动同步黑盒；server-id必须全局唯一（1–4294967295），重复会导致i/o线程拒绝启动并报错1236；主库须启用log-bin=binlog且binlog_format=row，从库通过change master to锚定主库位点，start slave后需验证slave_io_running和slave_sql_running均为yes，并确认seconds_behind_master=0及位点持续推进。
MySQL主从复制不是“多台数据库自动同步数据”的黑盒机制，而是一套明确分工、依赖日志流转的异步同步链路。它本身不提供自动故障切换或强一致性保障，搭建前必须清楚：主库写、从库读是基本约束；server-id冲突、binlog未启用、网络不通这三类问题占实际部署失败的 80% 以上。
为什么 server-id 必须全局唯一且不能为 1？
MySQL 用 server-id 标识复制拓扑中的每个节点。如果主从设置相同值（比如都为 1），从库会拒绝连接并报错：Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file'。这不是配置遗漏，而是协议层直接拒绝。
-
server-id必须是整数，范围 1–4294967295，建议用 IP 最后一段（如192.168.1.10→server-id = 10） - 修改后必须重启 MySQL：
systemctl restart mysqld，仅重载配置无效 - 检查是否生效：登录 MySQL 执行
SELECT @@server_id;，返回值应与配置一致
主库 binlog 启用和格式怎么选？
没有开启 log-bin，主从复制根本无法启动。MySQL 5.7+ 默认关闭 binlog，必须显式配置。格式选择直接影响复制稳定性：
- 必须设置：
log-bin = binlog（路径可省略，默认在 datadir 下），否则SHOW MASTER STATUS返回空 -
binlog_format = ROW是生产首选：避免函数、临时表、非确定性 SQL 导致的从库执行失败；STATEMENT格式在NOW()、UUID()等场景下极易主从不一致 - 还需配
expire_logs_days = 7，防止磁盘被旧 binlog 填满；max_binlog_size = 100M控制单个文件大小
从库执行 CHANGE MASTER TO 时哪些参数不能错？
这条命令把从库和主库的 binlog 位置锚定在一起，填错任意一个字段都会导致 IO 线程启动失败。常见错误是混淆 MASTER_LOG_FILE 和 MASTER_LOG_POS 来源。
-
MASTER_HOST填主库可解析的 IP 或域名（不要用localhost） -
MASTER_USER和MASTER_PASSWORD必须是主库上GRANT REPLICATION SLAVE ON *.*授权的账号，密码明文写入命令中（MySQL 8.0+ 支持密钥环，但此处仍需明文） -
MASTER_LOG_FILE和MASTER_LOG_POS必须来自主库执行SHOW MASTER STATUS的即时输出，不能复用历史记录或截图 - 命令末尾加
GET_MASTER_PUBLIC_KEY=1（MySQL 8.0+ TLS 连接必需），否则报错SSL connection error: SSL is required by the server
如何确认复制真的在跑，而不是假活？
执行 START SLAVE 后，SHOW SLAVE STATUS\G 显示 Slave_IO_Running: Yes 和 Slave_SQL_Running: Yes 只代表线程没崩，不代表数据在同步。真正要看的是延迟和位点推进。
-
Seconds_Behind_Master为NULL表示 SQL 线程没启动；为0才算实时；持续大于 0 说明从库追不上 -
Read_Master_Log_Pos和Exec_Master_Log_Pos应随时间缓慢增长，若长期不变，说明 IO 或 SQL 线程卡死 - 最简验证法：主库
INSERT INTO test.t1 VALUES (NOW());，几秒后从库查同表，看时间戳是否一致
主从复制的脆弱点不在配置步骤，而在网络抖动、磁盘 I/O 阻塞、SQL 线程遇到 DDL 锁表这些隐性场景。上线前务必用真实业务流量压测 30 分钟以上，观察 Seconds_Behind_Master 是否稳定归零——这是最容易被跳过的验证环节。
