问题标签 [percona-xtradb-cluster]

我按照官方指南在我的 Ubuntu 16.04 机器上从源代码安装 PXC。该过程成功完成，我得到了一个Percona-XtraDB-Cluster-5.7.22-rel22-29.26.1.Linux.x86_64.tar.gz文件夹。

从这个文件中，我如何在机器上安装 PXC？

注意：我尝试了这种方法，因为安装sudo apt-get install percona-xtradb-cluster-57失败并出现以下错误：

以下软件包具有未满足的依赖关系： percona-xtradb-cluster-57 ：

取决于：percona-xtradb-cluster-server-5.7 (>= 5.7.22-29.26-1.xenial) 但不会安装

取决于：percona-xtradb-cluster-client-5.7 (>= 5.7.22-29.26-1.xenial) 但它不会被安装 E：无法纠正问题，您持有损坏的软件包。

我有一个主从复制。在这里，我为表 dltb 安排了 pt-archiver，该表在条件下insert_date<date_sub(now(),interval 35 days)归档到 master 上的归档表 dltb_archive。在 master 中，当我检查从属数据看起来不一致时，它工作正常。我仍然可以在主表中看到 35 天。任何人请让我知道这里有什么问题。

1. 我在 master 和 slave 中使用 MIXED binlog 格式。

2.pt-archiver --source h=localhost,u=root,p=*****,D=dltbdb,t=dltb --dest h=localhost,u=root,p=******,D=dltbdb,t=dltb_archive --where "insert_date < date_sub(now(),interval 35 day)" --bulk-insert --bulk-delete --limit=5000 --progress 50000

3. 这是我从慢日志中找到的 pt-archiver 的删除查询。

这里 dl_id 是 varchar(64) PRIMARY KEY

我们有一个应用程序，它由所有连接到同一个 Percona 数据库实例的微服务组成。目前它只是一个没有复制的 16 核/32 GB 内存的实例。我们的问题之一是，有时我们的一个微服务会导致数据库负载如此之高（甚至只是读取），这使得所有微服务都无法使用。

我们正在考虑创建一个由三个节点组成的 Percona 集群，并为每个微服务选择节点。大多数“写入”的服务将连接到一个实例，其余的将连接到其他两个实例。这样，如果某些微服务导致读取负载很高，它不应该完全压倒我们的基础设施。

我的问题：

1. 这甚至是个好主意吗？我们不应该让 ProxySQL 处理流量拆分吗？ProxySQL 可能意味着没有隔离。
2. 我们应该有更多的 CPU 更少的实例，还是更少的 CPU 更多的实例？拥有更多实例意味着在高负载情况下运行微服务的隔离度更高。
3. 拥有不同 CPU 的节点是个好主意吗？例如，让“写入实例”与“读取实例”相比具有更多 CPU。
4. 如果我们将微服务定向到“他们的 Percona 实例”，当他们的实例完全死亡时，我们还能拥有某种 HA 吗？

注意：我们可能会在 GCE 中使用 Percona XtraDB click-to-deploy：https ://console.cloud.google.com/marketplace/details/click-to-deploy-images/percona?project=goout-cloud&folder&organizationId=74390800864

我在 lxc 容器上运行 Percona 5.6 集群（3 个节点）。各节点硬件如下：

我的数据库大小不到 4GB。我设法调整了配置设置，以便快速处理选择。但是，我看到一些 UPDATE 和 INSERT 执行速度很慢（5 秒以上）。所以一定有某种瓶颈，我想知道我是否可以通过配置调整来解决。

我知道有几个表可能需要删除一些未使用的索引，但我想知道还有什么可以提高查询的性能。负载并没有那么大，大约有 100 个用户，因为它是一个内部系统。

这是我的 SHOW ENGINE INNODB 状态：

更新 1

以下是有关最常出现问题的表的一些详细信息：

我认为这张表的最大问题是 1）indecies 的数量和 2）使用的数据类型。'bigint(20) unsigned' 有很多用法，我不能想象这完全没有必要。以及“mediumtext”字段。

我怀疑插入速度很慢，因为更新速度很慢。我怀疑这与使用的索引数量和大数据类型有关。

但是，我有大量可用的 CPU/Ram 可以在需要时投入使用，并且想知道是否有任何我可能想要查看的进一步配置。

更新 2

