staging.inyokaproject.org

Galera Cluster

Archivierte Anleitung

Dieser Artikel wurde archiviert. Das bedeutet, dass er nicht mehr auf Richtigkeit überprüft oder anderweitig gepflegt wird. Der Inhalt wurde für keine aktuell unterstützte Ubuntu-Version getestet. Wenn du Gründe für eine Wiederherstellung siehst, melde dich bitte in der Diskussion zum Artikel. Bis dahin bleibt die Seite für weitere Änderungen gesperrt.

Ein Galera-Cluster aus mehreren Servern bietet den Vorteil, dass Lese- und Schreibzugriffe auf alle beteiligten Servern erfolgen können und dabei die Datenbanken redundant gehalten werden. Es können alle bis auf einen Server ausfallen, bevor Daten verlorengehen oder der Zugriff nicht mehr möglich ist.

Befehl zum Installieren der Pakete:

sudo apt-get install mariadb-galera-server galera 

Oder mit apturl installieren, Link: apt://mariadb-galera-server,galera

Konfiguration

Konfiguration

Es ist empfehlenswert die Verbindung abzusichern. Hierzu muss man einen Benutzer mit Passwort anlegen. Die weitere Konfiguration erfolgt weiter unten.

mysql -u root -p -e "SET wsrep_on=OFF; GRANT ALL ON *.* TO BENUTZERNAME@'%' IDENTIFIED BY 'PASSWORT';" 

Um Fehler zu vermeiden, sollte man alle leeren Benutzer löschen:

mysql -u root -p -e "SET wsrep_on=OFF; DELETE FROM mysql.user WHERE user='';" 

Es gibt einige Optionen, die für den Betrieb von Galera notwendig sind. Diese sind hier aufgeführt. In der Datei /etc/mysql/my.cnf müssen folgende Einstellungen vorgenommen werden. Bereits in der Datei hinterlegte Einstellungen sollten erhalten bleiben und gegebenenfalls angepasst werden:

[mysqld]
# Wenn bind-address auskommentiert ist, "bind-address = 0.0.0.0" oder
# "bind-address = " gesetzt ist, ist die Datenbank an allen Netzwerkschnittstellen im Netzwerk erreichbar.
# MariaDB kann auch nur an dem Netzwerk verfügbar sein, das über die Netzwerkschnittstelle erreichbar ist:
# bind-address = IP-ADRESSE_EINES_INTERFACES
# Jedenfalls müssen sich die Knoten über das Netzwerk erreichen können.

binlog_format = ROW
innodb_locks_unsafe_for_binlog=1
innodb_autoinc_lock_mode=2
default_storage_engine=InnoDB
query_cache_size=0
query_cache_type=0

[mysqldump]
max_allowed_packet = 16M
quick
quote-names

[mysql]

[isamchk]
!includedir /etc/mysql/conf.d/

In einer Datei unter /etc/mysql/conf.d/ z.B. /etc/mysql/conf.d/mariadb.cnf kann man dann getrennt die spezifischen Galera-Optionen festlegen. Man kann natürlich auch alle Einstellungen in einer Datei sammeln. Es wird aber empfohlen, diese der Übersichtlichkeit halber zu trennen. Man muss sich auch noch überlegen, welche Replikationsmethode verwendet werden soll:

State Snapshot Transfer method (wsrep_sst_method)
Methode Eigenschaften
mysqldump Es wird bei jeder Synchronisation die gesamte Tabelle übertragen, daher langsam
rsync Es wird festgestellt, wo Änderungen stattgefunden haben. Dann werden nur diese übertragen.
xtrabackup Momentan noch experimentell.
eigene Skripte Diese Möglichkeit ist die optimale Lösung, wenn man diese implementieren kann. Dann man kann eine Lösung auf die eigene Datenbank maßschneidern.

Es wird empfohlen, rsync zu verwenden, da diese Methode ziemlich schnell, stabil und bandbreitenschonend ist. Man kann natürlich auch eine eigene Lösung implementieren. Dies ist aber im Vergleich zum Nutzen meist zu viel Arbeit.

Es muss im Folgenden die Option wsrep_cluster_address noch besonders beachtet werden. Hier wird eingestellt, wo der nächste Knoten zu finden ist. Der erste Knoten erhält vorübergehend keine Adresse zum Verbinden. Alle weiteren Knoten bekommen eine Adresse eingetragen, die zu einem Knoten gehört, der bereits an dem Cluster beteiligt ist. Zum Schluss wird auch dem ersten Knoten eine Adresse eingetragen, damit auch dieser sich wieder automatisch mit dem Cluster verbinden kann, wenn dieser Knoten einmal ausfällt.

[client]
# Standard ist Latin1. Es wird für einen Galera-Cluster aber UTF-8 benötigt. (auch in der Serversektion)
default-character-set = utf8

[mysqld]
# Standard ist Latin1. Es wird für einen Galera-Cluster aber UTF-8 benötigt.
character_set_server   = utf8
collation_server       = utf8_general_ci

# "gcom://"" setzen um einen Knoten zu reinitialisieren (resetten)
wsrep_cluster_address = 'gcomm://'
# "gcom://10.10.10.10"" oder "gcom://HOSTNAME"" setzen, um einen Knoten mit bestehenden Cluster-Knoten zu verbinden
#wsrep_cluster_address = 'gcomm://KNOTENADRESSE'

