单台服务器多实例主从本质是多个独立实例间跨实例复制，须严格隔离端口、socket、datadir及日志路径，server-id全局唯一，change master to需指定master_host='127.0.0.1'和正确master_port，并确保主库授权、网络可达及复制线程状态正常。
单台服务器上配置主从多实例，本质不是“一个实例既是主又是从”，而是多个独立实例之间建立主从关系——比如 3306 实例作为主库，3307 和 3308 分别作为它的从库。关键不在“多实例”本身，而在“跨实例复制”能否绕过端口/目录/用户权限的干扰。
主从多实例必须隔离端口、socket 和数据目录
同一台机器上启动多个 mysqld 进程时，只要任意两个实例共用 port、socket 或 datadir，必然启动失败或行为异常。这不是警告，是硬性限制。
-
port冲突会导致Can't start server: Bind on TCP/IP port错误，netstat -tulnp | grep :330可快速验证 -
socket路径重复会让客户端连接错乱，例如mysql -S /tmp/mysql.sock可能连到非预期实例 -
datadir共享会直接破坏数据一致性，MySQL 启动时会拒绝（报错类似Another MySQL daemon already running） - 所有日志路径（
log-error、slow_query_log_file、relay-log）也必须唯一，否则从库 IO 线程写 relay log 时可能覆盖主库错误日志
主从复制必须启用 server-id 且全局唯一
MySQL 主从复制靠 server-id 区分节点身份，它不等于端口号，但必须在所有实例中互不相同。哪怕只配一主一从，server-id=1 和 server-id=2 也不能颠倒或重复。
- 主库配置示例：
server-id = 101，并开启log-bin = mysql-bin和binlog-format = ROW - 从库配置示例：
server-id = 102，并确保relay-log = mysql-relay-102与主库无关 - 如果后续加第三个从库（如
3308实例），server-id必须是新值（如103），不能复用101或102 -
server-id = 0是非法值，会导致CHANGE MASTER TO失败，报错ERROR 1200 (HY000): The server is not configured as slave
CHANGE MASTER TO 必须指定正确的 master_host 和 master_port
从库执行 CHANGE MASTER TO 时，master_host 不能填 127.0.0.1 或 localhost 就完事——这会让 MySQL 尝试走 socket 连接，而 socket 文件路径是实例私有的，跨实例不可见。
- 必须显式指定
master_host = '127.0.0.1'（强制走 TCP） +master_port = 3306（对应主库端口） - 主库的
bind-address需设为127.0.0.1或0.0.0.0，不能是空或localhost（后者在某些版本下等价于 socket） - 主库用户需授权允许本地 TCP 连接：
CREATE USER 'repl'@'127.0.0.1' IDENTIFIED BY 'xxx'; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'127.0.0.1'; - 验证主库是否可被从库访问：
mysql -h 127.0.0.1 -P 3306 -u repl -p，失败则先解决网络层问题
从库启动后务必检查 Seconds_Behind_Master 和 IO/SQL 线程状态
即使 START SLAVE 执行成功，也不代表复制真正在工作。常见静默失败场景包括 relay log 权限不足、主库 binlog 被清理、GTID 模式未对齐等。
- 运行
SHOW SLAVE STATUS\G，重点看：Slave_IO_Running: Yes、Slave_SQL_Running: Yes、Seconds_Behind_Master: 0 - 若
IO_Running为No，查Last_IO_Error；常见原因是主库连接参数错（如密码过期、用户无权限）、主库max_connections耗尽 - 若
SQL_Running为No，查Last_SQL_Error；典型如从库表结构与主库不一致、主库执行了DROP DATABASE但从库该库下还有表 - 每个从库的
relay-log-info-file和master-info-file必须独立配置，否则两个从库会互相覆盖元数据
最易被忽略的是：主库的 binlog_expire_logs_seconds（或旧版 expire_logs_days）必须大于从库最大延迟时间，否则从库还没来得及拉取就被主库删了；同时，所有实例的 innodb_buffer_pool_size 总和不能超过物理内存，否则 swap 会拖垮整个服务器的复制延迟。
