mysql (Perconadb) Соединение кластера Galera / Xtrabackup завершается неудачно с «Недействительным аргументом»
У меня есть кластер 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 по-прежнему работает.
Поскольку galera творчески подходит к тому, что составляет значимое сообщение об ошибке, не ожидайте, что EINVAL 22 будет соответствовать коду возврата системного вызова.
Взгляните на некоторые из кода вокруг этого текста EINVAL в их коде.
исправление не является приоритетом.
Я обнаружил, что причины регулярного сбоя SST относятся к одной из следующих: SElinux / AppArmor принудительно, пользователь SST не был создан на донорском узле (и разрешения не обновлялись правильно в файлах .cnf) , IPTables / Firewall ограничения более 4444. В большинстве случаев их исправление позволяет SST работать.
Существует множество причин, по которым SST и IST могут выйти из строя, и некоторые из них были указаны в других плакатах; однако в нашем случае проблема, похоже, заключалась в том, что сценарий xtrabackup SST более требователен к mysql.cnf, чем сам MySQL, и выдает эту ошибку при возникновении проблем с анализатором.
В этом случае проблема заключалась в том, что некоторые директивы конфигурации были в файле более одного раза (хотя и с тем же значением). MySQL с радостью передает это, но синтаксический анализатор xtrabackup превратил его в многозначный массив с недопустимым типом данных, поэтому проблема была решена.
Удаление дополнительных повторяющихся строк конфигурации решило проблему.
Обратите внимание, что это повлияло только на xtrabackup SST - IST всегда работал нормально, а сам MySQL (плюс mysqldump и т. д.) вполне довольны.
Попробуйте открыть журнал innobackupex , например, в Debian он находится по адресу /var/lib/mysql/innobackup.backup.log
. Я обнаружил, что моя проблема с донором была InnoDB: номер ошибки 24 означает «Слишком много открытых файлов». , поэтому ulimit -n поможет: -)
РЕДАКТИРОВАТЬ: обнаружено, что есть еще одна строка журнала: xtrabackup: запрошен лимит открытых файлов 200000, установлено 1024
Фактически, я использовал:
[xtrabackup]
open-files-limit = 200000
Но MySQL уменьшает его до 1024 (или 5000), так что другое дело настроить:
[mysqld]
open-files-limit = 100000
(и удалить его в [xtrabackup] что бесполезно)