MariaDB
 sql >> Datenbank >  >> RDS >> MariaDB

Ein Leitfaden zur Cluster-Streaming-Replikation von MySQL Galera:Teil Eins

Streaming-Replikation ist eine neue Funktion, die mit der Version 4.0 von Galera Cluster eingeführt wurde. Galera verwendet die Replikation synchron über den gesamten Cluster, aber vor dieser Version wurden Write-Sets mit mehr als 2 GB nicht unterstützt. Mit der Streaming-Replikation können Sie jetzt große Write-Sets replizieren, was sich perfekt für Masseneinfügungen oder das Laden von Daten in Ihre Datenbank eignet.

In einem früheren Blog haben wir über den Umgang mit großen Transaktionen mit Streaming-Replikation und MariaDB 10.4 geschrieben, aber zum Zeitpunkt der Erstellung dieses Blogs hatte Codership seine Version des neuen Galera-Clusters noch nicht veröffentlicht. Percona hat jedoch seine experimentelle Binärversion von Percona XtraDB Cluster 8.0 veröffentlicht, die die folgenden Merkmale hervorhebt...

  • Streaming-Replikation unterstützt große Transaktionen

  • Die Synchronisierungsfunktionen ermöglichen eine Aktionskoordination (wsrep_last_seen_gtid, wsrep_last_written_gtid, wsrep_sync_wait_upto_gtid)

  • Detailliertere und verbesserte Fehlerprotokollierung. wsrep_debug ist jetzt eine mehrwertige Variable, die bei der Steuerung der Protokollierung hilft, und Protokollierungsmeldungen wurden erheblich verbessert.

  • Einige DML- und DDL-Fehler auf einem replizierenden Knoten können entweder ignoriert oder unterdrückt werden. Verwenden Sie zum Konfigurieren die Variable wsrep_ignore_apply_errors.

  • Mehrere Systemtabellen helfen, mehr über den Status des Clusterstatus herauszufinden.

  • Die wsrep-Infrastruktur von Galera 4 ist robuster als die von Galera 3. Sie bietet eine schnellere Ausführung von Code mit besserer Zustandsbehandlung, verbesserter Vorhersagbarkeit und Fehlerbehandlung.

Was ist neu bei Galera Cluster 4.0?

Die neue Streaming-Replikationsfunktion

Bei der Streaming-Replikation werden Transaktionen während der Transaktionsverarbeitung schrittweise in kleinen Fragmenten repliziert (d. h. vor dem eigentlichen Commit replizieren wir eine Reihe kleiner Fragmente). Replizierte Fragmente werden dann in Slave-Threads angewendet, wodurch der Status der Transaktion in allen Cluster-Knoten erhalten bleibt. Fragmente halten Sperren in allen Knoten und können später nicht kollidiert werden.

Galera-Systemtabellen 

Datenbankadministratoren und Clients mit Zugriff auf die MySQL-Datenbank können diese Tabellen lesen, aber sie können sie nicht ändern, da die Datenbank selbst alle erforderlichen Änderungen vornimmt. Wenn Ihr Server diese Tabellen nicht hat, kann es sein, dass Ihr Server eine ältere Version von Galera Cluster verwendet.

#> show tables from mysql like 'wsrep%';

+--------------------------+

| Tables_in_mysql (wsrep%) |

+--------------------------+

| wsrep_cluster            |

| wsrep_cluster_members    |

| wsrep_streaming_log      |

+--------------------------+

3 rows in set (0.12 sec)

Neue Synchronisierungsfunktionen 

Diese Version führt eine Reihe von SQL-Funktionen zur Verwendung in wsrep-Synchronisationsoperationen ein. Sie können sie verwenden, um die globale Transaktions-ID zu erhalten, die entweder auf der zuletzt geschriebenen oder der zuletzt gesehenen Transaktion basiert. Sie können den Knoten auch so einstellen, dass er auf die Replikation und Anwendung einer bestimmten GTID wartet, bevor er die nächste Transaktion initiiert.

Intelligente Spenderauswahl

Einige unauffällige Funktionen, die seit Galera 3.x vorhanden sind, beinhalten die intelligente Spenderauswahl und die Cluster-Absturzwiederherstellung. Diese waren ursprünglich für Galera 4 geplant, haben es aber vor allem aufgrund von Kundenanforderungen in frühere Releases geschafft. Bei der Auswahl der Spenderknoten in Galera 3 wurde der State Snapshot Transfer (SST)-Spender nach dem Zufallsprinzip ausgewählt. Mit Galera 4 erhalten Sie jedoch eine viel intelligentere Wahl, wenn es um die Auswahl eines Spenders geht, da es einen Spender bevorzugt, der einen inkrementellen Staatstransfer (IST) leisten kann, oder einen Spender im selben Segment auswählt. Als Datenbankadministrator können Sie dies über die Einstellung wsrep_sst_donor.

erzwingen

Warum MySQL Galera-Cluster-Streaming-Replikation verwenden?

Langfristige Transaktionen

Die Probleme und Einschränkungen von Galera drehten sich immer darum, wie lange Transaktionen gehandhabt wurden, und führten oft dazu, dass der gesamte Cluster aufgrund großer replizierter Write-Sets langsamer wurde. Die Flusskontrolle geht oft hoch, wodurch die Schreibvorgänge verlangsamt oder sogar der Prozess beendet werden, um den Cluster wieder in seinen normalen Zustand zu versetzen. Dies ist ein ziemlich häufiges Problem mit früheren Versionen von Galera Cluster.

