ComputerBase Menü
Aktuelles

Galera DB-Cluster auf MariaDB und Ubuntu. Wie konfigurieren

maxmad

maxmad

Ensign
Registriert
Aug. 2002
Beiträge
253
Moin zusammen :-)

Wer kennt sich vom Grundsatz her mit der Einrichtung eines Datenbank-HA Clusters mittels MariaDB + Galera und auf Basis von Ubuntu-Server aus?

Die DB-Nodes sind soweit mit MariaDB 10.0 in der Galeraversion bestückt. Jetzt hab ich allerdings Probleme damit die Konfigurationsdateien richtig einzustellen um das ganze zu einem Cluster zusammenzufügen.

Alle Anleitungen und Videotutorials die ich dazu bisher im Netz gefunden habe gehen allesamt unterschiedlich vor.

Ich wüsste erst mal gerne wer sich damit grundsätzlich auskennt bzw. wer schon mal sowas erfolgreich konfiguriert hat. Anschließend würde ich das Problem dann Anhand meiner "my.cnf" konkretisieren.

Danke :-)
 
Ui, ein DB-Cluster. Tolle Spielwiese :) Ein gut gemeinter Tipp - teste alles erstmal in einer abgekapselten Testumgebung, bevor du dich an ein DB-System mit Echtdaten begibst.

Was sind denn deine konkreten Probleme? Ich habe das nur mal auf einer Schulung gemacht, aber prinzipiell ist es doch recht einfach:

  1. Starte alle Nodes mit wsrep_provider = none
  2. Lege auf allen Nodes einen sst user an
  3. Fahre alle Nodes herunter
  4. Füge in allen Nodes in der my.cnf wsrep_provider und wsrep_cluster_address hinzu
  5. Starte Node 1 mit --wsrep-new-cluster
  6. Starte Node 2-x
  7. Jetzt sollten alle Nodes ein initialen SST machen

Natürlich müssen die my.cnf der Cluster entsprechende Einträge für einige wsrep-configs haben, z.B. "wsrep_node_name" etc.. Bei der Schulung hatten wir das Ding recht fix zum Fliegen gebracht. Wenn du Details zum Schulungsanbieter haben willst (den ich echt empfehlen kann) -> PN.
 
Keine Sorge, meine drei Testnodes sind VM's die auf einem Xen-Hypervisor laufen ;-) Der Wirt hat auch ausreichend Dampf. Produktiv wird da vorläufig so schnell nichts gehen.

Konkret habe ich die my.cnf so angepasst wie es bei, Hersteller beschrieben ist.
http://galeracluster.com/documentation-webpages/gettingstarted.html

nach dem speichern und dem anschließenden Start mittels --wsrep-new-cluster sieht auch alles gut aus. Aber wenn ich am am DB-Server mittels "mysql -u root -p" anmelden will zeigt er dann den Fehler an dass der Eintrag
default_storage_engine=InnoDB unbekannt sei. Daran habe ich aber nichts verändert und InnoDB als Engine ist ja eigentlich auch korrekt.

Wozu ist denn der sst User nötig. Das hab ich bisher noch in keiner Anleitung gefunden :-D Ansonsten habe ich grob alle Schritte die du ansprichst befolgt.

Hast du die Schulung zufällig in Hamburg gemacht? ;-)
Ergänzung ()

Bei dem obenen genannten Link stört mich im übrigen das sich keine Angabe darüber findet auch welche Versionsnummer der Software sich das bezieht. Finde ich bei einer Anleitung die vom Hersteller kommt schon etwas seltsam....
 
Wenn er default_storage_engine nicht erkennt, dann klingt das nach einer missglückten my.cnf. Kannst du die hier mal posten? Ein beliebter Fehler ist es, neue Einträge am Ende der config hinzuzufügen. Dann stehen sie aber unter [mysqld_safe], eigentlich müssten sie unter [mysqld] weiter oben stehen.

Du kannst den Eintrag aber auch einfach weglassen, sofern du eine halbwegs aktuelle Version verwendest. Seit MariaDB 5.5 ist default engine sowieso innodb (siehe MariaDB-Doku).

Der SST-User ist nicht nötig für den Betrieb, wenn du keinen anlegst und konfigurierst, dann wird der SST eben via root-Nutzer ausgeführt. Und daran stören sich viele (inkl. mir), denn der Nutzer root sollte wirklich nur im Ausnahmefall für administrative Zwecke verwendet werden und nicht im Regelbetrieb. Das sind aber Feinheiten, die für das initiale Test-Setup erstmal irrelevant sind.

Wegen der Schulung schicke ich dir mal eine PM.
 
Bisher bin ich auf folgendem Stand:

auf dem Pfad "/etc/mysql/conf.d" habe ich die Datei "cluster.cnf" erstellt und dort folgendes als Konfiguration auf dem DB-Hauptserver eingetragen:

Code: 
[mysqld]
query_cache_size=0
binlog_format=ROW
default-storage-engine=innodb
innodb_autoinc_lock_mode=2
query_cache_type=0
#bind-address=0.0.0.0

# Galera Provider Configuration
wsrep_provider=/usr/lib/galera/libgalera_smm.so
#wsrep_provider_options="gcache.size=32G"

# Galera Cluster Configuration
wsrep_cluster_name="max_cluster"
#wsrep_cluster_address="gcomm://192.168.11.63,192.168.11.64,192.168.11.65"

# Galera Synchronization Congifuration
wsrep_sst_method=rsync
#wsrep_sst_auth=user:pass

# Galera Node Configuration
wsrep_node_address="192.168.11.63"
wsrep_node_name="node1-ubuntudesktop"[/I][/I]

