read_only=1不能保证备份一致性位点，因其仅限制非super用户写入，不控制binlog position、gtid或事务快照；真正锚定位点需ftwrl或--single-transaction配合show master status/show gtid_executed。
read_only 本身不能保证备份时的一致性位点，它只是阻止非 super 用户写入，对 binlog position、GTID 或事务快照无控制能力。真正能锚定一致性位点的是 FLUSH TABLES WITH READ LOCK（FTWRL）或 --single-transaction 配合 SHOW MASTER STATUS / SHOW GTID_EXECUTED。
为什么 read_only=1 不能用于备份一致性位点
它只限制 SQL 层写操作，不影响以下关键行为：
- 复制线程（IO/SQL thread）仍可拉取并执行主库 binlog，导致从库位点持续前移
- 备份工具（如
mysqldump）在read_only下仍可能因未加锁而读到中间状态（尤其跨表关联或非事务表） - 不暴露当前 binlog 文件名、position 或 GTID 集合，无法记录“这一时刻的数据对应哪个位点”
- 重启后失效（除非写入配置文件），且无法与备份动作原子绑定
mysqldump 备份时如何获取一致性位点
取决于存储引擎和参数组合，核心是先锁定或快照，再抓位点：
MySQL（Linux）
下载
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
- 对 InnoDB 表：用
--single-transaction启动事务级快照，然后立即执行SHOW MASTER STATUS（主库）或SHOW SLAVE STATUS（从库 Relay_Master_Log_File + Exec_Master_Log_Pos）获取位点 - 含 MyISAM 或需全库强一致：必须用
FLUSH TABLES WITH READ LOCK，再执行SHOW MASTER STATUS，最后UNLOCK TABLES—— 此过程会阻塞所有写，但位点绝对精确 - 启用 GTID 时：优先用
SELECT @@GLOBAL.GTID_EXECUTED，它比 binlog position 更可靠，且无需锁表（--single-transaction+--set-gtid-purged=OFF即可） - 注意：
mysqldump --master-data=2会自动在 dump 文件开头插入CHANGE MASTER TO语句，但它依赖执行时刻的位点，若 dump 过程中主库有新事务提交，该位点可能已过期 —— 所以务必确认 dump 前是否已停写或使用 FTWRL
MySQL 8.0 新增的 ALTER DATABASE ... READ ONLY = 1 能否替代？
不能。这个语法仅控制单个库的 DDL/DML 权限，和一致性位点无关：
- 它不冻结 binlog position，也不阻塞复制线程应用日志
- 不提供任何接口输出当前位点，也无法与备份流程联动
- 适用于迁移期间临时禁止某库变更，但不是备份一致性机制
- 若误以为设了
READ ONLY就能直接 dump，很可能拿到非一致快照（尤其存在跨库 JOIN 或外键时）
最容易被忽略的实操细节
一致性位点不是“设个开关就自动出来”的东西，它必须由你主动捕获并显式记录：
- 用
FLUSH TABLES WITH READ LOCK时，连接不能断开 —— 一旦断开，锁自动释放，后续SHOW MASTER STATUS的结果就失效 -
--single-transaction只对 InnoDB 有效；如果库中混有 MyISAM 表，必须配合 FTWRL，否则这些表的数据可能不一致 - GTID 模式下，
mysqldump --gtid会自动注入SET GTID_PURGED，但要求源实例未 purged 对应 GTID，否则恢复时报错 - 云 RDS（如阿里云、AWS）通常禁用 FTWRL，此时唯一可靠方式是
--single-transaction+SELECT @@GLOBAL.GTID_EXECUTED，且必须确保备份窗口内无 DDL（DDL 会隐式提交事务，破坏快照边界）
