Статьи

Диагностика ошибок SST с помощью кластера Percona XtraDB для MySQL

[Эта статья была написана Stephane Combaudon]
Передача моментального снимка состояния (SST)
 используется в кластере Percona XtraDB (PXC), когда новый узел присоединяется к кластеру, или для повторной синхронизации отказавшего узла, если добавочная передача состояния (IST) больше недоступна. SST запускается автоматически, но волшебства нет: если он не настроен должным образом, он не будет работать, и новые узлы никогда не смогут присоединиться к кластеру. Давайте посмотрим на несколько классических вопросов.

Порт для SST не открыт

Донор и соединитель обмениваются данными через порт 4444, и если порт закрыт с одной стороны, SST всегда будет выходить из строя.

В журнале ошибок донора вы увидите, что SST запущен:

[...]
141223 16:08:48 [Note] WSREP: Node 2 (node1) requested state transfer from '*any*'. Selected 0 (node3)(SYNCED) as donor.
141223 16:08:48 [Note] WSREP: Shifting SYNCED -> DONOR/DESYNCED (TO: 6)
141223 16:08:48 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification.
141223 16:08:48 [Note] WSREP: Running: 'wsrep_sst_xtrabackup-v2 --role 'donor' --address '192.168.234.101:4444/xtrabackup_sst' --auth 'sstuser:s3cret' --socket '/var/lib/mysql/mysql.sock' --datadir '/var/lib/mysql/' --defaults-file '/etc/my.cnf' --gtid '04c085a1-89ca-11e4-b1b6-6b692803109b:6''
[...]

Но тогда ничего не происходит, и через некоторое время вы увидите кучу ошибок:

[...]
2014/12/23 16:09:52 socat[2965] E connect(3, AF=2 192.168.234.101:4444, 16): Connection timed out
WSREP_SST: [ERROR] Error while getting data from donor node:  exit codes: 0 1 (20141223 16:09:52.057)
WSREP_SST: [ERROR] Cleanup after exit with status:32 (20141223 16:09:52.064)
WSREP_SST: [INFO] Cleaning up temporary directories (20141223 16:09:52.068)
141223 16:09:52 [ERROR] WSREP: Failed to read from: wsrep_sst_xtrabackup-v2 --role 'donor' --address '192.168.234.101:4444/xtrabackup_sst' --auth 'sstuser:s3cret' --socket '/var/lib/mysql/mysql.sock' --datadir '/var/lib/mysql/' --defaults-file '/etc/my.cnf' --gtid '04c085a1-89ca-11e4-b1b6-6b692803109b:6'
[...]

На стороне соединения вы увидите похожую последовательность: SST запускается, затем зависает и, наконец, прерывается:

[...]
141223 16:08:48 [Note] WSREP: Shifting PRIMARY -> JOINER (TO: 6)
141223 16:08:48 [Note] WSREP: Requesting state transfer: success, donor: 0
141223 16:08:49 [Note] WSREP: (f9560d0d, 'tcp://0.0.0.0:4567') turning message relay requesting off
141223 16:09:52 [Warning] WSREP: 0 (node3): State transfer to 2 (node1) failed: -32 (Broken pipe)
141223 16:09:52 [ERROR] WSREP: gcs/src/gcs_group.cpp:long int gcs_group_handle_join_msg(gcs_group_t*, const gcs_recv_msg_t*)():717: Will never receive state. Need to abort.

Решение состоит в том, чтобы убедиться, что порты открыты с обеих сторон.

SST неправильно настроен

Иногда на доноре вы увидите такую ​​ошибку:

141223 21:03:15 [Note] WSREP: Running: 'wsrep_sst_xtrabackup-v2 --role 'donor' --address '192.168.234.102:4444/xtrabackup_sst' --auth 'sstuser:s3cretzzz' --socket '/var/lib/mysql/mysql.sock' --datadir '/var/lib/mysql/' --defaults-file '/etc/my.cnf' --gtid 'e63f38f2-8ae6-11e4-a383-46557c71f368:0''
[...]
WSREP_SST: [ERROR] innobackupex finished with error: 1.  Check /var/lib/mysql//innobackup.backup.log (20141223 21:03:26.973)

И если вы посмотрите на  innobackup.backup.log:

41223 21:03:26  innobackupex: Connecting to MySQL server with DSN 'dbi:mysql:;mysql_read_default_file=/etc/my.cnf;mysql_read_default_group=xtrabackup;mysql_socket=/var/lib/mysql/mysql.sock' as 'sstuser'  (using password: YES).
innobackupex: got a fatal error with the following stacktrace: at /usr//bin/innobackupex line 2995
	main::mysql_connect('abort_on_error', 1) called at /usr//bin/innobackupex line 1530
innobackupex: Error: Failed to connect to MySQL server: DBI connect(';mysql_read_default_file=/etc/my.cnf;mysql_read_default_group=xtrabackup;mysql_socket=/var/lib/mysql/mysql.sock','sstuser',...) failed: Access denied for user 'sstuser'@'localhost' (using password: YES) at /usr//bin/innobackupex line 2979

Что произошло?

По умолчанию используется метод SST,  xtrabackup-v2 и для его работы необходимо указать имя пользователя / пароль в файле my.cnf:

[mysqld]
wsrep_sst_auth=sstuser:s3cret

И вам также нужно создать соответствующего пользователя MySQL:

mysql> GRANT RELOAD, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'sstuser'@'localhost' IDENTIFIED BY 's3cret';

Таким образом, вы должны проверить, что пользователь был правильно создан в MySQL и  wsrep_sst_auth правильно установлен.

Версии Galera не совпадают

Вот еще один набор ошибок, которые вы можете увидеть в журнале ошибок донора:

141223 21:14:27 [Warning] WSREP: unserialize error invalid flags 2: 71 (Protocol error)
	 at gcomm/src/gcomm/datagram.hpp:unserialize():101
141223 21:14:30 [Warning] WSREP: unserialize error invalid flags 2: 71 (Protocol error)
	 at gcomm/src/gcomm/datagram.hpp:unserialize():101
141223 21:14:33 [Warning] WSREP: unserialize error invalid flags 2: 71 (Protocol error)
	 at gcomm/src/gcomm/datagram.hpp:unserialize():101

Здесь проблема в том, что вы пытаетесь подключить узел, используя Galera 2.x, и узел, на котором работает Galera 3.x. Это может произойти, если вы попытаетесь использовать узел PXC 5.5 и узел PXC 5.6.

Правильное решение, вероятно, заключается в том, чтобы понять, почему вы получили такие несовместимые версии, и убедиться, что все узлы используют одну и ту же   версию Percona XtraDB Cluster и версию Galera.

Но если вы знаете, что делаете, вы также можете указать узлу с помощью Galera 3.x, что он будет взаимодействовать с узлами Galera 2.x, указав в файле my.cnf:

[mysqld]
wsrep_provider_options="socket.checksum=1"

Вывод

У ошибок SST может быть несколько причин, и лучший способ диагностировать проблему — взглянуть на журнал ошибок донора и столяра. Galera в целом довольно многословен, поэтому вы можете следить за ходом SST на обоих узлах и видеть, где он выходит из строя. Тогда речь идет в основном о возможности интерпретировать сообщения об ошибках.