自上次重新启动 mysql ( https://www.percona.com/blog/2012/06/30/find-unused-indexes/ ) 以来，我已经启用了 userstat 来确定一些未使用的索引。事实证明，我只使用了 34 个索引中的 15 个。

更新 3

这是线程备份期间的状态输出：

https://pastebin.com/QhkHGH5s

我们有一个具有三个节点的 Xtradb 集群。有一个节点未正确停止且无法启动。其他两个节点正常工作并响应。日志中唯一的内容是：

在/var/lib/mysql/wsrep_recovery.qEEkjd我们发现这个：

我们想完全放弃这些20 prepared transactions。

其他两个节点是一致的并且工作，所以告诉这个节点“忽略你的状态并与其他节点同步”就足够了。

我有一个大问题。我的电脑崩溃了，所以我丢失了访问 Perconna Xtradbcluster 数据库的 ROOT 密码。

我可以访问集群服务器上的 Centos ROOT 用户。（所以还不错）如何更改或重置密码而不使所有数据库崩溃？

信息：

好的，所以我正在使用这个 repo 的修改版本：https ://github.com/CaptTofu/mysql_replication_kubernetes/tree/master/galera_sync_replication

修改后的文件是：

服务：

pxc1，它是相同的复制控制器，用于发现的服务以及 2 和 3 的持久卷声明，只是更改了数字

事情是几天前它还在工作，并进行了大量测试，降低了 Pod、节点，并查看了复制投票和一切工作的方式，现在当我集成到应用程序时，它只是无法启动，我不能理解为什么如果它的配置相同，我在互联网、SO、GitHub 上看了很多，并尝试了建议的修复，但不起作用。

有什么建议么？现在已经有几个小时了，只是无法让它工作

我在发出 COMMIT 时看到“尝试获取锁定时发现死锁”，而 WAN Galera 集群中的另一个节点最近出现了连接问题（几乎与 COMMIT 同时出现）。在这种特殊情况下，我将数据插入到具有 auto_increment PK、没有 FK 和其他唯一约束的单个表中。根据日志记录，发出 COMMIT 的节点尚未识别出其他节点遇到任何问题（在抛出死锁异常后集群大小尚未更改）。我最初认为此错误与集群大小更改时 auto_increment_increment 和 auto_increment_offset 值的变化有关，从而导致 PK 冲突，所以我试图通过将 Galera 配置为根本不管理这些值并在集群中手动设置适当的值来简化问题，但这并没有解决问题。根据 Galera 文档，听起来提交节点验证事务不会导致集群中其他节点出现任何问题。根据我的 auto_increment_* 配置，我知道 auto_increment id 不应冲突，因此，我假设此时提交节点正在尝试检查所有节点的事务状态，包括最近的节点，以及非常暂时（< 1 分钟），离线，它拒绝交易，因为它无法从当前遇到问题的节点获得响应。根据 Galera 文档，听起来提交节点验证事务不会导致集群中其他节点出现任何问题。根据我的 auto_increment_* 配置，我知道 auto_increment id 不应冲突，因此，我假设此时提交节点正在尝试检查所有节点的事务状态，包括最近的节点，以及非常暂时（< 1 分钟），离线，它拒绝交易，因为它无法从当前遇到问题的节点获得响应。根据 Galera 文档，听起来提交节点验证事务不会导致集群中其他节点出现任何问题。根据我的 auto_increment_* 配置，我知道 auto_increment id 不应冲突，因此，我假设此时提交节点正在尝试检查所有节点的事务状态，包括最近的节点，以及非常暂时（< 1 分钟），离线，它拒绝交易，因为它无法从当前遇到问题的节点获得响应。

我对 Galera 相对较新（8 个月），我希望一位经验丰富的 Galera 资深人士可能对处理这种情况的最佳方式提出一些建议。我知道“重试交易”方法，但这让我觉得有点像黑客，我希望有一个替代解决方案，或者至少有一些关于这个特定问题的根本原因的额外信息.

谢谢

在安装了 percona 服务器这么多次没有问题之后，我似乎找到了一个独特的服务器。

如您所见，我只安装了 repo。当我去安装 PXC5.7 时，我得到了这个：

运行建议的命令不会产生任何结果。我试过安装 PXC56，它工作正常。然后，我将yum remove这些包裹再试一次，只是为了得到同样的东西。我还尝试安装它提到的与之冲突的特定软件包

它会安装好，yum remove 工作，尝试安装 PXC57，得到同样的冲突。我什至试过用rpm -e至尝试使用 yum-utils 删除它。我以前从来没有遇到过这个问题。

更新：

我已将其缩小为perl-DBD-MySQL问题包。

虽然还是不知道怎么解决

有没有人致力于收集与 Xtrabackup 流程相关的见解？我想分析各种 Xtrabackup 性能指标。我知道，为了监控 MySQL 服务本身，我们使用跨“performance_schema”和“sys”数据库的表中可用的信息。我们也可以使用'show status' MySQL 命令。

有什么方法可以以同样的方式收集 Xtrabackup 见解？