MySQL 逻辑备份怎样处理并发写入窗口

MySQL 逻辑备份能否允许并发写入，取决于备份范围的存储引擎、快照选项和业务一致性要求。对 InnoDB 数据，可用 mysqldump --single-transaction 获取一致性视图，业务 INSERT、UPDATE、DELETE 通常可以继续；但相关 DDL 应在整个导出期间冻结。若包含 MyISAM、MEMORY 等非事务表，不能仅靠这一选项承诺跨表一致，需要安排受控停写或另行设计锁定方案。

本文用一个每晚导出订单库的假设任务说明窗口安排，不声称真实事故或实测效果。命令面向 MySQL 8.4 环境，制作文章时未实际运行。工具官方说明：https://dev.mysql.com/doc/refman/8.4/en/mysqldump.html；兼容性说明：https://dev.mysql.com/doc/refman/8.4/en/mysql-nutshell.html。

触发备份前，先拆开三种“写入”

“晚上照常写订单”与“晚上照常发布表结构变更”不是同一条件。备份排期至少应分别列出业务 DML、表结构 DDL、非事务表写入。只写一句“在线备份，无需停机”，交接时很容易被理解成所有变更都能并行。

在同一订单事务里完成的多表写入，与应用分多次事务完成的跨系统业务流程也不同。数据库的一致性快照不能自动修补应用自身未完成的业务步骤；如果业务要求“全部对账完成后的批次”，应先与业务方定义批次截止条件。

固定工具和权限，不把旧脚本原样迁移

MySQL 8.4 已移除 mysqlpump；旧任务仍调用它时，应先调整工具选择，而不是继续复制旧环境命令。本文选择 mysqldump，只示范普通业务库逻辑导出，不涉及账号迁移、复制初始化和时间点恢复。

权限按实际对象和选项授予：表数据需要 SELECT，视图与触发器有各自权限要求；存储过程和事件还需相应读取权限。是否导出表空间、是否请求日志坐标和 GTID 信息也会影响权限。不要为了解决一次报错直接把备份账号换成管理员。

-- 在业务授权范围内查看表引擎；示例库名需替换成真实备份目标。
SELECT TABLE_NAME, ENGINE
FROM information_schema.TABLES
WHERE TABLE_SCHEMA='orders_app' AND TABLE_TYPE='BASE TABLE'
ORDER BY TABLE_NAME;

同时确认执行机器的 mysqldump 版本、目标服务器版本，以及默认配置文件里是否暗含额外选项。本文示例假定所有业务基表为 InnoDB，备份账号和客户端配置已由管理员准备；不在命令行写明文密码，也不把凭据写入任务日志。

把业务窗口写成可交接的计划

备份启动前，调度器应先取得本次任务的独占执行权，确认不会与另一份导出、表结构迁移或发布任务重叠；发布系统也要承认这个冻结约定。导出开始到结束期间，不对涉及的对象执行 ALTER TABLE、CREATE TABLE、DROP TABLE、RENAME TABLE、TRUNCATE TABLE 等结构变更。

single-transaction 并不表示备份保存的是命令结束时的最新数据。应把“快照基准”和“任务完成时刻”分开记录，结束前新提交的订单可能不属于这份导出。跨库且存在关联的数据，应放在同一一致性范围内考虑，不能各自启动独立导出后就宣称拥有相同基准。

如果还要记录二进制日志坐标，应单独评估 --source-data 与权限、短暂全局读锁及等待影响。本文不加入该选项，不能因此把下面的导出称为完整的时间点恢复方案。不同选项组合改变窗口要求，不能把“快照在线”扩展成“绝对不会等待或影响业务”。

示例任务先写独立产物，再记录导出状态

下面是 Bash 示例：在当前受控工作目录创建独立子目录，使用已经配置好的 backup 登录路径。orders_app、登录路径和执行位置都需由操作者按本地授权配置替换；该示例不是立即可运行的生产任务。目录权限受 umask 约束，失败保留 partial 文件和错误日志，不覆盖上一份已知可用备份。

