Freigeben über

Lesereplikate in Azure Database for MySQL – Flexible Server

  • Artikel

MySQL ist eine der beliebtesten Datenbank-Engines für die Ausführung von Web- und mobilen Anwendungen im Internet. Viele unserer Kunden verwenden es für ihre Onlinebildungsdienste, Videostreamingdienste, digitalen Zahlungslösungen, E-Commerce-Plattformen, Gamingdienste, Nachrichtenportale sowie für Websites für Behörden und das Gesundheitswesen. Diese Dienste müssen in dem Maße, wie der Datenverkehr im Web oder bei mobilen Anwendungen zunimmt, genutzt und skaliert werden.

Auf der Anwendungsseite wird die Anwendung typischerweise in Java oder PHP entwickelt und migriert, um auf Microsoft Azure Virtual Machine Scale Sets oder Azure App Services ausgeführt zu werden, oder sie wird containerisiert, um unter Azure Kubernetes Service (AKS) ausgeführt zu werden. Mit VM-Skalierungsgruppen, App Service oder AKS als zugrundeliegende Infrastruktur wird die Anwendungsskalierung vereinfacht, indem neue VMs sofort bereitgestellt und die statusfreien Komponenten von Anwendungen repliziert werden, um die Anforderungen zu erfüllen, aber oft wird die Datenbank als zentrale statusbehaftete Komponente zum Engpass.

Mit dem Lesereplikat können Sie Daten von einer Instanz von Azure Database for MySQL – Flexibler Server auf einem schreibgeschützten Server replizieren. Sie können vom Quellserver auf bis zu zehn Replikate replizieren. Replikate werden asynchron mithilfe des auf der Position der nativen, binären Protokolldatei (binlog) basierenden Replikationsverfahrens der MySQL-Engine aktualisiert. Weitere Informationen zur binlog-Replikation finden Sie unter Binary Log File Position Based Replication Configuration Overview (Konfiguration der auf der Position der binären Protokolldatei basierenden Replikation – Übersicht).

Replikate sind neue Server, die Sie ähnlich wie Ihre Quellinstanzen von Azure Database for MySQL – Flexibler Server verwalten. Für jedes Lesereplikat werden Ihnen Gebühren belastet, die auf der bereitgestellten Compute in vCores und Speicherplatz in GB/Monat basieren. Weitere Informationen finden Sie unter Azure Data Lake Storage – Preise.

Hinweis

Das Feature für Lesereplikate ist nur für Instanzen von Azure Database for MySQL – Flexibler Server in den Tarifen „Universell“ oder „Unternehmenskritisch“ verfügbar. Stellen Sie sicher, dass für den Quellserver einer der folgenden Tarife festgelegt ist.

Weitere Informationen zu Features und Problemen der MySQL-Replikation finden Sie in der Dokumentation zur MySQL-Replikation.

Hinweis

Dieser Artikel enthält Verweise auf den Begriff Slave, einen Begriff, den Microsoft nicht mehr verwendet. Sobald der Begriff aus der Software entfernt wurde, wird er auch aus diesem Artikel entfernt.

Allgemeine Anwendungsfälle für Lesereplikate

Das Feature für Lesereplikate kann die Leistung und Skalierung von leseintensiven Workloads verbessern. Leseworkloads können in den Replikaten isoliert werden, während Schreibworkloads an den Quellserver weitergeleitet werden können.

Häufige Szenarien:

  • Skalierung von Leseworkloads, die von der Anwendung stammen, unter Verwendung eines einfachen Verbindungsproxys wie ProxySQL oder von auf Microservices basierenden Mustern zum Aufskalieren Ihrer Leseabfragen, die von der Anwendung stammen, um Replikate zu lesen.
  • BI- oder analytische Workloads zur Berichterstellung können Lesereplikate als Datenquelle für die Berichterstellung verwenden.
  • Für ein IoT- oder Produktionsszenario, bei dem Telemetrieinformationen in der MySQL-Datenbank-Engine erfasst werden, während mehrere Lesereplikate für die Datenberichterstellung verwendet werden.

