主库和从库在数据流向和权限设计上根本不同
主库是唯一允许写入的节点，所有
INSERT、
UPDATE、
DELETE操作必须发生在主库；从库默认拒绝写入（即使手动执行也会报错或被复制冲突中断），它只通过
IO_THREAD和
SQL_THREAD重放主库的
binlog来保持数据一致。这不是配置限制，而是复制机制的底层约定——一旦从库被写入，就可能破坏与主库的二进制日志序列对应关系，导致同步断裂。
server-id 和 binlog 是区分主从的硬性前提
MySQL 不靠角色名或标签识别主从，而靠两个强制配置项：
server-id必须全局唯一，主库和每个从库都不能相同（例如主库设为
137，从库设为
138） 主库必须启用
log-bin（如
log-bin = binlog），从库可不开启，但若要升级为主库或参与级联复制，也得开 从库还需显式配置
relay-log（如
relay-log = relay-bin），否则中继日志无法落盘，
SQL_THREAD就没东西可执行
漏配任一参数，
START SLAVE会静默失败或报错
ERROR 2003 (HY000)/
ERROR 1236，而不是提示你缺了哪项。
MySQL 角色（ROLE）和主从无关，别混淆概念
MySQL 的
ROLE是 8.0+ 引入的权限管理抽象层，和主从复制完全解耦。它不决定服务器是主还是从，也不影响复制行为：
CREATE ROLE 'rd_only'这类语句只能在用户账户上授予权限，对
replication slave账户无意义 复制账号（如
'repl'@'192.168.%'）只需要
REPLICATION SLAVE权限，不需要、也不能被赋予任何
ROLE你在主库上给应用用户建了个
app_reader角色，这个角色不会自动同步到从库——从库上的同名用户得单独
GRANT，且
FLUSH PRIVILEGES也得分别执行
误以为“给主库用户加了角色，从库就自动有权限”，是线上权限混乱的常见源头。
最容易被忽略的实操细节：从库写操作不是“禁止”，而是“危险但可绕过”
从库默认
read_only = ON，但这只是个开关，不是铁壁： 超级用户（
SUPER或
SYSTEM_VARIABLES_ADMIN权限）仍可写，比如 DBA 登录后执行
SET GLOBAL read_only = OFF，立刻就能
INSERT一旦写了，
binlog若开启，这些操作会被记录——如果该从库又作为另一台机器的主库，就会把脏数据传下去 更隐蔽的是：某些监控脚本或旧版 ORM 会尝试在从库上建临时表或写
information_schema衍生表，触发
read_only报错却未捕获，导致任务静默失败
所以生产环境不仅要设
read_only = ON，还应定期用
SELECT @@read_only和
SHOW VARIABLES LIKE 'read_only'校验，不能只信配置文件。
