У меня есть кластер MySQL Galera, использующий Perconadb и Xtrabackup. Узлы могут запускаться автономно или могут присоединяться к кластеру, если требуется только IST. Однако, если требуется SST, он выполняется до завершения, а затем завершается ошибкой.
Журналы показывают, что после завершения xtrabackup SST он завершается со статистикой 22 (недопустимый аргумент), вызывая откат SST, и узел не может подняться.
2018-08-09 00:43:25 860 [Note] WSREP: 0.0 (xmdadb01): State transfer to 1.0 (xmdadb02) complete.
2018-08-09 00:43:25 860 [Note] WSREP: Member 0.0 (xmdadb01) synced with group.
2018-08-09 00:43:25 860 [ERROR] WSREP: Process completed with error: wsrep_sst_xtrabackup-v2 --role 'joiner' --address '10.93.40.122' --datadir '/var/lib/mysql/' --defaults-file '/etc/my.cnf' --defaults-group-suffix '' --parent '860' '' : 22 (Invalid argument)
2018-08-09 00:43:25 860 [ERROR] WSREP: Failed to read uuid:seqno from joiner script.
2018-08-09 00:43:25 860 [ERROR] WSREP: SST script aborted with error 22 (Invalid argument)
2018-08-09 00:43:25 860 [ERROR] WSREP: SST failed: 22 (Invalid argument)
2018-08-09 00:43:25 860 [ERROR] Aborting
Соответствующие части my.cnf:
[mysqld]
wsrep_provider=/usr/lib64/galera3/libgalera_smm.so
wsrep_provider_options="gcache.size=256M;gcs.fc_factor=1.0;gcs.fc_limit=512;gcs.fc_master_slave=YES;pc.checksum=true;"
wsrep_cluster_name="galera01-xmd"
wsrep_cluster_address="gcomm://10.93.40.121:4567,10.93.40.122:4567"
wsrep_node_name=xmdadb02
wsrep_node_address="10.93.40.122"
wsrep_sst_method=xtrabackup-v2
wsrep_sst_auth=sst_user:password-goes-in-here
Во время работы SST я вижу, что файлы переходят в /var/lib/mysql/.sst, поэтому я знаю, что это работает. Я подтвердил, что имя пользователя и пароль верны. Однако почему xtrabackup-v2 возвращает 22 и как я могу остановить это, чтобы SST завершилась?
К сожалению, когда эта установка была впервые установлена, SST работала без проблем. Я не знаю, что изменилось за прошедшее время, чтобы предотвратить SST, но при этом IST продолжает работать.
Попробуйте открыть innobackupex log, например, в Debian он находится по адресу /var/lib/mysql/innobackup.backup.log
Я обнаружил, что моя проблема с донором была InnoDB: Error number 24 means 'Too many open files'., так ulimit -n помог бы :-)
РЕДАКТИРОВАТЬ: обнаружил, что есть еще одна строка журнала: xtrabackup: open files limit requested 200000, set to 1024 На самом деле я использовал:
[xtrabackup]
open-files-limit = 200000
Но MySQL уменьшает его до 1024 (или 5000), так что другое дело настроить:
[mysqld]
open-files-limit = 100000
(и удалите один в [xtrabackup] что бесполезно)
Есть много причин, по которым SST и IST могут выйти из строя, и некоторые из них были указаны в других плакатах; однако в нашем случае проблема, похоже, заключалась в том, что сценарий xtrabackup SST более требователен к mysql.cnf, чем сам MySQL, и выдает эту ошибку при возникновении проблем с анализатором.
В этом случае проблема заключалась в том, что некоторые директивы конфигурации присутствовали в файле более одного раза (хотя и с тем же значением). MySQL с радостью передает это, но синтаксический анализатор xtrabackup превратил его в многозначный массив, который был недопустимым типом данных, поэтому он подавился.
Удаление дополнительных повторяющихся строк конфигурации решило проблему.
Обратите внимание, что это затронуло только xtrabackup SST - IST всегда работал нормально, а сам MySQL (плюс mysqldump и т. Д.) Вполне доволен.
Я обнаружил, что причины, по которым SST регулярно выходит из строя, относятся к одной из следующих: SElinux / AppArmor принудительно, пользователь SST не был создан на донорском узле (и разрешения не обновлялись правильно в файлах .cnf), ограничения IPTables / Firewall более 4444. В большинстве случаев случаях, их исправление позволяет SST работать.