能共存但需规避冲突：gh-ost与mysqldump/xtrabackup可同时运行，前提是避开备份锁、错开高负载窗口、确保binlog可读；mysqldump--single-transaction无直接锁冲突但增i/o压力，xtrabackup不锁表但争抢磁盘io，二者均需检查binlog_format=row、权限不含reload、禁用autocommit=0等配置。
不能直接在运行中的备份流程里跑 gh-ost，但可以共存——前提是避开备份锁、错开高负载窗口、且备份本身不阻塞 binlog 读取。
gh-ost 与 mysqldump / xtrabackup 能否同时运行
能，但不是“无条件并行”。gh-ost 本身不加表级锁（除最后 cut-over 瞬间），但它依赖持续读取 binlog 和频繁 SELECT/INSERT 操作；而备份工具的行为决定了是否冲突：
-
mysqldump --single-transaction：基于 MVCC 快照，与 gh-ost 无直接冲突，但会显著增加innodb_buffer_pool压力和磁盘 I/O，容易触发--max-load退出（如Threads_running暴涨） -
mysqldump --lock-tables或--all-databases：会锁全库或单表，gh-ost 启动即失败（报Table 't' is locked） -
Percona XtraBackup：物理备份期间不锁表，但会大量读盘 + 写 backup 文件，若磁盘 IO 已达瓶颈，gh-ost 的 chunk 拷贝可能超时或被--critical-load中断
必须检查的 3 个备份相关配置点
漏掉任一，gh-ost 可能在备份中静默失败或拖垮主库：
-
binlog_format必须为ROW：XtraBackup 不影响 binlog，但 mysqldump 若搭配--master-data，会强制执行FLUSH TABLES WITH READ LOCK—— 此时 gh-ost 连接会被阻塞，直到锁释放 -
log_slave_updates=ON（若 gh-ost 连从库）：确保从库 binlog 包含所有变更，否则 gh-ost 解析不到主库写入，ghost 表数据滞后 - 备份用户权限不能包含
RELOAD或LOCK TABLES：避免备份脚本意外调用FLUSH TABLES类命令，干扰 gh-ost 的连接状态
实际执行时怎么安排时间与参数
核心原则：让 gh-ost 主动让步给备份，而不是硬扛。
- 备份窗口内，用
--max-load="Threads_running=10"+--critical-load="Threads_running=15"极限压低 gh-ost 负载，它会自动暂停 chunk 拷贝，只维持 binlog 同步 - 避免在
pt-online-schema-change或其他 DDL 工具运行时启动 gh-ost：它们可能建临时表（如_t_new），与 gh-ost 的_t_gho/_t_ghc表名冲突 - 若备份使用
--master-data=2，务必在 gh-ost 命令中加--assume-rbr，跳过 STOP/START SLAVE 操作，否则备份的FLUSH会卡住 gh-ost 的 slave 控制流
最容易被忽略的隐性冲突点
不是锁表，而是资源争抢下的「慢失败」：
- gh-ost 默认每秒发起多次
SELECT COUNT(*) FROM t（用于估算进度），而 mysqldump 的--single-transaction会拉长事务，导致这些 COUNT 被堵在innodb_row_lock_waits队列里，gh-ost 日志显示Throttling due to load却查不到明显锁 - XtraBackup 的
--stream=tar模式若直连管道压缩（如| gzip），CPU 占用飙升，MySQL 的Performance Schema统计可能误判为「负载过高」，触发 gh-ost 主动退避 - 所有备份都应禁用
autocommit=0的客户端设置——gh-ost 内部强制用SET SESSION autocommit=1，若备份连接未重置该变量，可能污染 gh-ost 的事务行为
