mysql (Perconadb) Соединение кластера Galera/Xtrabackup завершается неудачно с "Неверным аргументом"
У меня есть кластер MySQL Galera, использующий Perconadb и Xtrabackup. Узлы могут запускаться автономно или могут присоединяться к кластеру, если требуется только IST. Тем не менее, если требуется SST, это выполняется до завершения, а затем завершается ошибкой.
Журналы показывают, что после того, как SST xtrabackup завершен, он завершается со статистикой 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 работать.
4 ответа
Я обнаружил, что причины сбоя SST регулярно подпадают под одну из следующих: SElinux/AppArmor Enforcing, пользователь SST не был создан на донорском узле (и разрешения не обновлены правильно в файлах.cnf), ограничения IPTables/Firewall более 4444. В большинстве исправление тех случаев позволяет SST работать.
Попробуйте открыть innobackupex журнал, например, в 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 могут потерпеть неудачу, и некоторые из них были приведены другими авторами; однако в нашем случае проблема, похоже, заключалась в том, что SST-скрипт xtrabackup более требователен к mysql.cnf, чем сам MySQL, и завершается с этой ошибкой, когда у анализатора возникают проблемы.
В этом случае проблема заключалась в том, что некоторые директивы config были в файле более одного раза (хотя и с одним и тем же значением). MySQL с радостью проходит это, но анализатор xtrabackup превратил его в многозначный массив, который был недопустимым типом данных, поэтому он задохнулся.
Удаление дополнительных дублирующих строк конфигурации решило проблему.
Обратите внимание, что это влияет только на xtrabackup SST - IST всегда работал нормально, а сам MySQL (плюс mysqldump и т. Д.) Вполне доволен.
Поскольку у galera креативный взгляд на то, что представляет собой значимое сообщение об ошибке, не ожидайте, что EINVAL 22 будет соответствовать коду возврата системного вызова.
Взгляните на часть кода вокруг этого текста EINVAL в их коде.
исправление не является приоритетом.