错误 1777 (HY000)：分区 memsqldb:0 没有主实例
ERROR 1777 (HY000): Partition memsqldb:0 has no master instance
我正在使用 memsql 的社区版。我今天 运行 查询时收到此错误。所以我刚刚重新启动了我的集群并解决了这个错误。
memsql-ops cluster-restart
但是发生了什么事，我以后应该怎么做才能避免这个错误？
注意
我不想购买企业版。
问题
这是可用性问题吗？
我在测试性能时遇到这个错误。
VM 有 24 个 CPU 和 25 个节点：1 个 Master Agg，24 个 Leaf 节点
将 VM 减少到 4 个 CPU 并重新启动集群。
所有的叶子都没有恢复。
除 4 人外，所有人都在 < 5 分钟内恢复。
20分钟后，4个叶节点仍未连接
来自 MySQL/MemSQL 提示：
use db;
show partitions;
我注意到一些分区的序数从 0-71 对我来说是空的，而不是为给定分区定义的主机、端口、角色。
在 memsql ops UI http://server:9000 > Settings > Config > Manual Cluster Control 我检查了 "ENABLE MANUAL CONTROL"，同时我尝试 运行 各种没有实际好处的命令。
然后15分钟后，我取消勾选，Memsql-ops再次尝试附加所有叶节点，终于成功了。
也许重新启动集群会做同样的事情。
发生这种情况是因为您的集群中的一个叶节点由于某种原因（网络连接丢失、硬件故障、OS 问题、机器过载、内存不足等）未能通过健康检查心跳及其分区不再可供查询。 MemSQL Community Edition 仅支持冗余 1，因此集群中发生故障的叶节点上没有其他数据副本（因此出现有关丢失数据分区的错误 - MemSQL 无法完成需要读取任何分区上数据的查询在问题叶上）。
鉴于重启修复了问题，最有可能的答案是 linux "out of memory" 杀了你：MemSQL Linux OOM killer docs
您还可以检查 运行 进入问题的叶子上的跟踪日志，看看是否有任何关于发生的事情的线索（通常在 /var/lib/memsql/leaf_3306/tracelogs/memsql.log）
-亚当
我也遇到过这个错误，那是因为一些slave ordinals没有对应的masters。我的错误消息如下所示：
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; 命令返回以下内容。
所以我采用的方法是删除每个这样的情况（角色是 Slave 或 NULL）。
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。
我遇到了同样的问题。在master节点使用如下命令，问题解决：
REBALANCE PARTITIONS ON db_name
您可以选择使用 FORCE:
强制执行
REBALANCE PARTITIONS ON db_name FORCE
要在执行再平衡时查看操作列表，请将上面的命令与 EXPLAIN:
一起使用
EXPLAIN REBALANCE PARTITIONS ON db_name [FORCE]
我正在使用 memsql 的社区版。我今天 运行 查询时收到此错误。所以我刚刚重新启动了我的集群并解决了这个错误。
memsql-ops cluster-restart
但是发生了什么事，我以后应该怎么做才能避免这个错误？
注意
我不想购买企业版。
问题
这是可用性问题吗？
我在测试性能时遇到这个错误。
VM 有 24 个 CPU 和 25 个节点：1 个 Master Agg，24 个 Leaf 节点 将 VM 减少到 4 个 CPU 并重新启动集群。
所有的叶子都没有恢复。 除 4 人外，所有人都在 < 5 分钟内恢复。 20分钟后，4个叶节点仍未连接
来自 MySQL/MemSQL 提示：
use db;
show partitions;
我注意到一些分区的序数从 0-71 对我来说是空的，而不是为给定分区定义的主机、端口、角色。
在 memsql ops UI http://server:9000 > Settings > Config > Manual Cluster Control 我检查了 "ENABLE MANUAL CONTROL"，同时我尝试 运行 各种没有实际好处的命令。
然后15分钟后，我取消勾选，Memsql-ops再次尝试附加所有叶节点，终于成功了。
也许重新启动集群会做同样的事情。
发生这种情况是因为您的集群中的一个叶节点由于某种原因（网络连接丢失、硬件故障、OS 问题、机器过载、内存不足等）未能通过健康检查心跳及其分区不再可供查询。 MemSQL Community Edition 仅支持冗余 1，因此集群中发生故障的叶节点上没有其他数据副本（因此出现有关丢失数据分区的错误 - MemSQL 无法完成需要读取任何分区上数据的查询在问题叶上）。
鉴于重启修复了问题，最有可能的答案是 linux "out of memory" 杀了你：MemSQL Linux OOM killer docs
您还可以检查 运行 进入问题的叶子上的跟踪日志，看看是否有任何关于发生的事情的线索（通常在 /var/lib/memsql/leaf_3306/tracelogs/memsql.log）
-亚当
我也遇到过这个错误，那是因为一些slave ordinals没有对应的masters。我的错误消息如下所示：
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; 命令返回以下内容。
所以我采用的方法是删除每个这样的情况（角色是 Slave 或 NULL）。
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。
我遇到了同样的问题。在master节点使用如下命令，问题解决：
REBALANCE PARTITIONS ON db_name
您可以选择使用 FORCE:
REBALANCE PARTITIONS ON db_name FORCE
要在执行再平衡时查看操作列表，请将上面的命令与 EXPLAIN:
EXPLAIN REBALANCE PARTITIONS ON db_name [FORCE]