mysql - Percona XtraDB Cluster多节点写入和事务外意外死锁？

Question

我无法使用 google 或 Stack Overflow 找到这个问题的答案，所以熟悉 Percona XtraDB 的人也许可以帮助回答这个问题。我完全理解如何发生意外死锁，如本文所述，解决方案是确保使用重试逻辑包装事务，以便在事务失败时可以重新启动它们。我们已经这样做了。

https://www.percona.com/blog/2012/08/17/percona-xtradb-cluster-multi-node-writing-and-unexpected-deadlocks/

我的问题是关于自动提交模式下事务之外发生的正常更新。通常，如果您仅写入单个 SQL 数据库并执行更新，您将获得最后获胜的场景，因此无论谁最后执行该语句，都是黄金。任何其他数据都会丢失，因此如果两个更新同时发生，其中一个将生效，而其他数据基本上会丢失。

现在在具有相同情况的多主环境中会发生什么？集群模式与多主机的区别在于，死锁可能发生在提交发生的时刻，而不是第一次在表上获取锁时。因此，在自动提交模式下，数据将写入数据库，但如果其他东西同时修改了完全相同的记录，则当它尝试将其提交到集群中的其他节点时，数据可能会失败。显然，简单的解决方案是再次重新执行更新，在我看来，数据库本身应该能够处理这个问题，因为它是自动提交模式下的单个语句？

那么在这种情况下会发生什么，或者我是否需要开始将所有更新代码包装在重试处理中，并在失败时自己重试？

Answer 1

自动提交仍然是一个事务；单个语句事务。您的单个语句只是为您包裹在 BEGIN/COMMIT 中。我相信你的逻辑是颠倒的。在 PXC 中，规则是“先提交者获胜”。如果您在节点 1 上启动手动事务(即:autocommit=0; BEGIN;)并且 UPDATE id=1 并且不提交，那么在节点 2 上您将自动提交对同一行的更新，该更新将在节点 2 上成功，并在节点 1 上成功。当您提交手动 UPDATE 时，您将收到死锁错误。这是正确的行为。

是否自动提交并不重要；先提交的事务获胜，而另一个事务必须重试。这就是为什么我们不建议在 PXC 中写入多个节点的原因。

是的，如果您想写入多个节点，您需要调整代码以“try-catch-retry”处理此错误情况。