宝塔面板不提供一键主从同步，需手动配置mysql原生复制：主库必须开启可写binlog（路径存在且授权）、设唯一server-id、binlog-format=row；从库需配不同server-id、read_only=1，并严格按show master status的file和position执行change master to，再start slave验证状态。
宝塔面板本身不提供“一键开启主从同步”的全自动功能，所谓“实时同步”实际是 MySQL 原生的主从复制机制在起作用，宝塔只是帮你管理配置、执行命令和查看状态。直接上手配错一步，START SLAVE 就会卡住或报错，最常见的是连不上、权限不对、binlog 位置错、read_only 没生效。
主库必须打开 binlog 且路径可写
宝塔默认不启用 binlog，光在 my.cnf 里加 log-bin=mysql-bin 不够——你还得确认 MySQL 进程对日志目录有写权限，且目录存在。宝塔通常把数据放在 /www/server/mysql/data/，但 binlog 默认写到 /www/server/mysql/binlog/，这个目录可能根本不存在。
- 先手动创建目录：
mkdir -p /www/server/mysql/binlog，再chown -R mysql:mysql /www/server/mysql/binlog - 在宝塔【数据库】→【设置】→【配置修改】中，
[mysqld]下写全路径：log-bin = /www/server/mysql/binlog/mysql-bin - 顺手加上
binlog-format = ROW（别用 STATEMENT，含NOW()或触发器时主从数据会不一致） - 保存后务必点【重启数据库】，否则配置不加载
从库连不上主库？先查 bind-address 和防火墙
CHANGE MASTER TO 执行成功不代表能连通。很多人在宝塔里改了 my.cnf 却忘了最关键的网络层限制：MySQL 默认只监听 127.0.0.1，从库发来的连接请求直接被拒。
- 进宝塔【数据库】→【配置修改】，找到
bind-address行，改成bind-address = 0.0.0.0或主库真实内网 IP（如192.168.1.10），别留空或注释掉 - 检查宝塔自带防火墙：【安全】→ 开放端口
3306 - 再查系统级防火墙：
firewall-cmd --list-ports（CentOS）或ufw status（Ubuntu），确保3306放行 - 测试连通性不要只用
ping，要用telnet 主库IP 3306或mysql -u repl -p -h 主库IP -P 3306
CHANGE MASTER TO 的参数不能凭记忆填
MASTER_LOG_FILE 和 MASTER_LOG_POS 必须严格对应 SHOW MASTER STATUS 的实时输出，哪怕差 1 字节，从库就无法定位起始位置，Slave_IO_Running 会卡在 Connecting 状态。
- 主库执行
FLUSH TABLES WITH READ LOCK后立刻运行SHOW MASTER STATUS，记下File（如mysql-bin.000002）和Position（如154） - 从库执行
CHANGE MASTER TO时，所有值都要原样粘贴，注意引号、分号、逗号位置——宝塔里直接在终端输，别用 phpMyAdmin 的 SQL 窗口（容易吞空格） - 如果主库已运行很久，
Position可能是几百万甚至上千万，别手输，用鼠标复制 - 别漏掉
MASTER_PORT=3306，虽然默认是 3306，但显式写出更稳妥
从库启动后必须验证 Slave_SQL_Running 而非只看 Yes
SHOW SLAVE STATUS\G 输出里两个 Yes 是基本门槛，但真正决定同步是否有效的是 Seconds_Behind_Master 是否稳定、SQL_Delay 是否为 0、以及有没有跳过错误（Skipping event）。
-
Seconds_Behind_Master: NULL表示 SQL 线程没启动或出错，不是延迟高 -
Seconds_Behind_Master: 0只代表当前追平，不代表持续可用——大事务进来后可能瞬间涨到几百秒 - 重点盯
Last_IO_Error和Last_SQL_Error，哪怕值为空，也要定期SHOW SLAVE STATUS查看 - 从库务必在
my.cnf里写死read_only = 1（不是SET GLOBAL read_only = 1），否则人为写入会破坏一致性，且重启后失效
主从同步不是设完就一劳永逸的事，Seconds_Behind_Master 的波动、relay log 磁盘占满、主库 expire_logs_days 清得太早导致从库找不到旧 binlog，这些才是日常运维中最容易被忽略的断点。
