Ошибка при добавлении ноды в кластер

server №1:
Hostname: mtcr01
OS: CentOS 7
IP: 172.16.250.70
server 2:
Hostname: mtcr02
OS: CentOS 7
IP: 172.16.250.71
На сервере mtcr01 создан кластер test. Вывод статуса кластера:

"Counter"	"Value"
"cluster_name"	"test"
"cluster_test_state_uuid"	"1c91dbe1-9741-11ed-823b-e389993cb142"
"cluster_test_conf_id"	"1"
"cluster_test_status"	"primary"
"cluster_test_size"	"1"
"cluster_test_local_index"	"0"
"cluster_test_node_state"	"synced"
"cluster_test_nodes_set"	""
"cluster_test_nodes_view"	"172.16.250.70:9312,172.16.250.70:9360:replication"
"cluster_test_indexes_count"	"0"
"cluster_test_indexes"	""
"cluster_test_local_state_uuid"	"1c91dbe1-9741-11ed-823b-e389993cb142"
"cluster_test_protocol_version"	"9"
"cluster_test_last_applied"	"0"
"cluster_test_last_committed"	"0"
"cluster_test_replicated"	"0"
"cluster_test_replicated_bytes"	"0"
"cluster_test_repl_keys"	"0"
"cluster_test_repl_keys_bytes"	"0"
"cluster_test_repl_data_bytes"	"0"
"cluster_test_repl_other_bytes"	"0"
"cluster_test_received"	"2"
"cluster_test_received_bytes"	"185"
"cluster_test_local_commits"	"0"
"cluster_test_local_cert_failures"	"0"
"cluster_test_local_replays"	"0"
"cluster_test_local_send_queue"	"0"
"cluster_test_local_send_queue_max"	"1"
"cluster_test_local_send_queue_min"	"0"
"cluster_test_local_send_queue_avg"	"0.000000"
"cluster_test_local_recv_queue"	"0"
"cluster_test_local_recv_queue_max"	"1"
"cluster_test_local_recv_queue_min"	"0"
"cluster_test_local_recv_queue_avg"	"0.000000"
"cluster_test_local_cached_downto"	"0"
"cluster_test_flow_control_paused_ns"	"0"
"cluster_test_flow_control_paused"	"0.000000"
"cluster_test_flow_control_sent"	"0"
"cluster_test_flow_control_recv"	"0"
"cluster_test_flow_control_interval"	"[ 100, 100 ]"
"cluster_test_flow_control_interval_low"	"100"
"cluster_test_flow_control_interval_high"	"100"
"cluster_test_flow_control_status"	"OFF"
"cluster_test_cert_deps_distance"	"0.000000"
"cluster_test_apply_oooe"	"0.000000"
"cluster_test_apply_oool"	"0.000000"
"cluster_test_apply_window"	"0.000000"
"cluster_test_commit_oooe"	"0.000000"
"cluster_test_commit_oool"	"0.000000"
"cluster_test_commit_window"	"0.000000"
"cluster_test_local_state"	"4"
"cluster_test_local_state_comment"	"Synced"
"cluster_test_cert_index_size"	"0"
"cluster_test_cert_bucket_count"	"2"
"cluster_test_gcache_pool_size"	"1320"
"cluster_test_causal_reads"	"0"
"cluster_test_cert_interval"	"0.000000"
"cluster_test_open_transactions"	"0"
"cluster_test_open_connections"	"0"
"cluster_test_ist_receive_status"	""
"cluster_test_ist_receive_seqno_start"	"0"
"cluster_test_ist_receive_seqno_current"	"0"
"cluster_test_ist_receive_seqno_end"	"0"
"cluster_test_incoming_addresses"	"172.16.250.70:9312,172.16.250.70:9360:replication"
"cluster_test_cluster_weight"	"1"
"cluster_test_desync_count"	"0"
"cluster_test_evs_delayed"	""
"cluster_test_evs_evict_list"	""
"cluster_test_evs_repl_latency"	"3.09e-06/5.4404e-06/8.832e-06/2.2504e-06/5"
"cluster_test_evs_state"	"OPERATIONAL"
"cluster_test_gcomm_uuid"	"1c914ee3-9741-11ed-9149-0355c0433960"

При попытке добавления ноды mtcr02 в кластер возникает ошибка:

JOIN CLUSTER test AT '172.16.250.70:9312';
/* Ошибка SQL (1064): cluster 'test', no nodes available(172.16.250.70:9312), error: '172.16.250.70:9312': remote error: unknown cluster 'test' */
/* Затронуто строк: 0  Найденные строки: 0  Предупреждения: 0  Длительность  0 из 1 запрос: 0,000 сек. */

Прошу подсказать в чем допущена ошибка. Процедуру создания кластера выполняю согласно интерактивному курсу.
Конфигурационный файл manticore с сервера mtcr01:

common
{
  lemmatizer_base = /usr/share/manticore
}
indexer
{
  mem_limit = 16M
  lemmatizer_cache = 128M
}
searchd
{
  listen = 172.16.250.70:9312
  listen = 9306:mysql41
  listen = 172.16.250.70:9360:replication
  server_id = 1
  data_dir=/var/lib/manticore
  max_packet_size = 8M
  log = /var/log/manticore/searchd.log
  mysql_version_string = 5.0.0
  max_children = 0
  binlog_max_log_size = 2048M
  collation_server = utf8_general_ci
  thread_stack = 256K
  unlink_old = 1
  query_log = /var/log/manticore/query.log
  read_timeout = 5
  preopen_indexes = 1
  seamless_rotate = 1
  binlog_path = /var/lib/manticore
  workers = threads
  pid_file = /var/run/manticore/searchd.pid
}

