Проблемы с настройкой кластера MariaDB Galera

Я пытаюсь запустить кластер mariadb, но у меня ничего не получается. Прямо сейчас я использую MariaDB Galera 5.5.36 на 64-битной машине Red Hat ES6. Я установил mariadb через этот репозиторий здесь:

[mariadb]
name = MariaDB
baseurl = http://yum.mariadb.org/5.5-galera/rhel6-amd64/
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1

В server.conf у меня есть следующее на сервере 1:

[mariadb]
log_error=/var/log/mariadb.log
query_cache_size=0
query_cache_type=0
binlog_format=ROW
default_storage_engine=innodb
innodb_autoinc_lock_mode=2
wsrep_provider=/usr/lib64/galera/libgalera_smm.so
wsrep_cluster_address=gcomm://192.168.211.133
wsrep_cluster_name='cluster'
wsrep_node_address='192.168.211.132'
wsrep_node_name='cluster1'
wsrep_sst_method=rsync

а на 2 сервере у меня

[mariadb]
log_error=/var/log/mariadb.log
query_cache_size=0
query_cache_type=0
binlog_format=ROW
default_storage_engine=innodb
innodb_autoinc_lock_mode=2
wsrep_provider=/usr/lib64/galera/libgalera_smm.so
wsrep_cluster_address=gcomm://192.168.211.132
wsrep_cluster_name='cluster'
wsrep_node_address='192.168.211.133'
wsrep_node_name='cluster2'
wsrep_sst_method=rsync

Когда я запускаю сервер 1 с помощью следующей команды: sudo service mysql start --wsrep-new-cluster, он запускается просто отлично, если я открываю mysql и проверяю статус wsrep, он говорит, что все запущено и работает, что хорошо, но когда Я пытаюсь запустить службу sudo mysql на втором сервере, в журналах ошибок получаю следующее:

140609 14:47:55 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
140609 14:47:56 mysqld_safe WSREP: Running position recovery with --log_error='/var/lib/mysql/wsrep_recovery.i5qfm2' --pid-file='/var/lib/mysql/localhost.localdomain-recover.pid'
140609 14:47:57 mysqld_safe WSREP: Recovered position 85448d73-ebe8-11e3-9c20-fbc1995fee11:0
140609 14:47:57 [Note] WSREP: wsrep_start_position var submitted: '85448d73-ebe8-11e3-9c20-fbc1995fee11:0'
140609 14:47:57 [Note] WSREP: Read nil XID from storage engines, skipping position init
140609 14:47:57 [Note] WSREP: wsrep_load(): loading provider library '/usr/lib64/galera/libgalera_smm.so'
140609 14:47:57 [Note] WSREP: wsrep_load(): Galera 25.3.2(r170) by Codership Oy <[email protected]> loaded successfully.
140609 14:47:57 [Note] WSREP: CRC-32C: using hardware acceleration.
140609 14:47:57 [Note] WSREP: Found saved state: 85448d73-ebe8-11e3-9c20-fbc1995fee11:-1
140609 14:47:57 [Note] WSREP: Passing config to GCS: base_host = 192.168.211.133; base_port = 4567; cert.log_conflicts = no; gcache.dir = /var/lib/mysql/; gcache.keep_pages_size = 0; gcache.mem_size = 0; gcache.name = /var/lib/mysql//galera.cache; gcache.page_size = 128M; gcache.size = 128M; gcs.fc_debug = 0; gcs.fc_factor = 1; gcs.fc_limit = 16; gcs.fc_master_slave = NO; gcs.max_packet_size = 64500; gcs.max_throttle = 0.25; gcs.recv_q_hard_limit = 9223372036854775807; gcs.recv_q_soft_limit = 0.25; gcs.sync_donor = NO; repl.causal_read_timeout = PT30S; repl.commit_order = 3; repl.key_format = FLAT8; repl.proto_max = 5
140609 14:47:57 [Note] WSREP: Assign initial position for certification: 0, protocol version: -1
140609 14:47:57 [Note] WSREP: wsrep_sst_grab()
140609 14:47:57 [Note] WSREP: Start replication
140609 14:47:57 [Note] WSREP: Setting initial position to 85448d73-ebe8-11e3-9c20-fbc1995fee11:0
140609 14:47:57 [Note] WSREP: protonet asio version 0
140609 14:47:57 [Note] WSREP: Using CRC-32C (optimized) for message checksums.
140609 14:47:57 [Note] WSREP: backend: asio
140609 14:47:57 [Note] WSREP: GMCast version 0
140609 14:47:57 [Note] WSREP: (0c085f34-efe5-11e3-9f6b-8bfd1706e2a4, 'tcp://0.0.0.0:4567') listening at tcp://0.0.0.0:4567
140609 14:47:57 [Note] WSREP: (0c085f34-efe5-11e3-9f6b-8bfd1706e2a4, 'tcp://0.0.0.0:4567') multicast: , ttl: 1
140609 14:47:57 [Note] WSREP: EVS version 0
140609 14:47:57 [Note] WSREP: PC version 0
140609 14:47:57 [Note] WSREP: gcomm: connecting to group 'cluster', peer '192.168.211.132:,192.168.211.134:'
140609 14:48:00 [Warning] WSREP: no nodes coming from prim view, prim not possible
140609 14:48:00 [Note] WSREP: view(view_id(NON_PRIM,0c085f34-efe5-11e3-9f6b-8bfd1706e2a4,1) memb {
        0c085f34-efe5-11e3-9f6b-8bfd1706e2a4,0
} joined {
} left {
} partitioned {
})
140609 14:48:01 [Warning] WSREP: last inactive check more than PT1.5S ago (PT3.50775S), skipping check
140609 14:48:31 [Note] WSREP: view((empty))
140609 14:48:31 [ERROR] WSREP: failed to open gcomm backend connection: 110: failed to reach primary view: 110 (Connection timed out)
         at gcomm/src/pc.cpp:connect():141
