2

我正在使用 memsql 的社区版。我今天运行查询时收到此错误。所以我刚刚重新启动了我的集群并解决了这个错误。

memsql-ops cluster-restart

但是发生了什么，我将来应该怎么做才能避免这个错误？

笔记

我不想购买企业版。

问题

这是可用性问题吗？

4

4 回答 4

4

我在试验性能时遇到了这个错误。

VM 有 24 个 CPU 和 25 个节点：1 个 Master Agg，24 个 Leaf 节点 将 VM 减少到 4 个 CPU 并重新启动集群。

所有的叶子都没有恢复。除 4 人外，其他人都在 < 5 分钟内恢复。20 分钟后，4 个叶子节点仍然没有连接。

从 MySQL/MemSQL 提示符：

use db;
show partitions;

我注意到一些序号为 0-71 的分区对我来说具有 null 而不是为给定分区定义的主机、端口、角色。

在 memsql ops UI http://server:9000 > Settings > Config > Manual Cluster Control 中，我检查了“ENABLE MANUAL CONTROL”，而我尝试运行各种命令却没有真正的好处。

然后 15 分钟后，我取消选中该框，Memsql-ops 再次尝试附加所有叶节点，终于成功了。

也许集群重启会做同样的事情。

于 2015-09-30T23:56:11.547 回答
2

发生这种情况是因为集群中的某个叶节点由于某种原因（网络连接丢失、硬件故障、操作系统问题、机器过载、内存不足等）未能通过健康检查心跳，并且其分区不再可供查询访问。MemSQL 社区版仅支持冗余 1，因此集群中故障叶节点上没有其他数据副本（因此有关丢失数据分区的错误 - MemSQL 无法完成需要读取任何分区上的数据的查询在问题叶子上）。

鉴于重新启动修复了问题，最可能的答案是 linux“内存不足”杀死了你：MemSQL Linux OOM 杀手文档

您还可以检查遇到问题的叶子上的跟踪日志，看看是否有任何关于发生了什么的线索（通常位于 /var/lib/memsql/leaf_3306/tracelogs/memsql.log）

-亚当

于 2015-10-06T04:00:04.813 回答
2

我也遇到过这个错误，那是因为一些从属序号没有相应的主人。我的错误信息如下所示：

ERROR 1772 (HY000) at line 1: Leaf Error (10.0.0.112:3306): Partition database `<db_name>_0` can't be promoted to master because it is provisioning replication

我的memsql> SHOW PARTITIONS;命令返回以下内容。

在此处输入图像描述

所以我采用的方法是删除每一个这样的情况（角色是从属或空）。

DROP PARTITION <db_name>:4 ON "10.0.0.193":3306;
..
DROP PARTITION <db_name>:46 ON "10.0.0.193":3306;

然后用每个删除的分区创建一个新分区。

CREATE PARTITION <db_name>:4 ON "10.0.0.193":3306;
..
CREATE PARTITION <db_name>:46 ON "10.0.0.193":3306;

这是在memsql> SHOW PARTITIONS;那之后的结果。

在此处输入图像描述

如果上述步骤似乎无法解决您的问题，您可以参考有关分区的 MemSQL 文档。

于 2019-02-12T12:09:35.673 回答
0

我遇到了同样的问题。在主节点中使用以下命令，解决了问题：

REBALANCE PARTITIONS ON db_name

或者，您可以使用以下命令强制它FORCE：

REBALANCE PARTITIONS ON db_name FORCE

并且要在重新平衡将要执行时查看操作列表，请使用上面的命令EXPLAIN：

 EXPLAIN REBALANCE PARTITIONS ON db_name [FORCE]
于 2020-05-10T06:51:26.987 回答