Конфигурационный файл manticore с сервера mtcr01:

common
{
  lemmatizer_base = /usr/share/manticore
}
indexer
{
  mem_limit = 16M
  lemmatizer_cache = 128M
}
searchd
{
  listen = 172.16.250.71:9312
  listen = 9306:mysql41
  listen = 172.16.250.71:9360:replication
  server_id = 2
  data_dir=/var/lib/manticore
  max_packet_size = 8M
  log = /var/log/manticore/searchd.log
  mysql_version_string = 5.0.0
  max_children = 0
  binlog_max_log_size = 2048M
  collation_server = utf8_general_ci
  thread_stack = 256K
  unlink_old = 1
  query_log = /var/log/manticore/query.log
  read_timeout = 5
  preopen_indexes = 1
  seamless_rotate = 1
  binlog_path = /var/lib/manticore
  workers = threads
  pid_file = /var/run/manticore/searchd.pid
}

С доступностью портов проблем нет.

Попробуйте указать диапазон портов, а не один. Как в курсе.

Ошибка та же.

Запустите searchd с --logreplication, сделайте create cluster заново и покажите:

  • новые конфиги
  • логи searchd с обоих серверов

3 года назад я задавал вопрос по поводу диапазона ip адресов репликации: Настройка Manticore Galera Cluster - #5 by FunkForever
Как я понял, в случае создания одного кластера диапазон не нужен.

Добавление произошло успешно. Сейчас попробую повторить процедуру без --logreplication.

Отработало успешно, спасибо

Подскажите, пожалуйста, по ещё одному вопросу: при добавлении rt индекса в кластер пропали все данные (физически файлы есть, а в manticore не отображаются). Изначально это была отдельная нода не в кластере. Как правильно нужно импортировать данные?

После разбора кластера ситуация не изменилась: данные в manticore не отображаются.

такого не должно быть - RT индекс должен нормально добавляться в кластер
и файлы RT индекса должны копироватся на все ноды кластера через SST

Однако это случилось) У меня есть РК, проделаю процедуру с нуля. И да: на остальных нодах индексы не реплицировались.

ну тогда это ошибка - нужно создать тикет в GitHub куда выложить воспроизводимый пример
или логи демона со всех нод кластера, которые были запущены с --logreplication для того чтобы расследовать этот кейс

При повторном выполнении проблема не воспроизвелась, ноды добавились в кластер. Однако возникла новая проблема при добавлении некоторых индексов в кластер. Имеются RT индексы, работающие в plain mode (структура индексов была описана в конфигурационном файле). Для перевода в rt mode было выполнено следующее:

  1. Скопированы скрипты создания индексов (CREATE TABLE)
  2. Убрано описание индексов из конфигурационного файла и добавлена переменная data_dir
  3. Созданы индексы из скриптов
  4. Данные индексов были скопированы в соответствующие директории индексов. После перезапуска мантикоры данные отобразились.

Но при добавлении некоторых индексов в кластер стали возникать ошибки:

/* Ошибка SQL (1064): failed to open /var/lib/manticore/pupils_new//etc/sphinx/stopwords.txt: No such file or directory */

При импорте таблиц изменился путь до stopwords. И ошибки стали выпадать в индексах, в которых был прописан путь до stopwords. Было предпринято несколько вариантов для исправления данной проблемы:

  1. ALTER TABLE pupils_new stopwords=‘/etc/sphinx/stopwords.txt’
    Не помогло, так как при выполнении команды предпринимается попытка сделать РК stopwords.txt. А так как путь неверный, то запрос заваливается.
  2. Выполнить реконфигурацию индексов до перевода в RT mode с удалением пути до stopwords.
    При выполнении данной процедуры скрипт индексов скорректировался и путь до stopwords убрался. Однако при переносе индексов в RT mode ошибка снова воспроизвелась. Оказалось, что путь до stopwords.txt остался в файлах *.meta и *.sph

Прошу помочь в решении данной проблемы.

нужно оставить plain index как есть - и на конфиге работающем с плейн индексом, выполнить

ATTACH INDEX diskindex TO RTINDEX rtindex WITH TRUNCATE;

Attach

после этого у вас RT индекс будет иметь настройки такие же как и у plain index и единственный диск чанк из этого plain index

после этого загружаете демон с конфигом RT mode и выполняете Importing index с путем к RT индексу

руками ничего не надо нигде делать

Спасибо за информацию, отпишу по результатам.

Данное решение не подойдёт, так как индексы уже RT (но работают в plain mode)


image

ну раз 1ый пункт есть и уже работает - то нужен только 2ой пункт - import index

но если это тот RT индекс который фейлит ALTER TABLE - то он сфейлит и прочие операции

Спасибо большое за информацию. Импорт таблиц прошёл успешно, все индексы добавлены в кластер.

Хотелось бы уточнить ещё один момент: касательно distibuted index. Вопрос больше не о проблеме , а о понимании работы логики балансировки: требуется ли в балансировке описывать каждый блок индекса отдельно? В данный момент у меня такая настройка балансировки (в самом простом варианте):

index common {
    type = distributed
    agent = 172.16.250.70:9306|172.16.250.71:9306|172.16.250.72:9306
}

Агенты, описанные в конфигурации, собраны в кластер галера и каждая нода содержит одинаковый перечень индексов. В конфигурации мантикоры, которая развернута отдельно от кластера и выполняет роль балансировки, я создал отдельный индекс common и, как ни странно, доступ к индексам на нодах осуществляется без проблем.

не понятно, что значит

требуется ли в балансировке описывать каждый блок индекса отдельно?

дистрибутивный индекс и кластер \ репликация никак сейчас не связаны