Codership empfiehlt, die Streaming-Replikation für Ihre lang andauernden Transaktionen zu verwenden, um diese Situationen zu entschärfen. Sobald der Knoten ein Fragment repliziert und zertifiziert hat, ist es für andere Transaktionen nicht mehr möglich, es abzubrechen.

Große Transaktionen

Dies ist sehr hilfreich, wenn Sie Daten in Ihren Bericht oder Ihre Analyse laden. Das Erstellen von Masseneinfügungen, -löschungen, -aktualisierungen oder die Verwendung der LOAD DATA-Anweisung zum Laden großer Datenmengen kann in diese Kategorie fallen. Obwohl es davon abhängt, wie Sie Ihre Daten zum Abrufen oder Speichern verwalten. Sie müssen berücksichtigen, dass die Streaming-Replikation dahingehend eingeschränkt ist, dass Zertifizierungsschlüssel aus Datensatzsperren generiert werden.

Ohne Streaming-Replikation würde die Aktualisierung einer großen Anzahl von Datensätzen zu einem Konflikt führen und die gesamte Transaktion müsste rückgängig gemacht werden. Slaves, die auch große Transaktionen replizieren, unterliegen der Flusskontrolle, wenn sie den Schwellenwert erreicht und beginnt, den gesamten Cluster zu verlangsamen, um Schreibvorgänge zu verarbeiten, da sie dazu neigen, den Empfang eingehender Transaktionen von der synchronen Replikation zu lockern. Galera wird die Replikation lockern, bis der Write-Set verwaltbar ist, da die Replikation wieder fortgesetzt werden kann. Überprüfen Sie diesen externen Blog von Percona, um mehr über die Flusskontrolle in Galera zu erfahren.

Bei der Streaming-Replikation beginnt der Knoten, die Daten mit jedem Transaktionsfragment zu replizieren, anstatt auf die Übergabe zu warten. Dies bedeutet, dass keine widersprüchlichen Transaktionen, die in den anderen Knoten ausgeführt werden, abgebrochen werden können, da dies lediglich bestätigt, dass der Cluster den Schreibsatz für dieses bestimmte Fragment zertifiziert hat. Es ist kostenlos, andere gleichzeitige Transaktionen anzuwenden und festzuschreiben, ohne zu blockieren, und große Transaktionen mit minimalen Auswirkungen auf den Cluster zu verarbeiten.

Hot Records/Hot Spots

Heiße Datensätze oder Zeilen sind die Zeilen in Ihrer Tabelle, die ständig aktualisiert werden. Diese Daten könnten die am häufigsten besuchten sein und den Verkehr Ihrer gesamten Datenbank stark erhöhen (z. B. Newsfeeds, ein Zähler wie die Anzahl der Besuche oder Protokolle). Mit Streaming Replication können Sie kritische Updates für den gesamten Cluster erzwingen.

Wie vom Galera-Team bei Codership festgestellt

„Das Ausführen einer Transaktion auf diese Weise sperrt effektiv den heißen Datensatz auf allen Knoten und verhindert, dass andere Transaktionen die Zeile ändern. Es erhöht auch die Chancen, dass die Transaktion erfolgreich abgeschlossen wird und der Kunde wiederum das gewünschte Ergebnis erhält.“

Dies ist mit Einschränkungen verbunden, da es möglicherweise nicht dauerhaft und konsistent ist, dass Sie erfolgreiche Commits haben. Ohne die Verwendung von Streaming-Replikation werden Sie am Ende hohe Chancen oder Rollbacks haben, und das könnte den Endbenutzer zusätzlich belasten, wenn dieses Problem aus Sicht der Anwendung auftritt.

Dinge, die bei der Verwendung der Streaming-Replikation zu beachten sind

  • Zertifizierungsschlüssel werden aus Datensatzsperren generiert, daher decken sie keine Lückensperren oder Next-Key-Sperren ab. Wenn die Transaktion eine Lückensperre ergreift, ist es möglich, dass eine Transaktion, die auf einem anderen Knoten ausgeführt wird, einen Schreibsatz anwendet, der auf das Lückenprotokoll trifft, und die Streaming-Transaktion abbricht.
  • Wenn die Streaming-Replikation aktiviert wird, werden Write-Set-Protokolle in die wsrep_streaming_log-Tabelle geschrieben, die sich in der mysql-Systemdatenbank befindet, um die Persistenz zu bewahren, falls ein Absturz auftritt, sodass diese Tabelle bei der Wiederherstellung dient. Bei übermäßiger Protokollierung und erhöhtem Replikationsaufwand führt die Streaming-Replikation zu einer verringerten Transaktionsdurchsatzrate. Dies könnte ein Leistungsengpass sein, wenn eine hohe Spitzenlast erreicht wird. Daher wird empfohlen, dass Sie die Streaming-Replikation nur auf Sitzungsebene aktivieren und dann nur für Transaktionen, die ohne sie nicht korrekt ausgeführt würden.
  • Der beste Anwendungsfall ist die Nutzung der Streaming-Replikation, um große Transaktionen zu reduzieren
  • Fragmentgröße auf ~10.000 Zeilen festlegen
  • Fragmentvariablen sind Sitzungsvariablen und können dynamisch gesetzt werden
  • Intelligente Anwendung kann Streaming-Replikation nach Bedarf ein- und ausschalten

Fazit

Danke fürs Lesen, in Teil 2 besprechen wir, wie Sie die Galera-Cluster-Streaming-Replikation aktivieren und wie die Ergebnisse für Ihr Setup aussehen könnten.