Da Replikate schreibgeschützt sind, führen sie nicht direkt zu einer verringerten Auslastung der Schreibkapazität auf der Quelle. Dieses Feature ist nicht auf schreibintensive Workloads ausgerichtet.

Das Lesereplikatfeature verwendet die asynchrone MySQL-Replikation. Das Feature ist nicht für synchrone Replikationsszenarien vorgesehen. Zwischen der Quelle und dem Replikat gibt es eine messbare Verzögerung. Letztendlich sind die Daten auf dem Replikat mit den Daten auf dem Quellserver konsistent. Verwenden Sie das Feature für Workloads, für die diese Verzögerung akzeptabel ist.

Regionsübergreifende Replikation

Sie können ein Lesereplikat erstellen, das sich in einer anderen Region als Ihr Quellserver befindet. Die regionsübergreifende Replikation kann beispielsweise hilfreich sein, um die Notfallwiederherstellung zu planen oder Daten näher beim Benutzer bereitzustellen. Azure Database for MySQL – Flexibler Server ermöglicht die Bereitstellung von Lesereplikaten in allen von Azure unterstützten Regionen, in denen Azure Database for MySQL – Flexibler Server verfügbar ist. Mit dieser Funktion kann ein Quellserver ein Replikat in seiner gepaarten Region oder in den universellen Replikatregionen haben. Hier finden Sie die Liste der Azure-Regionen, in denen Azure Database for MySQL – Flexibler Server aktuell verfügbar ist.

Erstellen eines Replikats

Wenn ein Quellserver keine vorhandenen Replikatserver aufweist, startet die Quelle zunächst neu, um sich auf die Replikation vorzubereiten.

Wenn Sie den Workflow „Replikat erstellen“ starten, wird eine leere Instanz von Azure Database for MySQL – Flexibler Server erstellt. Der neue Server wird mit den Daten gefüllt, die auf dem Quellserver vorhanden waren. Die Erstellungszeit hängt von der Datenmenge in der Quelle und der verstrichenen Zeit seit der letzten wöchentlichen vollständigen Sicherung ab. Dieser Zeitraum kann wenige Minuten bis zu mehrere Stunden umfassen.

Hinweis

Lesereplikate werden mit der gleichen Serverkonfiguration wie die Quelle erstellt. Die Replikatserverkonfiguration kann nach der Erstellung geändert werden. Der Replikatserver wird immer in derselben Ressourcengruppe und demselben Abonnement wie der Quellserver erstellt. Wenn Sie einen Replikatserver in einer anderen Ressourcengruppe oder einem anderen Abonnement erstellen möchten, können Sie nach der Erstellung den Replikatserver verschieben. Für die Konfiguration des Replikatservers sollten mindestens die gleichen Werte verwendet werden wie für den Quellserver, damit das Replikat über genügend Kapazität verfügt.

Erfahren Sie, wie Sie ein Lesereplikat im Azure-Portal erstellen.

Herstellen einer Verbindung mit einem Replikat

Bei der Erstellung erbt ein Replikat die Konnektivitätsmethode des Quellservers. Sie können die Konnektivitätsmethode des Replikats nicht ändern. Wenn der Quellserver beispielsweise über privaten Zugriff (VNet-Integration) verfügt, kann das Replikat nicht den öffentlichen Zugriff (zulässige IP-Adressen) aufweisen.

Das Replikat erbt das Administratorkonto vom Quellserver. Alle Benutzerkonten auf dem Quellserver werden auf die Lesereplikate repliziert. Sie können nur mit denjenigen Benutzerkonten eine Verbindung mit einem Lesereplikat herstellen, die auf dem Quellserver verfügbar sind.

