重启死锁事务时导致后续错误的原因是什么？

Question

在提交阶段重新启动失败的事务时，重新启动事务时会出现第二次失败。这是在MariaDB 10.2.6下运行Galera集群。

事件的顺序如下：

1. 提交交易（比如单个插入）。
2. COMMIT失败，error 1213“尝试锁定时发现死锁”
3. 开始新事务以重播SQL语句[s]。
4. BEGIN以error 1047失败“WSREP尚未为应用程序使用准备节点”
5. 我的申请无法避免更严重的崩溃（请参阅下面的说明）

这种情况经常发生，虽然群集恢复，但各个线程都会收到故障。昨天这种情况在一秒内发生了15次。

我无法确定任何根本原因。似乎死锁是问题的始作俑者。这种情况应该是可以恢复的（并且经常是这样）但是由于多个客户端都试图同时解决它们的死锁，整个事情似乎都失败了。

注意：

这与earlier question有关，其中重试失败的事务导致集群完全崩溃。我设法通过仅在死锁上重试事务来防止崩溃。即如果在重启期间发生了不同类型的错误，则应用程序放弃。

我知道10.2.6不是MariaDB的最新版本。因为我有这么糟糕的经历，我现在很紧张升级。我想在升级之前了解当前的问题并且我无法在测试环境中重现错误。

Answer 1

我不确定，但我怀疑3次尝试（不是2次）是合适的。提交涉及两个步骤：

• 完全在您连接的节点内检查死锁。 （例如：另一个查询触及相同的行或间隙。）
• 检查其他节点是否会抱怨。 （例如：已将同一行插入另一个节点。）

当然，其中任何一种都可能反复发生，也可能以任何顺序发生。但是进行3次尝试似乎是合理的。

现在，一旦你失败了“太多”次，就可以中止并获得一个人（一个DBA类型）。我怀疑你可以用某种方式重构你的代码/应用程序逻辑/等，以避免大多数失败。您是否想提供更多详细信息，以便我们讨论这种可能性......

• 什么样的桌子？ （队列，交易，记录等）
• SHOW CREATE TABLE。 （auto_inc，唯一键等;太多UNIQUE键可能会加剧这种情况）
• INSERT看起来像什么？
• 您多久运行一次这样的插页？它多久失败一次？ （检测您的代码，以便计算可以从中恢复的代码。）
• 群集是如何分散的？ （平时）
• 还有什么其他疑问？ （他们可能会加剧这个问题。）