主库改端口后从库能否快速重连取决于复制模式：GTID模式下只需STOP SLAVE、CHANGE MASTER TO MASTER_PORT=新端口,AUTO_POSITION=1、START SLAVE；传统position模式则必须通过主库SHOW MASTER STATUS获取最新binlog文件及位点，否则同步中断。
主库改端口后，从库不能只改 master_port 就完事——是否能“快速重连”，取决于你用的是 GTID 还是传统 position 复制，以及自动重连机制是否已启用。盲目执行 CHANGE MASTER TO 可能无效，甚至导致同步中断加剧。
确认当前复制模式：GTID 还是 binlog position？
先在从库执行：SHOW SLAVE STATUS\G，重点看两个字段：
-
Auto_Position: 1→ 表示启用了 GTID 自动定位，改端口只需更新端口本身 -
Auto_Position: 0→ 表示基于MASTER_LOG_FILE和MASTER_LOG_POS的传统复制，主库改端口后大概率已生成新 binlog 文件，必须重新对齐位点
别凭记忆或旧配置填 MASTER_LOG_FILE，那是最常踩的坑——主库重启后第一个新 binlog 名称和起始 pos 必须来自 SHOW MASTER STATUS 实时输出，且该文件得仍在 SHOW BINARY LOGS 列表里，否则只能重建从库。
GTID 模式下只需改端口，但要确保 AUTO_POSITION 生效
GTID 下改端口本身很简单，但前提是 AUTO_POSITION = 1 真正生效：
- 执行
STOP SLAVE - 执行
CHANGE MASTER TO MASTER_PORT = 3307, AUTO_POSITION = 1（显式带上AUTO_POSITION = 1，避免配置残留） - 执行
START SLAVE
如果 SHOW SLAVE STATUS\G 中 Auto_Position 仍是 0，说明上次配置没生效，需检查是否漏写了 AUTO_POSITION = 1，或 gtid_mode 在主库未开启。
传统 position 模式必须重对位点，不能只改端口
主库改端口必然伴随重启，会生成新 binlog（如 mysql-bin.000049），而旧位点（比如 mysql-bin.000048）可能已被 purge。此时：
- 先在主库执行
SHOW MASTER STATUS，记下File和Position - 立刻执行
SHOW BINARY LOGS，确认该File还存在 - 在从库执行：
STOP SLAVE→CHANGE MASTER TO MASTER_PORT = 3307, MASTER_LOG_FILE = 'mysql-bin.000049', MASTER_LOG_POS = 154（注意 pos 一般为 154，不是 0）→START SLAVE
填错 MASTER_LOG_POS 是高频失误：不要抄 Relay_Master_Log_File 和 Exec_Master_Log_Pos，它们反映的是“已执行位置”，不是主库“当前可拉取起点”。
让重连真正“自动”：必须配 SOURCE_CONNECTION_AUTO_RETRY
MySQL 8.0.22+ 推荐用新语法，老版本用 MASTER_CONNECT_RETRY。但关键点是：仅设间隔不够，必须打开总开关：
- 执行
STOP REPLICA（或STOP SLAVE） - 执行
CHANGE REPLICATION SOURCE TO SOURCE_CONNECTION_AUTO_RETRY = 1, SOURCE_RETRY_COUNT = 86400（永久重试） - 再
START REPLICA
不设 SOURCE_CONNECTION_AUTO_RETRY = 1，哪怕 SOURCE_RETRY_COUNT 再大也没用；设了但没 STOP/START，运行中修改不生效。另外，认证失败、SSL 握手失败等明确拒绝型错误不会重试，得先解决网络、用户权限、防火墙问题。
最易被忽略的是：主库改端口后，从库连接参数只是表象，底层依赖的是网络可达性、用户 host 权限是否含新 IP 段、以及主库 bind_address 是否监听了对应网卡——这些不排查清楚，CHANGE MASTER TO 做十遍也连不上。
