MariaDB mysqldump恢复后临时库表为空的问题排查

问题背景 #

两台Debian12系统上的MariaDB10.11.4主从服务器通过SSH隧道复制正常。从库每日执行备份命令：

mysqldump --opt -uroot -p$PASS $DB | gzip > backup.$DATE.dmp.gz

将备份文件在主库恢复到临时库temp时执行：

gunzip -c backup.$DATE.dmp.gz | mysql -uroot -p$PASS temp

恢复过程无报错，但temp库仅创建表结构，无数据写入；手动插入数据正常，且在从库或其他服务器恢复该备份文件一切正常，说明备份文件本身无问题。

主库与从库的核心配置差异为主库设置了binlog_do_db = tax，迁移到新Debian服务器后出现此问题，且涉及大量Blob二进制数据的库恢复异常。

经测试确认触发条件：主库配置binlog_do_db = tax + 备份文件包含SET FOREIGN_KEY_CHECKS=0和SET UNIQUE_CHECKS=0语句时，恢复的INSERT操作完全不生效；移除binlog_do_db配置，或删除备份文件中任一SET语句，恢复均正常。

根因分析 #

按设计，binlog_do_db仅控制哪些数据库的操作会被写入二进制日志，不应影响SQL语句的执行逻辑。当前场景下出现的执行异常，大概率是MariaDB 10.11.4版本的特定Bug：当会话设置FOREIGN_KEY_CHECKS=0和UNIQUE_CHECKS=0后，与binlog_do_db的过滤逻辑产生了未预期的交互，尤其是处理Blob等二进制数据时，这种冲突导致INSERT操作被静默丢弃，而非正常执行后不写入binlog。

排查验证方向 #

• 开启通用日志（general log）：在主库临时开启general log，执行恢复操作后查看日志，确认INSERT语句是否被发送到服务器、是否执行失败或被过滤
• 检查错误日志（error log）：查看主库的MariaDB错误日志，排查是否有未被终端输出捕获的警告、错误或异常堆栈信息
• 替换binlog过滤规则：将binlog_do_db = tax替换为binlog_ignore_db（忽略除tax外的其他库），验证是否仍出现相同问题，判断是白名单逻辑的特定问题还是通用过滤逻辑冲突
• 版本验证：临时将主库MariaDB切换到10.11.5或10.6稳定版，复现恢复操作，确认是否为10.11.4版本的独有问题
• 会话参数调整测试：在恢复前手动执行SET FOREIGN_KEY_CHECKS=1; SET UNIQUE_CHECKS=1;，再导入备份数据，观察是否能正常写入数据
• 单语句测试：从备份文件中提取单个包含Blob数据的INSERT语句，在主库temp库单独执行，查看是否能成功写入，同时检查binlog是否记录该语句

临时解决方案 #

• 临时修改binlog配置：恢复前注释主库的binlog_do_db = tax配置，重启MariaDB，恢复完成后再恢复配置并重启
• 修改备份/恢复逻辑：移除备份命令中的--opt参数（--opt默认包含添加那两个SET语句的逻辑），或手动编辑备份文件删除SET FOREIGN_KEY_CHECKS=0和SET UNIQUE_CHECKS=0语句后再恢复
• 强制执行恢复：使用mysql --force参数执行恢复，强制跳过可能的语句错误（注意：此方法可能掩盖其他问题，仅应急使用）

内容的提问来源于stack exchange，提问作者Arno Schäfer