主库是唯一可写节点，从库仅通过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+ 引入的权限管理抽象层，和主从复制完全解耦。它不决定服务器是主还是从，也不影响复制行为：
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
-
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' 校验，不能只信配置文件。
