mysql主从复制的主库和从库有什么区别_mysql角色说明

主库是唯一可写节点，从库仅通过IO_THREAD和SQL_THREAD重放binlog同步数据；server-id必须全局唯一且log-bin为强制配置；mysql角色与主从无关；从库read_only可被超级用户绕过，需定期校验。

主库和从库在数据流向和权限设计上根本不同

主库是唯一允许写入的节点，所有 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' 校验，不能只信配置文件。