在提交阶段重新启动失败的事务时，我在重新启动事务时遇到第二个失败。这是在mariadb 10.2.6下运行galera集群。
事件顺序如下：
提交一个事务（比如一次插入）。
提交失败，错误为1213“尝试获取锁时发现死锁”
开始新事务以重播sql语句。
begin失败，错误为1047“wsrep尚未为应用程序使用准备节点”
我的应用程序退出以避免更严重的崩溃（参见下面的注解）
这种情况经常发生，尽管集群可以恢复，但个别线程会收到失败。昨天这件事在一秒钟内发生了15次。
我无法找出任何根本原因。看来僵局是问题的始作俑者。这种情况应该是可以恢复的（而且经常是这样），但是由于多个客户机都试图同时解决它们的死锁，整个过程似乎都失败了。
笔记：
这与前面的一个问题有关，即重试失败的事务会导致集群完全崩溃。我通过只在死锁时重试事务来防止崩溃。i、 e.如果在重新启动过程中发生不同类型的错误，应用程序将放弃。
我知道10.2.6不是mariadb的最新版本。我现在很紧张要升级，因为我有过这样糟糕的经历。我想在升级之前了解当前的问题，但我无法在测试环境中重现错误。
1条答案
按热度按时间jucafojl1#
我不确定，但我怀疑3次（不是2次）是合适的。提交包括两个步骤：
仅在所连接的节点内检查死锁(例如：另一个查询正在触及同一行或同一间隙。）
与其他节点一起检查是否会投诉(例如：同一行已经插入到另一个节点中。）
当然，这两种情况都有可能反复发生，而且以任何顺序发生。但三次尝试似乎是合理的。
现在，一旦失败“太多”次，就应该中止并让一个人（dba类型）参与进来。我怀疑您可以通过某种方式重构代码/应用程序逻辑/etc，以避免大多数失败。你能提供更多的细节吗，这样我们就可以讨论。。。
什么样的table(队列、事务、日志等）
SHOW CREATE TABLE. (汽车公司，独特的钥匙等；太多了UNIQUE钥匙会使情况恶化）这是什么意思
INSERT看起来像？你多久运行一次这样的插入？它多久失败一次(对代码进行指令插入，这样就可以计算那些可以恢复的代码。）
集群的分布情况如何(ping时间）
还有什么其他的问题(他们可能会加剧这个问题。）