这篇指南帮助你排查 MariaDB（一种关系型数据库）备份期间的锁等待问题，说明如何选择合适的备份方式避免影响线上写入。备份本身不是高风险操作，但选错方式或选错时机可能让整库写入被锁住数分钟，影响业务可用性。
如果你的数据库需要 24 小时可写，传统 mysqldump 备份方式就不适用。Hostease 中文博客的 WordPress 数据库优化关注查询性能，MariaDB 主从复制关注主从架构，本文聚焦备份本身：怎么选型、怎么验证、怎么避免备份窗口影响业务。
一、为什么备份会锁表
不同备份方式的锁机制差异很大。逻辑备份工具 mysqldump 默认会对每个表执行 FLUSH TABLES WITH READ LOCK，这个操作会获取全局读锁，期间所有写入都会被阻塞。即使后续用 –single-transaction 启用一致性快照，备份期间长事务仍然会持有 undo log（回滚日志），增加存储开销。
物理备份工具如 mariabackup、XtraBackup 通过拷贝数据文件实现备份，对业务写入几乎无影响。但物理备份对存储和 IO 有要求，且恢复流程比逻辑备份复杂。MySQL 8.0+ 的 INSTANT ADD COLUMN 也让物理备份的恢复逻辑更复杂，备份工具需要持续更新。
二、逻辑备份的锁风险
先用 mysqldump 默认方式测试锁等待时长。
mysqldump --all-databases --single-transaction > /tmp/full-backup.sql
–single-transaction 在备份开始时获取一致性快照，避免长时间锁表。但对于非事务表（MyISAM 等）或正在执行大量写入操作的表，仍可能遇到锁等待。在备份期间用 SHOW ENGINE INNODB STATUS 查看锁等待情况，关注 LATEST DETECTED DEADLOCK 和 TRANSACTIONS 节。
如果业务必须保证 24 小时可写，且 mysqldump 不可避免产生锁等待，建议改造为从库备份：在从库上跑备份，主库不承担备份压力。从库备份还可以和 主从复制结合，备份期间复制延迟会短暂升高但不影响主库可用性。
三、物理备份的优势与风险
物理备份工具（如 mariabackup）在备份期间对业务写入几乎无影响，是高写入场景的首选。
mariabackup --backup --target-dir=/var/backups/mariadb/$(date +%Y%m%d) mariabackup --prepare --target-dir=/var/backups/mariadb/$(date +%Y%m%d)
备份阶段对业务几乎无感知，但 prepare 阶段会创建长时间运行的内部事务，期间可能产生大量 undo log。如果数据量很大（如数百 GB），prepare 可能持续数小时，期间要监控磁盘空间。如果你做过 WordPress 数据库清理，提前清理冗余数据可以缩短 prepare 时间。
恢复物理备份不是简单的拷贝文件，需要通过 prepare 流程应用 redo log（重做日志）和 undo log，使备份文件达到一致性状态。错误的 prepare 操作可能导致恢复后数据不一致，建议在测试环境先演练。
四、并发备份策略
对于超大规模数据库（单库超过 1TB），单次全量备份耗时长、IO 压力大。可以做并发备份或增量备份。mariabackup 支持并行备份和增量备份。
mariabackup --backup --parallel=4 --target-dir=/var/backups/mariadb/full mariabackup --backup --incremental-basedir=/var/backups/mariadb/full --target-dir=/var/backups/mariadb/inc1
–parallel 参数控制备份线程数，根据磁盘 IO 能力调整。增量备份只备份上次全量后的变化，恢复时需要先恢复全量再逐个应用增量。备份频率根据数据变化量和恢复 RTO（Recovery Time Objective，恢复时间目标）目标决定：RTO 短的场景每 6 小时一次增量，RTO 长的可以每天一次增量 + 每周一次全量。
五、备份验证
备份本身不可信，必须验证恢复是否完整。
mariabackup --prepare --target-dir=/var/backups/mariadb/$(date +%Y%m%d) mysql -e "SELECT COUNT(*) FROM mydb.mytable;" > /tmp/row_count_after.txt mysql -e "SELECT COUNT(*) FROM mydb.mytable WHERE created_at > NOW() - INTERVAL 1 HOUR;" diff /tmp/row_count_before.txt /tmp/row_count_after.txt
对比备份前后的关键表行数和校验值，确认数据完整。还可以对关键表运行 CHECKSUM TABLE 验证数据一致性。备份验证应该定期做，每月至少一次完整恢复演练。备份如果不能恢复，等于没有备份。
六、备份窗口与业务平衡
对于写入密集型业务，备份窗口选择很重要。尽量选择业务低峰期跑全量备份，高峰期只做增量或跳过备份。如果业务 24 小时均匀写入，无法找到低峰期，强烈建议用物理备份工具或在从库上跑备份，避免影响主库。
备份期间监控三个指标：备份执行时长、备份期间主库写入延迟、备份完成后磁盘空间占用。如果备份时长超过预期，需要评估数据增长是否需要调整备份策略。如果你做过 VPS 入侵应急处理，备份是事故恢复的最后防线，不能因为备份影响业务就跳过备份本身。
备份策略之外还要考虑备份存储的安全性。备份文件包含完整数据库内容，访问权限要和数据库本身一致，不能因为是备份文件就降低权限控制。备份文件应加密存储或至少限制磁盘访问，避免备份成为数据泄露通道。异地备份（如备份到对象存储或另一个机房）可以防范单点故障，但传输过程中的网络安全也要保证。建议用专用备份账号访问数据库，账号权限仅授予备份所需的最小权限（SELECT、LOCK TABLES、RELOAD），不授予 DROP、DELETE 等危险权限。
还有一个容易被忽略的问题是备份保留周期。备份文件不能永久保留，否则磁盘空间会被耗尽。需要根据合规要求和数据变化频率制定保留策略：日备份保留 7 天、周备份保留 4 周、月备份保留 12 个月、年备份永久保留。同时记录备份文件清单和保留到期日期，定期清理过期备份。建议用脚本自动化清理流程，避免人工漏清导致磁盘空间不足。
总结
MariaDB 备份锁等待的核心是备份方式选择：逻辑备份（mysqldump）简单但有锁风险，物理备份（mariabackup）复杂但影响小。高写入场景优先选物理备份或在从库上做备份，结合增量备份减少单次备份压力。备份验证是交付清单必填项，恢复演练不能省。对于 Hostease 环境上的 MariaDB，建议默认采用物理备份 + 异地存储 + 月度恢复演练的组合，把备份验证纳入运维 SOP 而不是应急操作。