可以，但需绕过权限检查；mysqldump 默认尝试 FLUSH TABLES WITH READ LOCK（需 RELOAD 权限），应改用 --single-transaction 或 --skip-lock-tables，并确保 SELECT、SHOW VIEW 等必要权限。
只读数据库能用 mysqldump 吗？可以，但得绕过权限检查
MySQL 的只读模式（read_only=ON）本身不阻止 mysqldump，真正卡住的是用户权限。常见错误是：明明有 SELECT 权限，却报 Access denied for SELECT command denied to user —— 实际上是因为 mysqldump 默认会尝试执行 FLUSH TABLES WITH READ LOCK，而该操作需要 RELOAD 权限，只读库用户往往没这个权限。
解决方法是跳过锁表：
- 加
--single-transaction（对 InnoDB 表有效，靠 MVCC 保证一致性，无需全局锁） - 或加
--skip-lock-tables（适用于 MyISAM 或混合引擎，但备份期间可能有数据不一致风险） - 确保用户至少有
SELECT、SHOW VIEW、LOCK TABLES（如果没禁用锁）和PROCESS（用于获取表结构）权限
遇到 ERROR 1290 (HY000): The MySQL server is running with the --read-only option 怎么办？
这不是备份命令报的错，而是你试图在只读实例上执行写操作（比如 mysqldump 带 --master-data 且服务器没开 log_bin，或用了 --dump-slave 却没从库权限）。关键点在于：只读限制的是写，不是备份本身。
排查方向：
- 去掉
--master-data=1/2或--dump-slave=1/2—— 它们会触发SHOW MASTER STATUS或SHOW SLAVE STATUS，某些只读配置下这些语句被拦截 - 确认是否误连到了从库且该从库启用了
super_read_only=ON（比read_only更严格，连 super 用户都受限） - 用
--no-tablespaces避免因INFORMATION_SCHEMA.INNODB_SYS_TABLESPACES权限缺失导致失败
只读库没有 mysqldump 怎么办？用 mysqlpump 或原生导出
mysqlpump 是 MySQL 5.7+ 自带的并行逻辑备份工具，对只读环境更友好：默认不加全局锁，支持 --skip-lock-tables 和 --single-transaction，且权限需求更低。但它要求用户有 SELECT + SHOW VIEW + TRIGGER（如果导出触发器）即可。
实在不行，就退到最朴素方式：
- 用
SELECT ... INTO OUTFILE导出单表（需FILE权限，且文件写在服务端磁盘） - 用客户端工具如
mysql -e "SELECT * FROM t" > t.csv（注意字符集和字段分隔符） - 避免用
mysqldump --tab，它依赖FILE权限且生成两部分（SQL + 数据文件），在只读+权限受限环境下极易失败
物理备份（xtrabackup）在只读实例上可行吗？可以，但别碰日志
Percona XtraBackup 不依赖 MySQL 权限，直接读取数据文件，所以 read_only 对它完全透明。但要注意：
- 必须关闭
innodb_log_archive（已废弃，但旧配置可能残留） - 不要加
--backup同时启用--apply-log—— 后者会写入日志文件，只读文件系统或挂载为 ro 的目录会失败 - 若数据库启用了加密表空间（
innodb_encrypt_tables=ON），需提前准备好密钥文件路径，xtrabackup本身不处理密钥分发 - 备份后校验用
xtrabackup --verify，而不是启动实例，避免意外写操作
只读环境最易被忽略的点：备份脚本里藏着 SET GLOBAL read_only=OFF 这类“自动修复”逻辑 —— 在生产只读库上运行等于埋雷。所有备份操作必须严格限定在只读语义内，连临时 SET 都不该出现。