Sie können eine Verbindung mit dem Replikat herstellen, indem Sie wie bei einer normalen Instanz von Azure Database for MySQL – Flexibler Server dessen Hostnamen und ein gültiges Benutzerkonto verwenden. Für einen Server namens myreplica mit dem Administratorbenutzernamen myadmin können Sie eine Verbindung mit dem Replikat herstellen, indem Sie die mysql-Befehlszeilenschnittstelle verwenden:

mysql -h myreplica.mysql.database.azure.com -u myadmin -p

Geben Sie an der Eingabeaufforderung das Kennwort für das Benutzerkonto ein.

Überwachen der Replikation

Azure Database for MySQL Flexible Server stellt die Metrik „Replication lag in seconds“ (Replikationsverzögerung in Sekunden) in Azure Monitor bereit. Diese Metrik steht nur für Replikate zur Verfügung. Diese Metrik wird mithilfe der seconds_behind_master-Metrik berechnet, die im MySQL-Befehl SHOW SLAVE STATUS verfügbar ist. Legen Sie eine Warnung fest, um Sie zu benachrichtigen, wenn die Replikationsverzögerung einen Wert erreicht, der für Ihre Workload nicht annehmbar ist.

Wenn Sie eine längere Replikationsverzögerung beobachten, lesen Sie Behandeln von Problemen mit der Replikationswartezeit, um mögliche Ursachen zu verstehen und zu beheben.

Wichtig

Das Lesereplikat verwendet speicherbasierte Replikationstechnologie, die nicht mehr die Metrik „SLAVE_IO_RUNNING“/„REPLICA_IO_RUNNING“ verwendet, die im MySQL-Befehl „SHOW SLAVE STATUS“/„SHOW REPLICA STATUS“ verfügbar ist. Dieser Wert wird immer als „Nein“ angezeigt und gibt keinen Hinweis auf den Replikationsstatus. Informationen zum richtigen Status der Replikation finden Sie unter Replikationsmetriken – Replikat-E/A-Status und Replikat-SQL-Status auf dem Blatt „Überwachung“.

Beenden der Replikation

Sie können die Replikation zwischen einer Quelle und einem Replikat beenden. Sobald die Replikation zwischen einem Quellserver und einem Lesereplikat beendet wurde, wird das Replikat zu einem eigenständigen Server. Bei den Daten auf diesem eigenständigen Server handelt es sich um die Daten, die zu dem Zeitpunkt, als der Befehl zum Beenden der Replikation gestartet wurde, auf dem Replikatserver vorhanden waren. Der eigenständige Server wird nicht zusammen mit dem Quellserver aktualisiert.

Wenn Sie die Replikation zu einem Replikat stoppen, gehen alle Links zu seiner vorherigen Quelle und zu anderen Replikaten verloren. Zwischen einer Quelle und dem zugehörigen Replikat erfolgt kein automatisiertes Failover.

Wichtig

Der eigenständige Server kann nicht wieder in ein Replikat umgewandelt werden. Stellen Sie vor dem Beenden der Replikation auf einem Lesereplikat sicher, dass das Replikat alle erforderlichen Daten enthält.

Erfahren Sie, wie Sie die Replikation auf ein Replikat beenden.

Failover

Zwischen Quell- und Replikatservern erfolgt kein automatisiertes Failover.

Lesereplikate sind für die Skalierung leseintensiver Workloads gedacht und sind nicht dafür ausgelegt, die Hochverfügbarkeitsanforderungen eines Servers zu erfüllen. Das Beenden der Replikation bei einem Lesereplikat, um es im Lese-/Schreibmodus online zu schalten, ist die Methode, mit der dieser manuelle Failover durchgeführt wird.

