【发布时间】：2015-09-17 10:58:13
【问题描述】：
我正在使用 memsql 的社区版。我今天运行查询时收到此错误。所以我只是重新启动了我的集群并解决了这个错误。
memsql-ops cluster-restart
但是发生了什么，我以后应该怎么做才能避免这个错误？
注意
我不想购买企业版。
问题
这是可用性问题吗？
【问题讨论】：
标签： singlestore
【发布时间】：2015-09-17 10:58:13
【问题描述】：
我在测试性能时遇到了这个错误。
VM 有 24 个 CPU 和 25 个节点：1 个 Master Agg，24 个 Leaf 节点 将 VM 减少到 4 个 CPU 并重新启动集群。
所有的叶子都没有恢复。 除 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再次尝试附加所有叶子节点，终于成功了。
也许重启集群也会做同样的事情。
【讨论】：
-
是的，你是对的，我能感觉到，因为当我们重新启动集群时，所有节点都会尝试恢复它们的数据，从而问题解决了
发生这种情况是因为集群中的某个叶节点由于某种原因（网络连接丢失、硬件故障、操作系统问题、机器过载、内存不足等）未能通过运行状况检查检测信号，并且它的分区不再可供访问询问。 MemSQL 社区版仅支持冗余 1，因此集群中故障叶节点上没有其他数据副本（因此有关丢失数据分区的错误 - MemSQL 无法完成需要读取任何分区上的数据的查询在问题叶子上）。
鉴于重启修复了问题，最有可能的答案是 linux“内存不足”杀死了你：MemSQL Linux OOM killer docs
您还可以检查遇到问题的叶子上的跟踪日志，看看那里是否有任何关于发生了什么的线索（通常位于 /var/lib/memsql/leaf_3306/tracelogs/memsql.log）
-亚当
【讨论】：
-
很高兴看到 memsql 核心人员回答问题 :)
我也遇到过这个错误，那是因为一些从属序号没有对应的主控。我的错误信息如下所示：
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 文档，here。
【讨论】：
我遇到了同样的问题。在主节点使用如下命令，问题解决：
REBALANCE PARTITIONS ON db_name
您可以选择使用FORCE 强制它：
REBALANCE PARTITIONS ON db_name FORCE
如果要在执行再平衡时查看操作列表，请使用上面的命令和EXPLAIN：
EXPLAIN REBALANCE PARTITIONS ON db_name [FORCE]
【讨论】：