Cluster-Setup

Alle STACKIT MariaDB-Cluster-Instanzen laufen in einem synchronen Multi-Master-Replikations-Setup (auch bekannt als Multi-Primary). Dies wird durch den Einsatz von MariaDB Galera Cluster ermöglicht. Diese Cluster-Instanzen arbeiten auf einer Quorum-Basis, wodurch Ihr Cluster so lange betriebsbereit bleibt, wie die Mehrheit der Knoten intakt ist.

MariaDB Galera Cluster

MariaDB Galera Cluster ist ein Multi-Primary-Cluster für STACKIT MariaDB. Dies ermöglicht eine Replikation zum Commit-Zeitpunkt einer Transaktion, indem das mit der Transaktion verknüpfte Write-Set an jeden Knoten im Cluster übertragen wird. MariaDB Galera Cluster ermöglicht es MariaDB-Clustern zudem, mit einer bidirektionalen Replikation zu arbeiten, was bedeutet, dass alle Knoten im MariaDB-Cluster Primaries sind. Standardmäßig erhalten Sie einen 3-Knoten-Cluster mit 3 Primaries. MariaDB Galera Cluster bietet zudem die folgenden Funktionen:

• Synchrone Replikation
• Active-Active-Multi-Primary-Topologie
• Lesen und Schreiben auf jedem Cluster-Knoten
• Automatische Mitgliedschaftskontrolle, fehlerhafte Knoten scheiden aus dem Cluster aus
• Automatischer Beitritt von Knoten
• Echte parallele Replikation auf Zeilenebene

Replikation

Wie oben erwähnt, erfolgt der Replikationsprozess bei einer STACKIT MariaDB-Cluster-Instanz über MariaDB Galera Cluster.

Dies kann über 2 verschiedene Methoden geschehen:

• State Snapshot Transfers (SST)
• Incremental State Transfer (IST)

MariaDB Galera Cluster verwendet die SST-Methode, wenn ein neuer Knoten in den Cluster integriert wird oder wenn ein Knoten in Verzug geraten ist und IST die fehlenden Transaktionen nicht wiederherstellen kann. Zusammenfassend lässt sich sagen, dass diese Methode eine vollständige Datenkopie bereitstellt, die von einem Knoten geliefert wird, der als Spender (Donor) für den neuen/beitretenden Knoten fungiert.

Im Gegensatz dazu wird IST bevorzugt, wenn der beitretende Knoten bereits zum Cluster gehörte. Diese Methode funktioniert, indem die fehlenden Transaktionen identifiziert und nur diese Transaktionen anstelle des vollständigen Status gesendet werden. Die einzige Voraussetzung – abgesehen von der vorherigen Mitgliedschaft – ist, dass die fehlenden Write-Set-Transaktionen in den Binary Logs des Donors verfügbar sein müssen.

Cluster Health Logger

Protokolliert regelmäßig den wsrep- und Bin-Log-Status in /var/vcap/sys/log/cluster- health-logger/cluster_health.log.

Die protokollierten Informationen fassen die folgenden Abfragen zusammen:

SHOW STATUS WHERE Variable_name like 'wsrep%';
SHOW VARIABLES WHERE Variable_name = 'sql_log_bin';