Da die Replikation asynchron erfolgt, gibt es eine Verzögerung zwischen der Quelle und dem Replikat. Die Verzögerungsdauer kann durch viele Faktoren beeinflusst werden, z. B. durch den Umfang der Workload auf dem Quellserver und die Wartezeit zwischen Rechenzentren. In den meisten Fällen beträgt die Replikatverzögerung einige Sekunden bis zu einigen Minuten. Sie können die tatsächliche Replikatverzögerung mithilfe der Metrik Replikatverzögerung nachverfolgen, die für jedes Replikat verfügbar ist. Diese Metrik zeigt die seit der letzten wiedergegebenen Transaktion verstrichene Zeit an. Es wird empfohlen, die durchschnittliche Verzögerung zu ermitteln, indem Sie die Replikatverzögerung über einen bestimmten Zeitraum hinweg beobachten. Sie können eine Warnung für die Replikatverzögerung festlegen, sodass Sie Maßnahmen ergreifen können, wenn sie sich außerhalb des erwarteten Bereichs befindet.

Tipp

Wenn Sie ein Failover auf das Replikat durchführen, zeigt die Verzögerung zum Zeitpunkt der Trennung des Replikats von der Quelle an, wie viel Daten verloren werden.

Nachdem Sie sich für ein Failover auf ein Replikat entschieden haben:

  1. Beenden der Replikation auf das Replikat
    Dieser Schritt ist erforderlich, damit der Replikatserver Schreibvorgänge akzeptieren kann. Im Rahmen dieses Prozesses wird der Replikatserver von der Quelle getrennt. Nachdem Sie das Beenden der Replikation initiiert haben, dauert der Back-End-Prozess in der Regel etwa zwei Minuten. Informationen zu den Auswirkungen dieser Aktion finden Sie im Abschnitt Beenden der Replikation in diesem Artikel.

  2. Verweisen der Anwendung auf das (ehemalige) Replikat
    Jeder Server verfügt über eine eindeutige Verbindungszeichenfolge. Aktualisieren Sie Ihre Anwendung so, dass Sie auf das (ehemalige) Replikat und nicht auf die Quelle verweist.

Wenn die Anwendung erfolgreich Lese- und Schreibvorgänge verarbeitet, haben Sie das Failover abgeschlossen. Die Downtime Ihrer Anwendung hängt davon ab, wann Sie ein Problem erkennen und die oben beschriebenen Schritte 1 und 2 ausführen.

Globaler Transaktionsbezeichner (GTID)

Der globale Transaktionsbezeichner (Global Transaction Identifier, GTID) ist ein eindeutiger Bezeichner, der mit jeder auf einem Quellserver committeten Transaktion erstellt wird, und für Azure Database for MySQL – Flexibler Server standardmäßig deaktiviert (OFF). GTID wird von den Versionen 5.7 und 8.0 unterstützt. Weitere Informationen zum GTID und seiner Verwendung in der Replikation finden Sie unter Replikation mit GTID in der MySQL-Dokumentation.

Die folgenden Serverparameter sind für die Konfiguration des globalen Transaktionsbezeichners (GTID) verfügbar:

Serverparameter Beschreibung Standardwert Werte
gtid_mode Gibt an, ob GTIDs zur Identifizierung von Transaktionen verwendet werden. Änderungen zwischen Modi können nur nacheinander in aufsteigender Reihenfolge durchgeführt werden (z. B. OFF>OFF_PERMISSIVE>ON_PERMISSIVE>ON). OFF* OFF: Sowohl neue als auch replizierte Transaktionen müssen anonym sein
OFF_PERMISSIVE: Neue Transaktionen sind anonym. Replizierte Transaktionen können entweder anonyme Transaktionen oder GTID-Transaktionen sein.
ON_PERMISSIVE: Neue Transaktionen sind GTID-Transaktionen. Replizierte Transaktionen können entweder anonyme Transaktionen oder GTID-Transaktionen sein.
ON: Sowohl neue als auch replizierte Transaktionen müssen GTID-Transaktionen sein.
enforce_gtid_consistency Erzwingt die GTID-Konsistenz, indem die Ausführung nur der Anweisungen zugelassen wird, die auf transaktionssichere Weise protokolliert werden können. Dieser Wert muss vor dem Aktivieren der GTID-Replikation auf ON festgelegt werden. OFF* OFF: Alle Transaktionen können die GTID-Konsistenz verletzen.
ON: Keine Transaktion darf die GTID-Konsistenz verletzen.
WARN: Alle Transaktionen können gegen GTID-Konsistenz verstoßen, aber es wird eine Warnung generiert.