140609 14:48:31 [ERROR] WSREP: gcs/src/gcs_core.c:gcs_core_open():196: Failed to open backend connection: -110 (Connection timed out)
140609 14:48:31 [ERROR] WSREP: gcs/src/gcs.c:gcs_open():1291: Failed to open channel 'cluster' at 'gcomm://192.168.211.132,192.168.211.134': -110 (Connection timed out)
140609 14:48:31 [ERROR] WSREP: gcs connect failed: Connection timed out
140609 14:48:31 [ERROR] WSREP: wsrep::connect() failed: 7
140609 14:48:31 [ERROR] Aborting

140609 14:48:31 [Note] WSREP: Service disconnected.
140609 14:48:32 [Note] WSREP: Some threads may fail to exit.
140609 14:48:32 [Note] /usr/sbin/mysqld: Shutdown complete

140609 14:48:32 mysqld_safe mysqld from pid file /var/lib/mysql/localhost.localdomain.pid ended

Я не понимаю, почему второй сервер не может обнаружить, что кластер запущен и работает. Эти машины могут нормально общаться друг с другом, я могу использовать SSH от одной к другой, и они могут пинговать друг друга. Я попытался удалить кеш galera, попытался понизить свою версию mariadb galera, попытался отключить SELinux, попытался запустить службу mysql от имени другого пользователя, убедился, что правильные порты открыты, попытался запустить их на 2 виртуальных машинах на разных компьютерах с разными IP-адресами. и т. д. Кто-нибудь знает, что здесь происходит, потому что я искал 3 дня, пытаясь исправить это, но, похоже, ни одно решение не работает со мной.


person user3723495    schedule 09.06.2014    source источник


Ответы (3)


Вот как я исправил свою аналогичную проблему.

CentOS 7 с MariaDB Galera 10.1.

Node2 Я видел это:

016-12-27 15:40:38 140703512762624 [Warning] WSREP: no nodes coming from prim view, prim not possible

Почитав немного, я попытался запустить это на node1.

service mysql start --wsrep-new-cluster

Но это не удалось, и в журналах я нашел это...

2016-12-27 15:44:08 140438853814528 [ERROR] WSREP: It may not be safe to bootstrap the cluster from this node. It was not the last one to leave the cluster and may not contain all the updates. To force cluster bootstrap with this node, edit the grastate.dat file manually and set safe_to_bootstrap to 1 .

Поэтому я отредактировал файл /var/lib/mysql/grastate.dat, изменив safe_to_bootstrap на 1.

Затем я смог запустить основной узел, используя:

service mysql start --wsrep-new-cluster

Затем на других я просто использовал

service mysql start

Примечание. Это было в демонстрационной предварительной среде. Я быстро сломал его после того, как все заработало, перезагрузив все серверы одновременно: P, но я знал, что записей не было и что БД были синхронизированы. Если вы находитесь в рабочей среде, и это происходит, вы можете использовать следующее, чтобы выяснить, на каком узле запустить «новый кластер», что сродни высказыванию «сделай меня основным».

mysqld_safe --wsrep-recover

Если это производственная проблема, я настоятельно рекомендую прочитать эту статью и сделать резервную копию с помощью CloneZilla, прежде чем запускать команды для сломанных клиентов!

https://www.percona.com/blog/2014/09/01/galera-replication-how-to-recover-a-pxc-cluster/

person FreeSoftwareServers    schedule 27.12.2016

Кластер должен запускаться с помощью этой команды на основном узле:

galera_new_cluster

после запуска первого узла вы можете успешно запустить другие узлы в кластере.

person Ghasem Pahlavan    schedule 04.06.2017

Я считаю, что вам нужно перечислить все IP-адреса в параметре wsrep_cluster_address.

wsrep_cluster_address=gcomm://192.168.211.132,192.168.211.133

Это должно быть сделано на обоих хостах. Кстати, вы, вероятно, захотите три узла, а не два, чтобы избежать сценариев разделения мозга.

person mohr_michael_a    schedule 17.09.2014