Percona Xtradb Cluster не работает

Question

Я настроил кластер Percona Xtradb с 3 узлами. Первый узел нормально запускается с начальной загрузки, но когда я пытаюсь запустить второй узел для присоединения к кластеру, я получаю следующую ошибку:

2015-08-27 18:08:08 25990 [Предупреждение] WSREP: Не удалось подготовиться к добавочной передаче состояния: UUID локального состояния (00000000-0000-0000-0000-000000000000) не соответствует UUID состояния группы (a6b3fced-4ca1-11e5-b5da-d69fa186273c): 1 (операция не разрешена)
в galera/src/replicator_str.cpp:prepare_for_IST():463. IST будет недоступен.
2015-08-27 18:08:08 25990 [Примечание] WSREP: элемент 0.0 (db-gc-pxc2) запросил передачу состояния из 'any'. Выбрано 1.0 (db-gc-pxc1)(SYNCED) в качестве донора.
2015-08-27 18:08:08 25990 [Примечание] WSREP: Сдвиг ПЕРВИЧНОГО -> РЕЙТИНГ (ДО: 0)
2015-08-27 18:08:08 25990 [Примечание] WSREP: Запрос о передаче состояния: успех, донор: 1
2015-08-27 18:08:08 25990 [Предупреждение] WSREP: 1.0 (db-gc-pxc1): сбой при переносе состояния в 0.0 (db-gc-pxc2): -12 (невозможно выделить память)
2015-08-27 18:08:08 25990 [ОШИБКА] WSREP: gcs/src/gcs_group.cpp:int gcs_group_handle_join_msg(gcs_group_t*, const gcs_recv_msg_t*)():731: никогда не получит состояние. Нужно прервать.
2015-08-27 18:08:08 25990 [Примечание] WSREP: gcomm: завершающий поток
2015-08-27 18:08:08 25990 [Примечание] WSREP: gcomm: присоединение к ветке
2015-08-27 18:08:08 25990 [Примечание] WSREP: gcomm: закрытие серверной части

Ниже моя конфигурация кластера в файле my.cnf:

# Galera COnfig
wsrep_cluster_name = pxc
wsrep_cluster_address = gcomm://192.168.2.100,192.168.2.101,10.168.1.102
wsrep_node_address = 10.1.0.101
wsrep_provider = /usr/lib/libgalera_smm.so
wsrep_provider_options = "gcache.size=4G"
wsrep_slave_threads = 32
wsrep_sst_auth = "user:userpass"
wsrep_node_name = node2
#wsrep_sst_method = xtrabackup_throttle
wsrep_sst_method = xtrabackup-v2

Что будет причиной этой ошибки?

Кстати, у меня есть пользователь и пароль для wsrep_sst_auth, созданные в базе данных.

Вот остаток my.cnf, это помогает:

back_log = 65535
binlog_format = ROW
character_set_server = utf8
collation_server = utf8_general_ci
datadir = /var/lib/mysql
#default_storage_engine = InnoDB
expand_fast_index_creation = 1
expire_logs_days = 7
innodb_autoinc_lock_mode = 2
innodb_buffer_pool_instances = 6
innodb_buffer_pool_populate = 1
innodb_buffer_pool_size = 6G   # XXX 64GB RAM, 80%
#innodb_data_file_path = ibdata1:64M;ibdata2:64M:autoextend
innodb_file_format = Barracuda
innodb_file_per_table
innodb_flush_log_at_trx_commit = 2
innodb_flush_method = O_DIRECT
innodb_io_capacity = 1600
innodb_large_prefix
innodb_locks_unsafe_for_binlog = 1
#innodb_log_file_size = 64M
innodb_print_all_deadlocks = 1
innodb_read_io_threads = 64
innodb_stats_on_metadata = FALSE
innodb_support_xa = FALSE
innodb_write_io_threads = 64
log-bin = mysqld-bin
log-queries-not-using-indexes
log-slave-updates
long_query_time = 1
max_allowed_packet = 64M
max_connect_errors = 4294967295
max_connections = 4096
min_examined_row_limit = 1000
performance-schema-instrument='%=ON'
port = 3306
relay-log-recovery = TRUE
skip-name-resolve
slow_query_log = 1
slow_query_log_timestamp_always = 1
table_open_cache = 4096
thread_cache = 1024
tmpdir = /srv/tmp
transaction_isolation = REPEATABLE-READ
updatable_views_with_limit = 0
user = mysql
wait_timeout = 60

Answer 1

Это может показаться основной причиной:

2015-08-27 18:08:08 25990 [Warning] WSREP: 1.0 (db-gc-pxc1): State transfer to 0.0 (db-gc-pxc2) failed: -12 (Cannot allocate memory)

Новый узел пытается присоединиться к кластеру. Новый узел в настоящее время не имеет состояния (локальный UUID равен нулю), поэтому IST недоступен - это означает, что ему необходимо запустить полный SST из донорского узла.

Узел pxc2 является столяром, а pxc1 является выбранным донором; однако мы получаем ошибку от pxc1, что передача состояния не удалась, что приводит к сбою соединения.

Вы должны проверить журналы на донорском узле (pxc1) для более подробной информации; но журнал, который мы имеем, указывает на то, что у него недостаточно памяти для запуска экспорта базы данных. Не зная вашей аппаратной конфигурации, я не могу дать однозначный ответ, но, скорее всего, ваш my.cnf настроен так, что он слишком жаден для вашей доступной памяти, и поэтому процесс xtrabackup не может быть запущен, иначе база данных слишком велика. Добавьте больше памяти к узлу или уменьшите распределение в my.cnf.