Я использую версию сообщества memsql. Я получил эту ошибку, когда выполнял запрос сегодня. Поэтому я просто перезапустил свой кластер и решил эту ошибку.
memsql-ops cluster-restart
Но что случилось и что мне делать в будущем, чтобы избежать этой ошибки?
ПРИМЕЧАНИЕ
Я не хочу покупать версию Enterprise.
Вопрос
Это проблема доступности?
Это произошло из-за того, что лист в вашем кластере по какой-то причине не прошел проверку работоспособности (потеря сетевого подключения, аппаратный сбой, проблема с ОС, перегрузка компьютера, нехватка памяти и т. д.), и его разделы больше не доступны для запросов. MemSQL Community Edition поддерживает только избыточность 1, поэтому на отказавшем конечном узле в вашем кластере нет других копий данных (поэтому возникает ошибка об отсутствии раздела данных — MemSQL не может выполнить запрос, требующий чтения данных из любых разделов). на проблемном листе).
Учитывая, что перезагрузка все исправила, наиболее вероятным ответом будет то, что linux «недостаточно памяти» убил вас: MemSQL Linux OOM killer docs
Вы также можете проверить журнал трассировки на листе, который столкнулся с проблемами, чтобы увидеть, есть ли там какая-либо подсказка о том, что произошло (обычно он находится в /var/lib/memsql/leaf_3306/tracelogs/memsql.log)
-Адам
Я получил эту ошибку, когда экспериментировал с производительностью.
В ВМ было 24 процессора и 25 узлов: 1 главный Agg, 24 листовых узла. Виртуальная машина была уменьшена до 4 процессоров и перезапущен кластер.
Все листья не восстановились. Все, кроме 4, выздоровели за ‹ 5 минут. Через 20 минут 4 листовых узла все еще не были подключены.
Из подсказки MySQL/MemSQL:
use db;
show partitions;
Я заметил, что некоторые разделы с порядковым номером от 0 до 71 для меня имеют значение null вместо Host, Port, Role, определенных для данного раздела.
В пользовательском интерфейсе memsql ops http://server:9000 > Настройки > Конфигурация > Ручное управление кластером я проверил "ВКЛЮЧИТЬ РУЧНОЕ УПРАВЛЕНИЕ" во время Я пытался запускать различные команды без реальной пользы.
Затем, через 15 минут, я снял флажок, Memsql-ops снова попытался подключить все конечные узлы и, наконец, успешно.
Возможно, перезапуск кластера сделал бы то же самое.
Я тоже столкнулся с этой ошибкой, потому что у некоторых ординалов-рабов не было соответствующих хозяев. Мое сообщение об ошибке выглядело так:
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, касающейся разделов, здесь, если вышеуказанные шаги похоже, не решает вашу проблему.
Я столкнулся с той же проблемой. Используя следующую команду в главном узле, проблема решена:
REBALANCE PARTITIONS ON db_name
При желании вы можете принудительно использовать FORCE:
REBALANCE PARTITIONS ON db_name FORCE
И чтобы увидеть список операций, когда будет выполняться ребалансировка, используйте приведенную выше команду с EXPLAIN:
EXPLAIN REBALANCE PARTITIONS ON db_name [FORCE]