Der Part #wsrep_cluster_address="gcomm://192.168.11.63,192.168.11.64,192.168.11.65"

ist auskommentiert da sich der Server per "sudo service mysql start --wsrep-new-cluster"

nicht starten ließ und einen Fehler geworfen hat.

Im zweiten Node ist dann in der "cluster.cnf" folgendes eingetragen:

Code: 
[mysqld]
query_cache_size=0
binlog_format=ROW
default-storage-engine=innodb
innodb_autoinc_lock_mode=2
query_cache_type=0
#bind-address=0.0.0.0

# Galera Provider Configuration
wsrep_provider=/usr/lib/galera/libgalera_smm.so
#wsrep_provider_options="gcache.size=32G"

# Galera Cluster Configuration
wsrep_cluster_name="max_cluster"
wsrep_cluster_address="gcomm://192.168.11.63,192.168.11.64,192.168.11.65"

# Galera Synchronization Congifuration
wsrep_sst_method=rsync
#wsrep_sst_auth=user:pass

# Galera Node Configuration
wsrep_node_address="192.168.11.64"
wsrep_node_name="node2-ubuntuserver"

hier dann das gleich Bild. Per sudo service mysql start kommt der Node nicht hoch und wirft einen Fehler.

Per "journalctl -xe" finden sich dann folgende Fehlermeldungen:

Code: 
Sep 27 11:29:35 node2-ubuntuserver mysqld[4138]: 160927 11:29:35 [Note] WSREP: view((empty))
Sep 27 11:29:35 node2-ubuntuserver mysqld[4138]: 160927 11:29:35 [ERROR] WSREP: failed to open gcomm backend connection: 110
Sep 27 11:29:35 node2-ubuntuserver mysqld[4138]:          at gcomm/src/pc.cpp:connect():162
Sep 27 11:29:35 node2-ubuntuserver mysqld[4138]: 160927 11:29:35 [ERROR] WSREP: gcs/src/gcs_core.cpp:gcs_core_open():208: Fa
Sep 27 11:29:35 node2-ubuntuserver mysqld[4138]: 160927 11:29:35 [ERROR] WSREP: gcs/src/gcs.cpp:gcs_open():1380: Failed to o
Sep 27 11:29:35 node2-ubuntuserver mysqld[4138]: 160927 11:29:35 [ERROR] WSREP: gcs connect failed: Connection timed out
Sep 27 11:29:35 node2-ubuntuserver mysqld[4138]: 160927 11:29:35 [ERROR] WSREP: wsrep::connect(gcomm://192.168.11.63,192.168
Sep 27 11:29:35 node2-ubuntuserver mysqld[4138]: 160927 11:29:35 [ERROR] Aborting
Sep 27 11:29:35 node2-ubuntuserver mysqld[4138]:
Sep 27 11:29:35 node2-ubuntuserver mysqld[4138]: 160927 11:29:35 [Note] WSREP: Service disconnected.
Sep 27 11:29:36 node2-ubuntuserver mysqld[4138]: 160927 11:29:36 [Note] WSREP: Some threads may fail to exit.
Sep 27 11:29:36 node2-ubuntuserver mysqld[4138]: 160927 11:29:36 [Note] /usr/sbin/mysqld: Shutdown complete
Sep 27 11:29:36 node2-ubuntuserver mysqld[4138]:
Sep 27 11:29:36 node2-ubuntuserver mysqld_safe[4413]: mysqld from pid file /var/run/mysqld/mysqld.pid ended
Sep 27 11:35:48 node2-ubuntuserver sudo[4429]:      zb2 : TTY=pts/0 ; PWD=/etc/mysql/conf.d ; USER=root ; COMMAND=/usr/bin/v
Sep 27 11:35:48 node2-ubuntuserver sudo[4429]: pam_unix(sudo:session): session opened for user root by zb2(uid=0)
Sep 27 11:40:55 node2-ubuntuserver sudo[4429]: pam_unix(sudo:session): session closed for user root

Ich verstehe das so das er irgendwie nicht in der Lage ist die Verbindung zum Cluster aufzubauen aber ich kann mir noch nicht
richtig einen Reim drauf machen an welcher Stelle die Config falsch ist. Jemand ne Idee?
 
Zuletzt bearbeitet:
Du musst dich einloggen oder registrieren, um hier zu antworten.

Passend zum Thema

Zurück
Oben

Willkommen auf ComputerBase!

Mit Werbung weiterlesen

Besuche ComputerBase wie gewohnt mit Werbung und Tracking. Die Zustimmung ist jederzeit widerrufbar.

Details im Privacy Center und in der Liste unserer Partner. Ein Widerruf ist möglich in der Datenschutzerklärung.

… oder ComputerBase Pro bestellen

Nutze ComputerBase ohne Werbebanner, Video-Ads und Werbetracking schon für 4 €/Monat oder 36 €/Jahr.

Mehr zu ComputerBase Pro

Bereits Pro-Nutzer? Hier anmelden.

Tracking: Wir und unsere 165 Partner verarbeiten personenbezogene Daten, indem wir mit auf Ihrem Gerät gespeicherten Informationen (z. B. eindeutige Kennungen in Cookies) ein Nutzungsprofil erstellen, um z. B. Anzeigen zu personalisieren. Verarbeitungszwecke: Genaue Standortdaten und Abfrage von Geräteeigenschaften zur Identifikation, Informationen auf einem Gerät speichern und/oder abrufen, Personalisierte Anzeigen und Inhalte, Anzeigen- und Inhaltsmessungen, Erkenntnisse über Zielgruppen und Produktentwicklungen.

Impressum Kontakt Datenschutz