🔁Replikation und Galera-Cluster

Klassische Replikation kopiert das Binärlog eines Primary auf Replikate. Galera dagegen repliziert synchron zwischen gleichberechtigten Knoten.

🧬Primary → Replikat mit GTID

Probiere: mehrere Transaktionen schreiben, holen, anwenden – dann das Replikat abstürzen lassen und per GTID neu verbinden.
  Primary (server_id=1)                       Replikat (server_id=2)
┌───────────────────────┐   Binlog-Dump   ┌──────────────┐   ┌─────────────┐
│ COMMIT → Binlog       │ ──────────────▶ │  IO-Thread   │──▶│  Relay-Log  │
│ mariadb-bin.000042    │   (TCP 3306)    └──────────────┘   └──────┬──────┘
│ GTID 0-1-1042         │                                          ▼
└───────────────────────┘                  ┌──────────────────────────────┐
                                           │ SQL-Thread(s) → Daten        │
                                           │ gtid_slave_pos = 0-1-1042    │
                                           └──────────────────────────────┘
Rückstand: 0 Transaktion(en)
🟢 Primary · Binlog
gtid_binlog_pos = (leer)
    📥 Replikat · Relay-Log
    IO-Thread läuft
      🗄️ Replikat · Daten
      gtid_slave_pos = (leer)
      noch nichts angewendet
      • • Primary (server_id = 1) und Replikat (server_id = 2) sind verbunden: CHANGE MASTER TO … MASTER_USE_GTID = slave_pos; START SLAVE;
      💡 MariaDB-GTID
      Format Domain-ServerId-Sequenz, z. B. 0-1-1042. Mehrere Domains erlauben unabhängige Replikationsströme (Multi-Source). MySQL nutzt dagegen server_uuid:1-1042 – die Formate sind nicht kompatibel.
      💡 Asynchron oder semisynchron?
      Standard ist asynchron: Der Primary wartet auf niemanden – fällt er aus, können die letzten Transaktionen fehlen. Semisynchron (in MariaDB fest eingebaut: rpl_semi_sync_master_enabled) wartet, bis mindestens ein Replikat den Empfang bestätigt hat.
      ✅ Parallel anwenden
      slave_parallel_threads lässt das Replikat unabhängige Transaktionen parallel anwenden – hilft, wenn der Rückstand wächst (SHOW SLAVE STATUS\G → Seconds_Behind_Master).

      🕸️Galera-Cluster

      Galera ist fester Bestandteil von MariaDB (wsrep-API). Alle Knoten sind beschreibbar, Konflikte werden per Zertifizierung erkannt.
      Schritt 1 / 7 · Tasten ← →
      GruppenkommunikationKnoten 1bereitKnoten 2bereitKnoten 3bereit

      Drei gleichberechtigte Knoten

      Jeder Knoten nimmt Lese- und Schreibzugriffe an (Multi-Primary). Alle haben denselben Datenbestand; die Gruppenkommunikation hält eine gemeinsame, geordnete Reihenfolge aller Schreibvorgänge.

      💡 Voraussetzungen
      Nur InnoDB-Tabellen werden repliziert, jede Tabelle braucht einen Primärschlüssel. binlog_format=ROW.
      💡 Wann Galera?
      Hochverfügbarkeit ohne manuelles Umschalten, Lesen auf allen Knoten. Schreiblast skaliert nicht – jeder Knoten wendet alle Änderungen an.
      ⚠️ Hotspots
      Viele gleichzeitige Änderungen derselben Zeilen auf verschiedenen Knoten führen zu Zertifizierungsfehlern. Schreibzugriffe dann besser auf einen Knoten lenken (z. B. mit MaxScale).