используется в кластере 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 на обоих узлах и видеть, где он выходит из строя. Тогда речь идет в основном о возможности интерпретировать сообщения об ошибках.