问题标签 [percona-xtradb-cluster]

升级到 Flyway 4.2.1 后，我们在发布到 Percona MySQL 集群时开始出现错误。我们得到的错误是：

看起来 Flyway 4.1+ 试图锁定表，而 Percona 的 PXC 严格模式不允许这样做。

我相信我的问题是：我们可以在 Flyway 4.1+ 方面做些什么来避免这个错误（之前在 Flyway 4.0 中一切正常）还是我们唯一的选择是在 Percona 中禁用 PXC 严格模式？

谢谢！

我的mysql集群：Ver 5.6.30-76.3-56 for debian-linux-gnu on x86_64 (Percona XtraDB Cluster (GPL), Release rel76.3, Revision aa929cb, WSREP version 25.16, wsrep_25.16)

我有一个复杂的 sql 查询，它使用以下语法将大约 36k 行插入到表中：

选择有点复杂但并不慢（0.0023 秒），但插入大约需要 40-50 秒。当我插入行时，该表未使用。

我的问题是：

• 我可以以某种方式加快速度吗？
• 缓慢的插入导致其他表上的锁定问题（因为选择）
• 这个工作流程是好还是坏的做法？有没有更好的？

谢谢

更新：

表架构：

更新2：

当我尝试运行查询时，在某些情况下会出现错误：

我的解决方案：

如果有人感兴趣，这是我的最终解决方案： gist

主要问题是，当我填写mytable其他查询时，其他查询卡住了，并且集群出现了严重的性能问题。在这个解决方案中，我创建了一个临时表并在“脏读”模式下用数据填充它，然后我将这些数据复制到mytable块中，这样会花费更多时间，但没有性能问题并且不会卡住查询。

我正在尝试在三台干净的 centos 机器上启动集群。

我试图保持这篇文章简短，我没有附加配置文件，因为我使用了本指南并且配置文件是这样的：

https://www.percona.com/doc/percona-xtradb-cluster/5.7/add-node.html#add-node

启动第一个节点正常。启动第二个节点错误。

这是第二个节点上的日志

--defaults-file '/etc/my.cnf' --defaults-group-suffix '' --parent '5490' '' : 2 (没有这样的文件或目录) 2017-09-28T15:05:09.370161Z 2 [错误] WSREP：无法准备“xtrabackup-v2”SST。不可恢复。2017-09-28T15:05:09.370192Z 2 [错误] 中止

我们一直在为我们的电子商务网站使用 Percona Mysql 主从配置，即单主和 2 个只读从属，以及一个额外的从属来执行备份和报告。

我们观察到负载没有分布，因为我们的主服务器加载了所有写入操作，而从服务器仅用于读取操作。

考虑到这一限制，我们计划对我们的数据库基础设施进行增强。

我们的一种选择是转向 Percona XtraDB 集群（master-master）。

请建议任何其他对电子商务网站有用的首选方法。

问候

查尔斯

我在 3 个节点（节点 1、节点 2、节点 3）中运行 Percona XtraDB 集群。我已经在第 4 个节点（管理员）中配置了 ProxySQL。

我有一个尝试访问集群的 python 应用程序代码。

在连接到 node1 的 3306 端口时，我能够连接。

为了实现负载均衡，应用程序应指向 ProxySQL 端口 6032。

在尝试连接时，我收到以下错误：

我在proxysql中使用了grant privilages命令

不幸的是，我收到以下错误，

如我错了请纠正我。

我应该使用其他配置连接到 Percona XtraDB 集群吗？

我试图弄清楚如何为我的服务器计算正确的 gcache，并遇到了以下帖子，讨论了如何做到这一点：

在帖子中，讨论了执行以下操作来获取计算所需的值：

我的问题是，在生产中运行 select sleep(60) 是否会阻止 MySQL 上的所有读取（通过保持 mysqld 线程忙碌）？如何计算生产中的最佳 gcache 值？

有备份日志，但是昨天备份还好好的，怎么回事？

mysql是：5.6.28

xtrabackup 为：2.4.6

我正在寻找一个高可用的 SQL 解决方案！我读过的一篇文章是关于 Galera Cluster 中的“虚拟同步”：https ://www.percona.com/blog/2012/11/20/understanding-multi-node-writing-conflict-metrics-in-percona -xtradb-cluster-and-galera/

他说

当 writeset 实际应用于给定节点时，它检测到的与该节点上的打开（尚未提交）事务的任何锁定冲突都会导致该打开的事务回滚。

和

复制线程应用的写入集总是获胜

如果 WriteSet 与已提交的事务冲突会发生什么？

他还说：

然后在每个节点上（按顺序）“认证”写入集。

Galera Cluster 如何使 WriteSets 在集群上排序？是否有任何隐藏的主节点使 WriteSets 有序；像动物园管理员？或者是什么？

如果 3 节点 Percona 集群中的所有节点都已关闭（正常关闭或崩溃），从这篇博客中，它说当节点可以相互访问时，集群可以自动恢复。然而，在这种情况下启动节点似乎是一项艰巨的任务。

那么在这种情况下是否有可靠且可操作的方法来进行集群恢复呢？

我在当前正在处理的系统中有一个循环模式，例如，我需要在可能的公司列表下选择所有有订单的用户。或者如果存在该用户被标记的记录，则需要选择用户。

我的users表包含 430,825 条记录，所以这应该不难处理。现在我很接近了，我有一个查询得到我要查找的 0.047 秒的执行时间，但是如果我再添加一个，它会变得非常慢。

这是我当前的查询，最快的查询：

（额外select*from(...)是因为这个https://stackoverflow.com/a/1434712/728236）

在中间，我通过电子邮件地址进一步吸引用户，同时检查其他相关表中可能与该用户相关的电子邮件。就像，当报价发送给客户时，下一部分搜索用户，包括他们的抄送地址。

我添加了备用表来搜索电子邮件，但现在查询需要 3.016 秒，速度慢得多。奇怪的是，当我构建这个查询时，最后一部分似乎是这里性能的临界点，这是什么原因？

第一个和第二个分别解释

另外，我尝试过使用连接，例如连接invoices表等，但随后我遇到了每个用户行重复invoice或quoterequest连接接收的问题，并且在几分钟内对结果数据进行分组/区分和排序变得非常慢.

我也尝试了第一个查询的“存在”版本，正如文档https://dev.mysql.com/doc/refman/5.7/en/subquery-optimization-with-exists.html所建议的那样

但这让我达到了 5.516 秒，所以这绝对不是正确的方向。

以我尝试的方式选择数据的最有效方法是什么？或者我是否需要重组我的一些表以获得我正在寻找的性能？

我已经隔离了我认为我拥有的最小的子问题和瓶颈。这是我的打火机查询

和解释

此查询大约需要 1.5 秒来执行

嗯......所以它似乎正在工作，但我发现了一对似乎效率不高的表，即 myusers和invoices表。

我有这些索引：

和查询

仅这个查询就需要 0.3 秒，这对我来说感觉很慢，就像它没有充分利用索引一样，特别是因为users只有 430,997 行并且invoices只有 194,180 行，这看起来应该是一个非常简单的查询。

编辑：实际上比这更糟糕，如果给定的 CompanyID 仅包含 ~4 行，则此查询需要 3.5 秒