Hier ist das Szenario: Ich musste eine Konfigurationsänderung an Mariadb in einem 3-Knoten-Cluster vornehmen. Ich habe die Konfigurationsdatei bearbeitet und den Knoten mit Folgendem heruntergefahren:
# service mysqld stop
Habe die Änderung an den anderen beiden Knoten vorgenommen und das Gleiche gemacht. Als ich den fortgeschrittensten Knoten mit
# galera_new_cluster
OK gestartet
Auf dem Netzknoten gestartet, Start ok. Der letzte Knoten ist der erste Knoten, an dem ich die Änderung vorgenommen habe.
Dieser Knoten startet nicht. Er erreicht eine Zeitüberschreitung beim Starten des Dienstes und stirbt einfach. Ich kann keine Fehler auf dem ausgefallenen Knoten oder auf dem primären Knoten finden. Ich habe die Zeitüberschreitung von der Standardeinstellung von 90 Sekunden auf 2 Stunden angepasst, was wiederum einfach eine Zeitüberschreitung bedeutete.
Ich suche lediglich nach Hinweisen darauf, was los sein könnte.
Jetzt ist die Galera-Konfiguration fehlgeschlagen:
[galera]
# Mandatory settings
binlog_format=ROW
default-storage-engine=innodb
innodb_autoinc_lock_mode=2
bind-address=192.168.10.238
wsrep_on=ON
wsrep_provider=/usr/lib64/galera/libgalera_smm.so
wsrep_cluster_address="gcomm://192.168.10.200,192.168.10.201"
## Galera Cluster Configuration
wsrep_cluster_name="Cluster1"
## Galera Synchronization Configuration
wsrep_sst_method=rsync
## Galera Node Configuration
wsrep_node_address="192.168.10.238"
wsrep_node_name="db3"
Meldung zur Zeitüberschreitung beim Start:
# service mysql start
Starting mysql (via systemctl): Job for mariadb.service failed because a timeout was exceeded. See "systemctl status mariadb.service" and "journalctl -xe" for details.
[FAILED]
Auf dem primären Knoten sehe ich, dass der letzte Knoten dem Cluster erfolgreich beitritt:
2018-03-13 9:08:36 140261636175616 [Note] WSREP: (050b87ee, 'tcp://0.0.0.0:4567') connection established to ce802915 tcp://192.168.10.238:4567
2018-03-13 9:08:36 140261636175616 [Note] WSREP: (050b87ee, 'tcp://0.0.0.0:4567') turning message relay requesting on, nonlive peers:
2018-03-13 9:08:36 140261636175616 [Note] WSREP: declaring 8ee7874f at tcp://192.168.10.201:4567 stable
2018-03-13 9:08:36 140261636175616 [Note] WSREP: declaring ce802915 at tcp://192.168.10.238:4567 stable
2018-03-13 9:08:36 140261636175616 [Note] WSREP: Node 050b87ee state prim
2018-03-13 9:08:36 140261636175616 [Note] WSREP: view(view_id(PRIM,050b87ee,87) memb {
050b87ee,0
8ee7874f,0
ce802915,0
} joined {
} left {
} partitioned {
})
2018-03-13 9:08:36 140261636175616 [Note] WSREP: save pc into disk
2018-03-13 9:08:36 140261627782912 [Note] WSREP: New COMPONENT: primary = yes, bootstrap = no, my_idx = 0, memb_num = 3
2018-03-13 9:08:36 140261627782912 [Note] WSREP: STATE_EXCHANGE: sent state UUID: a3fa8cd5-26bf-11e8-8f00-a686a9b10fbd
2018-03-13 9:08:36 140261627782912 [Note] WSREP: STATE EXCHANGE: sent state msg: a3fa8cd5-26bf-11e8-8f00-a686a9b10fbd
2018-03-13 9:08:36 140261627782912 [Note] WSREP: STATE EXCHANGE: got state msg: a3fa8cd5-26bf-11e8-8f00-a686a9b10fbd from 0 (b1)
2018-03-13 9:08:36 140261627782912 [Note] WSREP: STATE EXCHANGE: got state msg: a3fa8cd5-26bf-11e8-8f00-a686a9b10fbd from 1 (db2)
2018-03-13 9:08:36 140261627782912 [Note] WSREP: STATE EXCHANGE: got state msg: a3fa8cd5-26bf-11e8-8f00-a686a9b10fbd from 2 (db3)
2018-03-13 9:08:36 140261627782912 [Note] WSREP: Quorum results:
version = 4,
component = PRIMARY,
conf_id = 20,
members = 2/3 (joined/total),
act_id = 3166274,
last_appl. = 3166245,
protocols = 0/7/3 (gcs/repl/appl),
group UUID = 4687a061-0310-11e8-a49f-534404044853
2018-03-13 9:08:36 140261627782912 [Note] WSREP: Flow-control interval: [28, 28]
2018-03-13 9:08:36 140261627782912 [Note] WSREP: Trying to continue unpaused monitor
2018-03-13 9:08:36 140261931068160 [Note] WSREP: New cluster view: global state: 4687a061-0310-11e8-a49f-534404044853:3166274, view# 21: Primary, number of nodes: 3, my index: 0, protocol version 3
2018-03-13 9:08:36 140261931068160 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification.
2018-03-13 9:08:36 140261931068160 [Note] WSREP: REPL Protocols: 7 (3, 2)
2018-03-13 9:08:36 140261931068160 [Note] WSREP: Assign initial position for certification: 3166274, protocol version: 3
2018-03-13 9:08:36 140261686085376 [Note] WSREP: Service thread queue flushed.
2018-03-13 9:08:39 140261636175616 [Note] WSREP: (050b87ee, 'tcp://0.0.0.0:4567') turning message relay requesting off
Ich sehe keine Fehler, wenn Mariadb versucht, auf dem ausgefallenen Host zu starten:
Mar 13 09:11:43 pn09 systemd: Starting MariaDB 10.1.30 database server...
Mar 13 09:11:49 pn09 sh: WSREP: Recovered position 4687a061-0310-11e8-a49f-534404044853:2564462
Mar 13 09:11:49 pn09 mysqld: 2018-03-13 9:11:49 122545243265280 [Note] /usr/sbin/mysqld (mysqld 10.1.30-MariaDB) starting as process 7558 ...
Mar 13 09:11:50 pn09 rsyncd[7667]: rsyncd version 3.0.9 starting, listening on port 4444
Ich bin diesbezüglich ein wenig ratlos und bin für jede Anleitung dankbar. Mir ist nicht klar, warum es ein Problem sein sollte, den Dienst auf einem einzelnen Knoten wie diesem einfach zu stoppen und zu starten. Die anderen beiden kann ich problemlos hoch- und herunterfahren.
Ein Hinweis: Beim Durchforsten ist mir aufgefallen, dass bei allen 3 Knoten in der Datei grastate.dat SEQNO auf -1 gesetzt ist. Ich bin mir nicht sicher, warum das passiert, ob es ein kritisches Problem ist oder was.
Weiterer interessanter Punkt – einige Hintergrundprozesse werden weiterhin ausgeführt, nachdem der Dienststart fehlgeschlagen ist:
# ps aux |grep mysql
mysql 7558 0.2 0.3 349912 57920 ? Ssl 09:11 0:00 /usr/sbin/mysqld --wsrep_start_position=4687a061-0310-11e8-a49f-534404044853:2564462
mysql 7567 1.2 0.0 113388 1796 ? S 09:11 0:03 /bin/bash -ue /usr//bin/wsrep_sst_rsync --role joiner --address 192.168.10.238 --datadir /var/lib/mysql/ --parent 7558
mysql 7667 0.0 0.0 114652 1068 ? S 09:11 0:00 rsync --daemon --no-detach --port 4444 --config /var/lib/mysql//rsync_sst.conf