#!/usr/bin/env bash
# 只示范导出，不在源库写数据；每次运行使用独立目录。
set -eu
umask 077
backup_run_dir=$(mktemp -d ./backup-run.XXXXXX)
printf '本次输出目录：%s\n' "$backup_run_dir"

# backup 登录路径须预先配置。最后显式关闭表锁选项。
# OFF 不输出 GTID_PURGED 信息：本例不用于复制初始化或时间点恢复。
if mysqldump --login-path=backup \
    --single-transaction --quick --no-tablespaces \
    --set-gtid-purged=OFF --routines --events --triggers \
    --skip-lock-tables \
    --result-file="$backup_run_dir/orders.sql.partial" \
    orders_app 2>"$backup_run_dir/dump.stderr.log"; then
    # 改名只表示导出进程成功，不表示已通过恢复演练。
    mv "$backup_run_dir/orders.sql.partial" "$backup_run_dir/orders.sql"
    printf '导出进程成功；仍需按交付规则确认业务窗口。\n'
else
    dump_exit_code=$?
    printf '导出失败，退出码=%s；保留 partial 与日志。\n' "$dump_exit_code" >&2
    exit "$dump_exit_code"
fi

--quick 用于逐行提取以避免把整表结果先缓存在客户端；它不是一致性开关。--no-tablespaces 排除表空间语句，不意味着产物适用于所有表空间恢复场景。--skip-lock-tables 与 --single-transaction 的取舍针对本例全 InnoDB 范围，不能拿来保护 MyISAM 的并发变化。

退出码为零只能确认导出进程成功完成；还要确认本次业务范围、DDL 冻结和引擎前提没有失守。若还有压缩、加密、上传等后续步骤，调度系统应分别记录各自状态，不能让最后一条通知命令的成功掩盖前面导出失败。恢复演练应在独立环境按组织流程安排，不向生产库直接回灌。

窗口失守或任务失败，保留证据再重新安排

若导出期间发生相关 DDL，即使命令看似成功，也不应直接宣布这份备份满足原定一致性目标。记录冲突对象和时间，由负责人确认影响，重新安排受控窗口。非事务表仍有写入时，同样不能用“重跑直到退出码为零”解决一致性问题。

若必须跨引擎保持整体状态，应评估业务停写范围，涵盖应用、批处理、事件和其他写入入口；选择锁定策略时也须评估其覆盖范围与业务等待，而不是默认某个按库加锁选项能保护全部跨库关联。本例不自动执行全局锁或停业务命令，这些动作应由明确的维护流程授权。

失败收尾至少应做到：保留最后一份已知可用备份；将当前产物标为未交付；记录退出码和实际错误；确认导出连接已结束，再释放本次窗口；需要重试时创建新的独立产物。不要在失败分支里删除所有历史备份以腾空间。

通知和复盘记录实际范围，不只写“备份成功”

交接消息应包含目标实例与库范围、存储引擎前提、客户端版本、脱敏后的选项、任务起止时间、DDL 冻结负责人、产物位置和导出退出状态。恢复演练完成与否另列一项，不能用文件存在或文件非空代替可恢复性结论。

用了 single-transaction，还需要停止订单写入吗？

全 InnoDB 且满足本例前提时，通常不必为了数据快照暂停普通 DML；相关 DDL 仍需冻结，应用特殊批次截止要求另算。

只冻结备份开始的几秒钟 DDL 可以吗？

不能按这个简化假设安排。官方限制覆盖单事务导出进行期间，不只是启动瞬间。

导出文件包含备份结束前所有新订单吗？

不保证。快照基准与导出结束时刻不同，需要恢复更新变化时还要设计日志保留和恢复链路，本文命令没有提供这一链路。

合理的并发写入窗口不是“全部停写”与“完全不管”的二选一，而是将事务数据快照、结构变更冻结和非事务表保护分开落实。这样任务状态才能与业务承诺对应。