主库需开启binlog并配置唯一server-id：在my.cnf的[mysqld]段添加log-bin=mysql-bin、server-id=1、binlog-format=ROW，重启后用SHOW VARIABLES确认生效。
主库怎么开 binlog 并配好唯一 server-id
MySQL 主从复制的前提是主库必须开启二进制日志（binlog），否则从库根本没东西可拉。默认很多安装包（比如某些 Docker 镜像或一键脚本）会关掉 binlog，或者压根没配 server-id —— 这会导致从库启动时报错 ERROR 1236 (HY000): Could not find first log file name in binary log index file 或直接拒绝连接。
实操建议：
- 编辑主库配置文件（通常是
/etc/mysql/my.cnf或/etc/my.cnf），在[mysqld]段下确保有：log-bin = mysql-bin<br>server-id = 1<br>binlog-format = ROW
-
server-id必须是正整数，且主从不能重复；主库设为1是常见做法，但不是强制，只要全局唯一就行 -
binlog-format推荐用ROW，语句级（STATEMENT）在函数、时间戳、自增等场景下容易主从不一致 - 改完重启 MySQL（
systemctl restart mysql），然后进 MySQL 执行SHOW VARIABLES LIKE 'log_bin';和SHOW VARIABLES LIKE 'server_id';确认生效
从库怎么连上主库并指定起始位置
从库靠 CHANGE REPLICATION SOURCE TO（MySQL 8.0.23+）或旧版 CHANGE MASTER TO 命令告诉自己“去哪拉日志、从哪开始拉”。很多人卡在这步，不是账号没权限，就是位点（source_log_file / source_log_pos）填错了。
实操建议：
- 主库上先创建复制专用账号：
CREATE USER 'repl'@'%' IDENTIFIED WITH mysql_native_password BY 'your_strong_pass';<br>GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';<br>FLUSH PRIVILEGES;
- 主库执行
SHOW MASTER STATUS;记下当前File和Position（比如mysql-bin.000002和154） - 从库执行：
CHANGE REPLICATION SOURCE TO<br> SOURCE_HOST='主库IP',<br> SOURCE_USER='repl',<br> SOURCE_PASSWORD='your_strong_pass',<br> SOURCE_LOG_FILE='mysql-bin.000002',<br> SOURCE_LOG_POS=154;<br>START REPLICA;
- 注意：MySQL 8.0.23+ 用
SOURCE_*前缀，旧版本用MASTER_*；命令里不能漏掉分号，START REPLICA（非START SLAVE）是新语法
怎么确认复制真跑起来了，而不是假活
执行 START REPLICA 后，很多人只看 SHOW REPLICA STATUS\G 里 Replica_IO_Running 和 Replica_SQL_Running 都是 Yes 就以为完事了。其实这两项可能短暂为 Yes 又变 No，或者卡在某个错误上不动，而 Seconds_Behind_Master 显示 NULL 或一直不变。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
实操建议：
- 重点盯三个字段：
Replica_IO_Running（网络连接和日志接收）、Replica_SQL_Running（本地回放）、Seconds_Behind_Master（延迟秒数） - 如果任一为
No，立刻查Last_IO_Error或Last_SQL_Error字段，常见如Access denied（账号权限问题）、Could not parse relay log event entry（格式不兼容）、Duplicate entry（主从数据不一致导致冲突） - 用
SHOW PROCESSLIST;看有没有Replica_IO和Replica_SQL线程在运行 - 最稳的验证方式：主库建个测试表、插一行，等几秒后去从库查，别只信状态字段
为什么从库写入后主从就裂开了
异步复制本身不阻止你在从库写数据，但一旦你执行了 INSERT、UPDATE 或 DROP，后续主库发来的同表同行操作大概率报错（比如 Duplicate entry 或 Can't find record），Replica_SQL_Running 直接挂掉。这不是 bug，是设计如此。
实操建议：
- 生产环境从库务必加
read_only = ON（写在my.cnf的[mysqld]下），它能拦住普通用户写操作（root 仍可写，所以还要配合账号权限控制） - 如果真需要从库临时写，先
SET GLOBAL read_only = OFF;，操作完立刻关回去，且要清楚后果：之后得人工跳过错误或重搭从库 - 不要依赖
skip_slave_start或盲目用SET GLOBAL sql_slave_skip_counter = 1跳错——这相当于把病灶捂住，下次还犯 - 异步复制没有强一致性保障，高并发写 + 网络抖动时，
Seconds_Behind_Master拉到几十秒甚至几分钟都正常，别一看到延迟就 panic
主从复制看着步骤少，真正麻烦的是位点对齐、权限闭环、错误归因和只读防护——这些地方松一扣，后面排查起来全是时间黑洞。
