CHANGE MASTER TO 是严格绑定复制行为的配置命令，漏写、错写或乱组合参数会导致连接失败、数据跳过、重复执行或 GTID 冲突；MASTER_HOST、PORT、USER、PASSWORD 必须同时指定，缺一不可；GTID 模式下必须禁用 MASTER_LOG_FILE 和 MASTER_LOG_POS；所有参数写入 master.info 文件并持久生效。
直接说结论： CHANGE MASTER TO 不是“设完就跑”的配置命令，每个参数都绑定着复制行为的具体控制逻辑——漏掉、写错、乱组合，轻则 Slave_IO_Running: Connecting 卡死，重则从库跳过数据、重复执行、甚至 GTID 冲突不可逆。
MASTER_HOST、MASTER_PORT、MASTER_USER、MASTER_PASSWORD 是连接四要素，但必须一起出现
这四个参数构成从库连主库的“登录凭证”，缺一不可。单独改密码或端口时，仍需显式写出全部四项（哪怕其他值不变），否则 MySQL 会把未指定项重置为空字符串，导致连接失败。
-
MASTER_HOST必须是可解析的 IP 或域名；填'localhost'会走 socket 连接，不走 TCP，仅限同机部署 -
MASTER_PORT默认 3306，但一旦指定，哪怕和原来一样，也会触发“主库变更”逻辑：自动清空 relay log，并将MASTER_LOG_FILE和MASTER_LOG_POS重置为''和4 -
MASTER_USER和MASTER_PASSWORD对应主库上具有REPLICATION SLAVE权限的账号，密码明文存储在master.info文件里，建议用强密码并限制该账号只允许从从库 IP 登录
MASTER_LOG_FILE 和 MASTER_LOG_POS 只在非 GTID 模式下生效，且必须成对出现
这两个参数定义复制起点，但仅当 MASTER_AUTO_POSITION = 0（默认）时才起作用。一旦启用 GTID，它们会被忽略，强行指定反而报错。
- 值必须来自主库执行
SHOW MASTER STATUS的输出，不能凭记忆或旧快照填写 - 如果只写
MASTER_LOG_FILE不写MASTER_LOG_POS，MySQL 会报错；反过来也一样 - 位置
4是 binlog 文件头起始偏移，不是万能安全值——只有在主库刚初始化、尚未写入任何事件时才适用
MASTER_AUTO_POSITION=1 启用 GTID 复制，但前提条件很硬
开启这个参数前，主从双方都必须满足：gtid_mode=ON、enforce_gtid_consistency=ON，且从库不能有未清理的旧 relay log。
- 只要
MASTER_AUTO_POSITION=1，就绝对不能再带MASTER_LOG_FILE和MASTER_LOG_POS，否则语法错误 - 切换到 GTID 模式后，
STOP SLAVE; RESET SLAVE ALL;再CHANGE MASTER TO ... MASTER_AUTO_POSITION=1;是标准流程，漏掉RESET SLAVE ALL容易残留旧位点引发冲突 - GTID 模式下，从库会自动找主库缺失的事务，但前提是主库 binlog 没被 purge —— 所以
binlog_expire_logs_seconds要设得比最大复制延迟长
MASTER_CONNECT_RETRY 和 MASTER_RETRY_COUNT 控制网络抖动下的重试行为
这两个参数决定从库连不上主库时“等多久、试几次”，但容易被误认为只是调优项，实际直接影响故障恢复时间窗口。
-
MASTER_CONNECT_RETRY是每次重试前等待秒数，默认 60；跨云或高延迟链路建议设为 120～180 -
MASTER_RETRY_COUNT是最大重试次数，默认无限（0）；生产环境建议设为有限值（如1000），避免永久卡在Connecting状态掩盖真实问题 - 注意：
MASTER_HEARTBEAT_PERIOD并不控制连接重试，它只影响心跳包发送频率；它的默认值依赖slave_net_timeout，且修改slave_net_timeout不会自动更新它，必须显式CHANGE MASTER TO设置
最常被忽略的一点：所有参数写进 master.info 文件后，重启 mysqld 也会加载——这意味着临时测试改参数，不 RESET SLAVE 就停服务，下次启动可能沿用错误配置。别只盯着命令行输得对不对，得盯住文件里存的是什么。
