MariaDB 10.4.12：审计日志记录DML但未在数据库执行的异常

可能的原因及排查方向 #

• 事务提交隐性失败：审计日志的返回码0仅代表单条语句执行完成，不代表整个事务最终提交。如果批量插入在显式事务中执行，若客户端异常断开、应用未执行COMMIT就终止，事务会回滚，但审计日志仍会记录语句。检查应用端事务逻辑，确认每个批量插入后是否有明确的COMMIT；查看数据库error.log是否有客户端异常断开的记录，或通过历史PROCESSLIST排查未提交事务。
• binlog过滤或临时关闭：检查是否配置了binlog_do_db/binlog_ignore_db规则，这类规则会让符合条件的语句不写入binlog但仍被审计日志记录。另外，若应用代码中存在临时执行SET sql_log_bin=0的逻辑，也会导致该会话的语句不进binlog。执行SHOW GLOBAL VARIABLES LIKE '%binlog%'确认过滤配置，同时排查应用代码的相关逻辑。
• MariaDB 10.4.12版本bug：该版本属于10.4系列较早版本，存在高并发场景下binlog丢写的已知问题（比如sync_binlog=1配置下的竞态条件）。建议升级到10.4系列最新稳定版（如10.4.32+），验证问题是否复现。
• 日志记录时机差异：审计日志在语句执行后立即记录，而binlog要等事务提交时才写入。若存在长时间未提交的事务，其中的语句只会出现在审计日志。通过SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX查看未提交事务，或检查binlog末尾位置确认是否有未刷入的事务。
• 磁盘/文件系统异常：即便配置了sync_binlog=1和innodb_flush_log_at_trx_commit=1，若磁盘存在IO故障、文件系统缓存异常（如ext4未开启barrier），可能导致binlog写入后未持久化，重启后丢失。查看系统dmesg日志、用iostat监控磁盘IO，确认是否有IO错误或超时。

验证手段 #

• 手动执行单条批量插入语句，同步核对审计日志与binlog，确认成功执行的语句是否都会写入binlog。
• 临时开启general_log，对比审计日志与general_log的一致性，再交叉验证binlog，定位未进入binlog的语句范围。
• 检查binlog_error_action参数，确认binlog写入失败时的处理策略，是否存在忽略错误的配置。

内容的提问来源于stack exchange，提问作者Jaya Karthik