在提交查询期间丢失到数据库的连接:事务是否成功？

Question

问题

最近，我在MySql (查询期间丢失到MySQL服务器的连接)为事务执行COMMIT语句(前面的update语句成功)时遇到了2013年的错误。这是由于提交期间发生了网络停机错误。

然后，我启动了一个新的连接，在检查事务效果之后，我可以看到事务确实已成功提交，并且没有错误(应用了更改)。

问题

在COMMIT查询期间出现错误时，如何100%确保提交成功？有没有人发现类似的问题？当这种模棱两可的情况出现时，最好的方法是什么？有没有办法避免这种“提交歧义”？

以前的研究

我在这里发现了一些与其他数据库和MySql相关的问题：

• 如果连接丢失/中断，是否中止Postgres长期运行的查询？
• 如果数据库节点的网络在提交之后和响应客户端之前失败，会发生什么？
• 导致MySQL提交查询失败的条件？
• 如果连接在提交过程中关闭怎么办？
• https://stackoverflow.com/questions/3960189/can-a-commit-statement-in-sql-ever-fail-how

但似乎没有办法避免这个问题？

谢谢!

Answer 1

立即想到的是二进制日志。

COMMIT;命令总是记录在二进制日志中。您可以通过对二进制日志运行mysqlbinlog程序来证明这一点，您应该会看到一些。

有人在是在二进制日志之前还是之后回复客户端有关事务提交的信息？上发布了这个例子

# at 1016
[..]
SET TIMESTAMP=1458127130/*!*/;
create table tr (i int) engine=innodb
[...]
# at 1281
[..]
SET TIMESTAMP=1458127136/*!*/;
BEGIN
/*!*/;
# at 1384
[..]
SET TIMESTAMP=1458127136/*!*/;
insert into tr values(1),(2),(3)
/*!*/;
# at 1514
[...]
COMMIT/*!*/;

请注意什么是MySQL文档在“二进制日志”中写道

二进制日志记录是在语句或事务完成后，但在释放任何锁或完成任何提交之前立即完成的。这确保日志按提交顺序登录。

这意味着，即使COMMIT;没有进入二进制日志，更改也会在COMMIT;之前记录在二进制日志中。