MariaDB Galera Cluster Node cannot start after going down
My Environtment :
Two Nodes - CentOS 6.4 x86_64
Node1 : 10.10.201.3
Node2 : 10.10.201.4
MariaDB-server-10.2.0-1.el6.x86_64
Both nodes are running normally, but after restarting mysql on Node1, it'll be failed to start again whilst mysql on Node2 is continuing running without problem.
Configuration on Node1 :
#/etc/my.cnf.d/server.cnf
node1
bind-address=10.10.201.3
datadir=/opt/mysql
socket=/opt/mysql/mysql.sock
handlersocket_address="10.10.201.3"
handlersocket_port="9998"
handlersocket_port_wr="9999"
open_files_limit = 25600
log-error=/opt/mysql/log/mysqld.log
[galera]
# Mandatory settings
wsrep_on=ON
wsrep_provider=/usr/lib64/galera/libgalera_smm.so
wsrep_cluster_address="gcomm://10.10.201.4,10.10.201.3"
wsrep_cluster_name='galera_cluster_www'
wsrep_node_address='10.10.201.3'
wsrep_node_name='www-node1'
wsrep_sst_method=rsync
wsrep_sst_auth=sst_user:password
wsrep-slave-threads=16
binlog_format=ROW
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
wsrep_log_conflicts=ON
wsrep_provider_options="cert.log_conflicts=ON"
wsrep_debug=ON
wsrep_max_ws_size = 2G
binlog_row_image = minimal
Configuration on Node2 :
#/etc/my.cnf.d/server.cnf
node2
bind-address=10.10.201.4
datadir=/opt/mysql
socket=/opt/mysql/mysql.sock
handlersocket_address="10.10.201.4"
handlersocket_port="9998"
handlersocket_port_wr="9999"
open_files_limit = 25600
[galera]
# Mandatory settings
wsrep_on=ON
wsrep_provider=/usr/lib64/galera/libgalera_smm.so
wsrep_cluster_address="gcomm://10.10.201.3,10.10.201.4"
wsrep_cluster_name='galera_cluster_www'
wsrep_node_address='10.10.201.4'
wsrep_node_name='www-node2'
wsrep_sst_method=rsync
wsrep_sst_auth=sst_user:password
wsrep-slave-threads=16
binlog_format=ROW
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
wsrep_log_conflicts=ON
wsrep_provider_options="cert.log_conflicts=ON"
wsrep_debug=ON
wsrep_max_ws_size = 2G
binlog_row_image = minimal
And finally, Cluster Information on Node2 after failing mysql on the first node (Node1) :
MariaDB [(none)]> show status like 'wsrep%';
+------------------------------+--------------------------------------+
| Variable_name | Value |
+------------------------------+--------------------------------------+
| wsrep_apply_oooe | 0.017353 |
| wsrep_apply_oool | 0.000050 |
| wsrep_apply_window | 1.021550 |
| wsrep_causal_reads | 0 |
| wsrep_cert_deps_distance | 24.564685 |
| wsrep_cert_index_size | 48 |
| wsrep_cert_interval | 0.021750 |
| wsrep_cluster_conf_id | 69 |
| wsrep_cluster_size | 1 |
| wsrep_cluster_state_uuid | c07f825f-132f-11e6-b219-d7e841605104 |
| wsrep_cluster_status | Primary |
| wsrep_commit_oooe | 0.000000 |
| wsrep_commit_oool | 0.000034 |
| wsrep_commit_window | 1.005403 |
| wsrep_connected | ON |
| wsrep_evs_delayed | |
| wsrep_evs_evict_list | |
| wsrep_evs_repl_latency | 0/0/0/0/0 |
| wsrep_evs_state | OPERATIONAL |
| wsrep_flow_control_paused | 0.000000 |
| wsrep_flow_control_paused_ns | 0 |
| wsrep_flow_control_recv | 0 |
| wsrep_flow_control_sent | 0 |
| wsrep_gcomm_uuid | 401f6755-71da-11e6-8244-9e88079ed6c4 |
| wsrep_incoming_addresses | 10.10.201.4:3306 |
| wsrep_last_committed | 2364263 |
| wsrep_local_bf_aborts | 116 |
| wsrep_local_cached_downto | 2221069 |
| wsrep_local_cert_failures | 23 |
| wsrep_local_commits | 729390 |
| wsrep_local_index | 0 |
| wsrep_local_recv_queue | 0 |
| wsrep_local_recv_queue_avg | 0.004725 |
| wsrep_local_recv_queue_max | 6 |
| wsrep_local_recv_queue_min | 0 |
| wsrep_local_replays | 112 |
| wsrep_local_send_queue | 0 |
| wsrep_local_send_queue_avg | 0.000335 |
| wsrep_local_send_queue_max | 2 |
| wsrep_local_send_queue_min | 0 |
| wsrep_local_state | 4 |
| wsrep_local_state_comment | Synced |
| wsrep_local_state_uuid | c07f825f-132f-11e6-b219-d7e841605104 |
| wsrep_protocol_version | 7 |
| wsrep_provider_name | Galera |
| wsrep_provider_vendor | Codership Oy <info@codership.com> |
| wsrep_provider_version | 25.3.15(r3578) |
| wsrep_ready | ON |
| wsrep_received | 1376816 |
| wsrep_received_bytes | 630752657 |
| wsrep_repl_data_bytes | 303429595 |
| wsrep_repl_keys | 3039261 |
| wsrep_repl_keys_bytes | 41097380 |
| wsrep_repl_other_bytes | 0 |
| wsrep_replicated | 729452 |
| wsrep_replicated_bytes | 391211903 |
| wsrep_thread_count | 17 |
+------------------------------+--------------------------------------+
У меня была та же проблема, и, наконец, после ее устранения (на CentOS 7 - MariaDB-server-10.2.0-1 ]), Я написал документацию о том, как ее правильно настроить, и надеюсь, что она исправит и вашу. Следуйте приведенным ниже инструкциям и попробуйте построить свои узлы Galera с нуля. Обратите внимание, что я буду использовать только обязательную конфигурацию, вы можете добавить ее позже. Я думаю, вы пропустили пятый шаг или сделали его неправильно. В любом случае, я напишу все шаги, чтобы всем было проще следовать.
Проблема возникает, когда вы не используете команду galera_new_cluster на главном узле, и вы не используете соответствующий адрес для wsrep_cluster_address - gcomm . Поэтому, когда мастер выходит из строя, другие узлы не могут вернуться к партнеру. (даже мастер не может вернуться в кластер)
Рассмотрим 3 сервера с именами GLR {1,2,3} , и мы собираемся настроить Galera Cluster на каждом. - Я объясню, как избежать сбоя в двухузловом кластере на седьмом шаге.
ШАГ 1
Для установки:
Откройте /etc/yum.repos.d/mariadb.repo с помощью вашего любимого редактора и добавьте в него следующие строки:
[mariadb]
name = MariaDB
baseurl = http://yum.mariadb.org/10.0/centos6-amd64
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1
ШАГ 2
Если вы не знаете, как управлять / настраивать SELinux, установите его в разрешающий режим и проверьте файлы журнала после завершения установки, чтобы выполнить необходимые шаги для управления им. Вам также может потребоваться установить пакеты setroubleshoot-server и setools-console , чтобы лучше понимать журналы SELinux.
Но если у вас включен SELinux и вы не хотите его использовать. установите его в разрешающий режим, обратите внимание, что он может заблокировать mysqld от выполнения необходимых операций. Поэтому вы должны настроить его так, чтобы mysqld мог запускать внешние программы и открывать прослушивающие сокеты на непривилегированных портах, то есть то, что может делать непривилегированный пользователь.
Обучение управлению SELinux выходит за рамки этого ответа, но вы можете установить его в разрешающий режим только для запросов mysql , выполнив следующую команду:
semanage permissive -a mysql_t
ШАГ 3
После установки используя yum , добавьте следующие строки в конец /etc/my.cnf.d/server.cnf, как показано ниже на каждом сервере GLR соответственно:
[GLR1] ↴
$ vim /etc/my.cnf.d/server.cnf
[galera]
# Mandatory settings
wsrep_on=ON
wsrep_provider=/usr/lib64/galera/libgalera_smm.so
wsrep_cluster_address='gcomm://{GLR1 IP},{GLR2 IP},{GLR3 IP}'
wsrep_cluster_name='galera'
wsrep_node_address='{GLR1 IP}
wsrep_node_name='GLR1'
wsrep_sst_method=rsync
binlog_format=row
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
bind-address=0.0.0.0
[GLR2] ↴
$ vim /etc/my.cnf.d/server.cnf
[galera]
# Mandatory settings
wsrep_on=ON
wsrep_provider=/usr/lib64/galera/libgalera_smm.so
wsrep_cluster_address='gcomm://{GLR1 IP},{GLR2 IP},{GLR3 IP}'
wsrep_cluster_name='galera'
wsrep_node_address='{GLR2 IP}
wsrep_node_name='GLR2'
wsrep_sst_method=rsync
binlog_format=row
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
bind-address=0.0.0.0
[GLR3] ↴
$ vim /etc/my.cnf.d/server.cnf
[galera]
# Mandatory settings
wsrep_on=ON
wsrep_provider=/usr/lib64/galera/libgalera_smm.so
wsrep_cluster_address='gcomm://{GLR1 IP},{GLR2 IP},{GLR3 IP}'
wsrep_cluster_name='galera'
wsrep_node_address='{GLR3 IP}
wsrep_node_name='GLR3'
wsrep_sst_method=rsync
binlog_format=row
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
bind-address=0.0.0.0
ШАГ 4
Перезагрузите все серверы.
ШАГ 5
Используйте следующую команду только на GLR1, а затем перезапустите mariadb.сервис на GLR2 и GLR3:
$ galera_new_cluster
$ sevice mysql start
ШАГ 6
Как вы заметили в своем вопросе, вы можете проверить связь между серверами, используя следующую команду:
$ mysql -u root -p -e "SHOW STATUS LIKE 'wsrep%'"
Или просто проверьте размер кластера:
$ mysql -u root -p -e "SHOW GLOBAL STATUS LIKE 'wsrep_cluster_size';"
ШАГ 7
С другой стороны, после выполнения всех вышеперечисленных шагов вы можете использовать эту статью , предоставленную веб-сайтом galeracluster, о том, как избежать отказа одного узла, из-за которого другой перестает работать, если вы хотите использовать ДВА -NODE cluster.
Вам доступны два решения:
Вы можете загрузить уцелевший узел, чтобы сформировать новый первичный компонент, используя опцию поставщика pc.boostrap wsrep Provider. Для этого войдите в клиент базы данных и выполните следующую команду:
SET GLOBAL wsrep_provider_options = 'pc.bootstrap = YES';Это загружает уцелевший узел как новый первичный компонент. Когда другой узел возвращается в оперативный режим или восстанавливает сетевое соединение с этим узлом, он инициирует передачу состояния и догоняет этот узел.
Если вы хотите, чтобы узел продолжал работать, вы можете использовать ] pc.ignore_sb Параметр поставщика wsrep. Для этого войдите в клиент базы данных и выполните следующую команду:
SET GLOBAL wsrep_provider_options = 'pc.ignore_sb = TRUE';Узел возобновляет обработку обновлений, и он будет продолжать делать это даже в случае что он подозревает ситуацию с разделенным мозгом.
Примечание Предупреждение: включение pc.ignore_sb опасно в настройке с несколькими мастерами из-за вышеупомянутого риска для ситуаций с разделенным мозгом. Однако это действительно упрощает работу в кластерах главный-подчиненный (особенно в тех случаях, когда вы используете только два узла).
В дополнение к решениям, приведенным выше, вы можете полностью избежать ситуации, используя Galera Arbitrator. Galera Arbitrator действует как нечетный узел в расчетах кворума. Это означает, что если вы включите Galera Arbitrator на одном узле в двухузловом кластере, этот узел останется первичным компонентом, даже если другой узел откажет или потеряет сетевое соединение.