wsrep_provider = /usr/lib/galera/libgalera_smm.so

# Wie oft soll versucht werden, festgefahrene "autocommits" per "commit" abzuschließen
wsrep_retry_autocommit=1

# Übertragungsmethode (mysqldump, rsync, xtrabackup oder eigene Skripte)
wsrep_sst_method=rsync


## Optionale Einstellungen ##

# Authentifizierung (empfohlen)
wsrep_sst_auth=BENUTZERNAME:PASSWORT

# Name des Clusters
wsrep_cluster_name=CLUSTERNAME

# Log-Level auf DEBUG stellen, damit man mehr Infos bekommt. 
# Diese Einstellung ist bei der Einrichtung sehr zu empfehlen, um Fehler zu finden. 
wsrep_debug=1

# Für MyISAM Unterstützung erforderlich
wsrep_replicate_myisam=1

# Konvertiere locking sessions in Transaktionen.
# Transaktionen sorgen dafür, daß bei parallelen Zugriff auf Daten
# diese für einen Zugreifenden gesperrt werden, damit nicht
# der Zufall entscheidet, was am Ende gespeichert wird.
wsrep_convert_LOCK_to_trx=1

# Generate fake primary keys for non-PK tables (required for multi-master and parallel applying operation)
wsrep_certify_nonPK=1

Nun kann man MariaDB neustarten und den Status des Clusters überprüfen:

mysql -e "SHOW STATUS LIKE 'wsrep_%';" 

Die Ausgabe sollte ungefähr so aussehen. Wenn die Node-Anzahl wsrep_cluster_size stimmt, kann man davon ausgehen, dass alles geklappt hat.

+----------------------------+--------------------------------------+
| Variable_name              | Value                                |
+----------------------------+--------------------------------------+
| wsrep_local_state_uuid     | d50ca7c2-8f17-11e2-0800-ca06845fffe9 |
| wsrep_protocol_version     | 4                                    |
| wsrep_last_committed       | 320                                  |
| wsrep_replicated           | 0                                    |
| wsrep_replicated_bytes     | 0                                    |
| wsrep_received             | 3                                    |
| wsrep_received_bytes       | 267                                  |
| wsrep_local_commits        | 0                                    |
| wsrep_local_cert_failures  | 0                                    |
| wsrep_local_bf_aborts      | 0                                    |
| wsrep_local_replays        | 0                                    |
| wsrep_local_send_queue     | 0                                    |
| wsrep_local_send_queue_avg | 0.000000                             |
| wsrep_local_recv_queue     | 0                                    |
| wsrep_local_recv_queue_avg | 0.000000                             |
| wsrep_flow_control_paused  | 0.000000                             |
| wsrep_flow_control_sent    | 0                                    |
| wsrep_flow_control_recv    | 0                                    |
| wsrep_cert_deps_distance   | 0.000000                             |
| wsrep_apply_oooe           | 0.000000                             |
| wsrep_apply_oool           | 0.000000                             |
| wsrep_apply_window         | 0.000000                             |
| wsrep_commit_oooe          | 0.000000                             |
| wsrep_commit_oool          | 0.000000                             |
| wsrep_commit_window        | 0.000000                             |
| wsrep_local_state          | 4                                    |
| wsrep_local_state_comment  | Synced                               |
| wsrep_cert_index_size      | 0                                    |
| wsrep_causal_reads         | 0                                    |
| wsrep_incoming_addresses   | ,                                    |
| wsrep_cluster_conf_id      | 2                                    |
| wsrep_cluster_size         | 2                                    |
| wsrep_cluster_state_uuid   | d50ca7c2-8f17-11e2-0800-ca06845fffe9 |
| wsrep_cluster_status       | Primary                              |
| wsrep_connected            | ON                                   |
| wsrep_local_index          | 1                                    |
| wsrep_provider_name        | Galera                               |
| wsrep_provider_vendor      | Codership Oy <info@codership.com>    |
| wsrep_provider_version     | 23.2.2(r137)                         |
| wsrep_ready                | ON                                   |
+----------------------------+--------------------------------------+

Problembehebung

Galera Cluster Debian-Sys-User inkonsistent

Man erhält beim Starten von MariaDB folgende Fehlermeldung oder findet in den Protokollen ("log files") folgende Fehlermeldung:

"ERROR 1045 (28000): Access denied for user 'debian-sys-maint'@'localhost' (using password: YES)"

Falls man einen Galera-Cluster betreibt, liegt das Problem vor, daß auf den Knoten unterschiedliche Passwörter in den Dateien /etc/mysql/debian.cnf vorhanden sind. Am einfachsten ist es, die Datei von einem Knoten auf den/die anderen zu kopieren. Bei einer Einzelinstallation kann es bei einer Aktualisierung eines Paketes zu einer Veränderung des Passwortes gekommen ist. Man führt einfach folgende SQL-Befehle aus:

1
2
3
grant all privileges on *.* to 'debian-sys-maint'@'localhost' identified by 'newpassword' with grant option;
flush privileges;
quit;

Diese Revision wurde am 3. März 2021 23:11 von tuxifreund erstellt.