**Bei Instanzen von Azure Database for MySQL – Flexibler Server, bei denen das Feature „Hochverfügbarkeit“ aktiviert ist, ist der Standardwert auf ON festgelegt.

Hinweis

  • Wenn GTID aktiviert ist, können Sie ihn nicht wieder deaktivieren. Wenn Sie GTID deaktivieren müssen, wenden Sie sich an den Support.
  • Sie können GTIDs nur schrittweise in aufsteigender Reihenfolge der Modi von einem Wert zum anderen ändern. Wenn z. B. gtid_mode derzeit auf OFF_PERMISSIVE festgelegt ist, ist eine Änderung in ON_PERMISSIVE möglich, aber nicht in ON.
  • Um die Replikation konsistent zu halten, können Sie die Einstellung für einen Master-/Replikatserver nicht aktualisieren.
  • Es wird empfohlen, enforce_gtid_consistency auf ON festzulegen, bevor Sie gtid_mode=ON festlegen.

Um GTID zu aktivieren und das Konsistenzverhalten zu konfigurieren, aktualisieren Sie die Serverparameter gtid_mode und enforce_gtid_consistency mithilfe der Anleitungen unter Konfigurieren von Serverparametern in Azure Database for MySQL – Flexibler Server mithilfe des Azure-Portals oder Konfigurieren von Serverparametern in Azure Database for MySQL – Flexibler Server mithilfe der Azure CLI.

Wenn GTID auf einem Quellserver aktiviert ist (gtid_mode = ON), wird für neu erstellte Replikate GTID ebenfalls aktiviert und die GTID-Replikation verwendet. Um sicherzustellen, dass die Replikation konsistent ist, kann gtid_mode nicht geändert werden, nachdem der Master- oder der/die Replikatserver mit aktivierter GTID erstellt wurden.

Überlegungen und Einschränkungen

Szenario Einschränkung/Überlegung
Replikat auf Server im Tarif „Burstfähig“ Nicht unterstützt
Preise Die Kosten für den Betrieb des Replikatservers richten sich nach der Region, in der der Replikatserver betrieben wird.
Quellserverneustart Wenn Sie ein Replikat für eine Quelle erstellen, die keine vorhandenen Replikate hat, startet die Quelle zunächst neu, um sich auf die Replikation vorzubereiten. Beachten Sie dies, und führen Sie diese Vorgänge nicht zu Spitzenzeiten durch.
Neue Replikate Ein Lesereplikat wird als neue Instanz von Azure Database for MySQL – Flexibler Server erstellt. Ein vorhandener Server kann nicht in ein Replikat umgewandelt werden. Es kann kein Replikat eines anderen Lesereplikats erstellt werden.
Replikatkonfiguration Ein Replikat wird mit der gleichen Serverkonfiguration wie der Quellserver erstellt. Nachdem ein Replikat erstellt wurde, können mehrere Einstellungen unabhängig vom Quellserver geändert werden: die Computegeneration, die virtuellen Kerne, der Speicher und der Aufbewahrungszeitraum für Sicherungen. Die Computeebene kann auch unabhängig geändert werden.

