Листовой узел memsql-deploy постоянно терпит неудачу

На том же хосте, что и главный узел для memsql-deploy конечного узла, всегда произошел сбой с одной и той же ошибкой. Переключение операции на новые машины имеет тот же сбой.

Вот шаги для развертывания главной роли:

# memsql-ops memsql-deploy -a Af53bfb  -r master -P 3306 --community-edition
2017-03-24 16:15:54: Je5725b [INFO] Deploying MemSQL to 172.17.0.3:3306
2017-03-24 16:15:59: Je5725b [INFO] Installing MemSQL
2017-03-24 16:16:02: Je5725b [INFO] Finishing MemSQL Install
Waiting for MemSQL to start...
MemSQL successfully started

Вот немедленные шаги по добавлению листового узла после развертывания мастера:

# memsql-ops memsql-deploy -a Af53bfb  -r leaf -P 3308       
2017-03-24 16:16:43: J32c71f [INFO] Deploying MemSQL to 172.17.0.3:3308
2017-03-24 16:16:43: J32c71f [INFO] Installing MemSQL
2017-03-24 16:16:46: J32c71f [INFO] Finishing MemSQL Install
Waiting for MemSQL to start...
MemSQL failed to start: Failed to start MemSQL:

        set_mempolicy: Operation not permitted
setting membind: Operation not permitted

Каковы возможные причины сообщений об ошибках и каким образом я могу найти основную причину или исправить?


person robert    schedule 24.03.2017    source источник
comment
Далее углубитесь в job-logs и найдите соответствующее сообщение об ошибке, произошедшее во время запуска конечного узла: J2f44c7 [WARNING] Could not read tracelog for MemSQL node 636F0213D6DA91A67D67DD3F4554E20B5CC3FAF1 because it doesn't exist   -  person robert    schedule 24.03.2017


Ответы (2)


После одного дня поиска в Google я, кажется, наконец нашел основную причину этой ошибки. Я чувствую себя странно, почему никто не спрашивал раньше, потому что это должно происходить чаще, чем только я.

Настоящая причина этой проблемы заключается в том, что я установил пакет numactl в соответствии с рекомендациями MemSQL на компьютере, отличном от NUMA. Это позволит узлу memsql, отличному от первого, попытаться выполнить подкоманду numactl set_mempolicy для связывания отдельных узлов MemSQL с ЦП, но эта команда в конечном итоге завершится ошибкой. А запуск ноды подкомандами memsql-start или memsql-deploy из memsql-ops вообще не получится.

Обойти это очень просто, просто удалите пакет numactl. Тогда все будет хорошо. Этот обходной путь особенно применим к некоторым развертываниям memsql на основе виртуализации, таким как Docker.

person robert    schedule 25.03.2017

Можно попробовать на мастере:

memsql-ops start
memsql-ops memsql-deploy --role master -P 3306 --community-edition

На агенте:

memsql-ops start
memsql-ops follow -h <host of primary agent> -P <port of primary agent if configured to use one>
memsql-ops memsql-deploy --role leaf -P 3308 --community-edition  
person Clicquot The Dog    schedule 24.03.2017
comment
И master, и leaf находятся на одном хосте. Нужно ли мне запускать follow до memsql-deploy? - person robert; 24.03.2017
comment
@роберт, я так думаю - person Clicquot The Dog; 24.03.2017
comment
хотя я сомневался, но я попробовал. Оказалось, что агент не может следовать за собой, когда я делаю это на поле агента primary, которое также является master memsql. Я считаю, что у нас может быть только один агент memsql на хост, но у нас может быть один или несколько узлов на хост memsql. У моей проблемы должны быть другие причины. Спасибо. - person robert; 25.03.2017