WICHTIG – Bevor die Konfiguration eines Quellservers mit neuen Werten aktualisiert wird, sollte die Konfiguration des Replikats auf gleiche oder höhere Werte aktualisiert werden. Durch diese Aktion wird sichergestellt, dass das Replikat mit allen Änderungen, die auf dem Quellserver durchgeführt werden, Schritt halten kann.
Konnektivitätsmethode und Parametereinstellungen werden beim Erstellen eines Replikats vom Quellserver geerbt. Danach sind die Regeln des Replikats unabhängig.
Beendete Replikate Wenn Sie die Replikation zwischen einem Quellserver und einem Lesereplikat beenden, wird das beendete Replikat zu einem eigenständigen Server, der sowohl Lese- als auch Schreibzugriffe akzeptiert. Der eigenständige Server kann nicht wieder in ein Replikat umgewandelt werden.
Gelöschte Quellserver und eigenständige Server Wenn ein Quellserver gelöscht wird, wird die Replikation an alle Lesereplikate beendet. Diese Replikate werden automatisch zu eigenständigen Servern und können sowohl Lese- als auch Schreibvorgänge akzeptieren. Der Quellserver selbst wird gelöscht.
Benutzerkonten Benutzer auf dem Quellserver werden an die Lesereplikate repliziert. Sie können nur mit denjenigen Benutzerkonten eine Verbindung mit einem Lesereplikat herstellen, die auf dem Quellserver verfügbar sind.
Serverparameter Um zu verhindern, dass Daten nicht synchronisiert werden und um einen möglichen Datenverlust oder eine Beschädigung zu vermeiden, sind einige Serverparameter bei der Verwendung von Lesereplikaten für die Aktualisierung gesperrt.
Die folgenden Serverparameter sind sowohl auf dem Quell- als auch auf dem Replikatserver gesperrt:
- innodb_file_per_table
- log_bin_trust_function_creators
Der Parameter event_scheduler ist auf den Replikatservern gesperrt.
Um einen der oben genannten Parameter auf dem Quellserver zu aktualisieren, löschen Sie Replikatserver, aktualisieren Sie den Parameterwert für die Quelle, und erstellen Sie Replikate neu.
Parameter auf Sitzungsebene Beim Konfigurieren von Parametern auf Sitzungsebene wie beispielsweise „foreign_keys_checks“ für das Lesereplikat müssen Sie sicherstellen, dass die für das Lesereplikat festgelegten Parameterwerte mit denen des Quellservers übereinstimmen.
Hinzufügen der Primärschlüsselspalte AUTO_INCREMENT zur vorhandenen Tabelle auf dem Quellserver Es wird nicht empfohlen, die Tabelle nach der Lesereplikaterstellung mit AUTO_INCREMENT zu ändern, da dies die Replikation unterbricht. Wenn Sie jedoch die Autoinkrement-Spalte nach der Erstellung eines Replikatservers hinzufügen möchten, empfehlen wir diese beiden Ansätze:
- Erstellen Sie eine neue Tabelle mit demselben Schema der Tabelle, die Sie ändern möchten. Ändern Sie in der neuen Tabelle die Spalte mit AUTO_INCREMENT, und stellen Sie dann die Daten aus der ursprünglichen Tabelle wieder her. Trennen Sie die alte Tabelle, und benennen Sie diese in der Quelle um. Dazu müssen wir den Replikatserver nicht löschen, aber es können hohe Einfügekosten für die Erstellung der Sicherungstabelle anfallen.
- Die andere schnellere Methode besteht darin, das Replikat neu zu erstellen, nachdem alle AUTO_INCREMENT-Spalten hinzugefügt wurden.
Sonstige – Die Erstellung eines Replikats eines Replikats wird nicht unterstützt.
– In-Memory-Tabellen können dazu führen, dass Replikate nicht mehr synchron sind. Dies ist eine Einschränkung der MySQL-Replikationstechnologie. Weitere Informationen finden Sie in der MySQL-Referenzdokumentation.
– Stellen Sie sicher, dass die Quellservertabellen über Primärschlüssel verfügen. Das Fehlen von Primärschlüsseln kann zu Replikationswartezeit zwischen der Quelle und den Replikaten führen.
– Eine vollständige Liste aller Einschränkungen der MySQL-Replikation finden Sie in der MySQL-Dokumentation.

Zugehöriger Inhalt