Freigeben über

Lesen von Replikaten in der Azure-Datenbank für MySQL

MySQL ist eine der beliebtesten Datenbank-Engines für die Ausführung von Web- und mobilen Anwendungen im Internet. Viele Kunden verwenden Azure Database für MySQL für eine breite Palette von Anwendungen, darunter Online-Bildungseinrichtungen, Videostreaming, digitale Zahlungen, E-Commerce, Spiele, Nachrichtenportale, Behörden und Gesundheitswebsites. Diese Dienste müssen in der Lage sein, den Datenverkehr im Web oder in der mobilen Anwendung zu erhöhen und zu skalieren.

Auf der Anwendungsseite verwenden Entwickler in der Regel Java oder PHP. Sie migrieren die Anwendung zur Ausführung auf Azure Virtual Machine Scale Sets, Azure App Services oder containerisieren sie, um sie auf Azure Kubernetes Service (AKS) auszuführen. Mit dem Skalierungssatz für virtuelle Computer, app Service oder AKS als zugrunde liegende Infrastruktur wird die Anwendungsskalierung vereinfacht, indem neue VMs sofort bereitgestellt und die zustandslosen Komponenten von Anwendungen repliziert werden, um die Anforderungen zu erfüllen. Die Datenbank wird jedoch häufig zu einem Engpass als zentrale zustandsbehaftete Komponente.

Mit dem Feature "Replikat lesen" können Sie Daten aus einer Azure-Datenbank für MySQL Flexible Server-Instanz auf einen schreibgeschützten Server replizieren. Sie können vom Quellserver auf bis zu 10 Replikate replizieren. Replikate werden asynchron mithilfe der systemeigenen Binärprotokoll-Technologie des MySQL-Moduls (Binlog)-Dateipositionsbasierte Replikationstechnologie aktualisiert. Weitere Informationen zur binlog-Replikation finden Sie unter Übersicht über die binlog-Replikation in MySQL.

Sie verwalten Replikate als neue Server, genau wie Ihre Azure-Quelldatenbank für Flexible Server-Instanzen von MySQL. Es entstehen Abrechnungsgebühren für jedes Lesereplikat basierend auf der bereitgestellten Berechnung in vCores und Speicher in GB pro Monat. Weitere Informationen finden Sie unter Preise.

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. Wenn wir den Begriff aus der Software entfernen, entfernen wir ihn aus diesem Artikel.

Allgemeine Anwendungsfälle für Lesereplikate

Mit dem Feature "Replikat lesen" können Sie die Leistung und den Umfang der leseintensiven Workloads verbessern. Sie können Leseworkloads für die Replikate isolieren, während Sie Arbeitslasten an die Quelle weiterleiten.

Zu den häufigen Szenarios gehören:

  • Skalieren von Lesearbeitslasten, die von der Anwendung stammen, mithilfe eines einfachen Verbindungsproxys wie ProxySQL oder mithilfe eines mikroservicesbasierten Musters, um Ihre Leseabfragen zu skalieren, die von der Anwendung stammen, um Replikate zu lesen
  • Verwenden von Lesereplikaten als Datenquelle für BI- oder analytische Berichtsarbeitslasten
  • Erfassen von Telemetrieinformationen in das MySQL-Datenbankmodul bei Verwendung mehrerer Lesereplikate zum Melden von Daten in IoT- oder Fertigungsszenarien

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. Mit Azure Database for MySQL Flexible Server können Sie ein Lesereplikat in allen von Azure unterstützten Regionen bereitstellen, in denen Azure-Datenbank für MySQL Flexible 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 die Azure-Datenbank für MySQL Flexible Server heute verfügbar ist.

Erstellen eines Replikats

Wenn Sie den Workflow zum Erstellen eines Replikats starten, erstellen Sie eine leere Azure-Datenbank für mySQL Flexible Server-Instanz. Der neue Server enthält die Daten, die sich auf dem Quellserver befanden. 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

Sie erstellen Lesereplikate mit derselben Serverkonfiguration wie die Quelle. Sie können die Replikatserverkonfiguration nach der Erstellung ändern. Sie erstellen den Replikatserver immer in derselben Ressourcengruppe und einem Abonnement wie der Quellserver. Wenn Sie einen Replikatserver in einer anderen Ressourcengruppe oder einem anderen Abonnement erstellen möchten, können Sie den Replikatserver nach der Erstellung verschieben . Behalten Sie die Konfiguration des Replikatservers unter gleichen oder höheren Werten als die Quelle bei, um sicherzustellen, dass das Replikat mit der Quelle schritthalten kann.

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

Herstellen einer Verbindung mit einem Replikat

Wenn Sie ein Replikat erstellen, erbt es die Konnektivitätsmethode des Quellservers. Sie können die Konnektivitätsmethode des Replikats nicht ändern. Wenn der Quellserver beispielsweise den privaten Zugriff (VNet-Integration) verwendet, kann das Replikat keinen öffentlichen Zugriff (zulässige IP-Adressen) verwenden.

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

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 mit dem Namen "myreplica " mit dem Administratorbenutzernamen "myadmin" können Sie mithilfe der MySQL CLI eine Verbindung mit dem Replikat herstellen:

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. Azure Monitor berechnet diese Metrik mithilfe der seconds_behind_master Metrik im Befehl von MySQL SHOW SLAVE STATUS . Legen Sie eine Benachrichtigung fest, um Sie zu benachrichtigen, wenn die Replikationsverzögerung einen inakzeptablen Schwellenwert für Ihre Workload überschreitet.

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

Lesereplikat verwendet speicherbasierte Replikationstechnologie, die die metrik, die SLAVE_IO_RUNNING/REPLICA_IO_RUNNING im Befehl von MySQL SHOW SLAVESTATUS'/'SHOWREPLICA STATUS verfügbar ist, nicht mehr verwendet. Dieser Wert wird immer als "Nein" angezeigt und steht nicht für den Replikationsstatus. Informationen zum richtigen Replikationsstatus finden Sie unter "Replikationsstatus" und "SQL-Status des ReplikatsIO" auf der Seite "Überwachung".

Beenden der Replikation

Sie können die Replikation zwischen einem Quellserver und einem Replikatserver beenden. Wenn Sie die Replikation zwischen einem Quellserver und einem Lesereplikat beenden, wird der Replikatserver zu einem eigenständigen Server. Der eigenständige Server enthält die Daten, die beim Starten des Befehls "Replikation beenden" auf dem Replikatserver verfügbar waren. Der eigenständige Server synchronisiert keine fehlenden Daten vom Quellserver.

Wenn Sie die Replikation auf einem Replikatserver beenden, verliert der Replikatserver alle Verknüpfungen zu seinem vorherigen Quellserver und anderen Replikatservern. Es gibt kein automatisiertes Failover zwischen einem Quellserver und seinen Replikatservern.

Wichtig

Sie können den eigenständigen Server nicht wieder in einen Replikatserver konvertieren. Bevor Sie die Replikation für ein Lesereplikat beenden, stellen Sie sicher, dass der Replikatserver über alle benötigten Daten verfügt.

Weitere Informationen finden Sie unter Beenden der Replikation zu einem Replikat.

Ausfall

Zwischen Quell- und Replikatservern erfolgt kein automatisiertes Failover.

Lesereplikate skalieren leseintensive Workloads und bieten keine hohe Verfügbarkeit für einen Server. Sie führen manuelles Failover aus, indem Sie die Replikation für ein Lesereplikat beenden, indem Sie sie im Lese-/Schreibmodus online schalten.

Da die Replikation asynchron ist, liegt ein Verzögerung zwischen der Quelle und dem Replikat vor. Viele Faktoren beeinflussen die Verzögerung, z. B. die Arbeitsauslastung auf dem Quellserver und die Latenz zwischen Rechenzentren. In den meisten Fällen liegt der Replikatabstand zwischen einigen Sekunden und einigen Minuten. Sie können die tatsächliche Replikationsverzögerung nachverfolgen, indem Sie die Metrik " Replikatabstand " verwenden, 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 den Zeitabstand ihres Replikats 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 das Replikat nicht aufrufen, gibt die Verzögerung beim Aufheben der Verknüpfung des Replikats aus der Quelle an, wie viele Daten verloren gehen.

Nachdem Sie sich entschieden haben, ein Replikat nicht mehr zu verwenden:

  1. Beenden der Replikation auf das Replikat

    Sie müssen die Replikation beenden, damit der Replikatserver Schreibvorgänge akzeptieren kann. Bei diesem Vorgang wird die Verknüpfung des Replikatservers von der Quelle entfernt. Nach dem Initiieren der Replikation dauert der Back-End-Prozess in der Regel etwa zwei Minuten, bis die Replikation abgeschlossen ist. 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 Ihre Anwendung Lese- und Schreibvorgänge erfolgreich verarbeitet, schließen Sie das Failover ab. Die Anzahl der Ausfallzeiten, die Ihre Anwendungserfahrungen verursachen, hängt davon ab, wann Sie ein Problem erkennen und die Schritte 1 und 2 ausführen.

Globaler Transaktionsbezeichner (GTID)

Eine globale Transaktions-ID (GTID) ist ein eindeutiger Bezeichner, den der Quellserver mit jeder zugesicherten Transaktion erstellt. Azure Database for MySQL Flexible Server deaktiviert standardmäßig GTID. Die Versionen 5.7 und 8.0 unterstützen GTID. Weitere Informationen zu GTID und deren Verwendung der Replikation finden Sie in der Dokumentation zur Replikation von MySQL mit GTID .

Verwenden Sie die folgenden Serverparameter, um GTID zu konfigurieren:

Serverparameter Beschreibung Standardwert Werte
gtid_mode Gibt an, ob GTIDs zur Identifizierung von Transaktionen verwendet werden. Änderungen zwischen Modi können nur jeweils einen Schritt in aufsteigender Reihenfolge (z. B. OFF -OFF_PERMISSIVE> ->ON_PERMISSIVE ->ON) ausgeführt werden. 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. Legen Sie den Wert ON fest, bevor Sie die GTID-Replikation aktivieren. OFF* OFF: Alle Transaktionen dürfen die GTID-Konsistenz verletzen.
ON: Keine Transaktion darf die GTID-Konsistenz verletzen.
WARN: Alle Transaktionen dürfen gegen GTID-Konsistenz verstoßen, aber es wird eine Warnung generiert.

Hinweis

Für Azure-Datenbank für MySQL Flexible Server-Instanzen, für die das Feature "Hohe Verfügbarkeit" aktiviert ist, wird der Standardwert auf <a0/> festgelegt.

Nachdem Sie GTID aktiviert haben, können Sie sie nicht mehr 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 sie z. B. zurzeit auf festgelegt OFF_PERMISSIVEist, können Sie sie ON_PERMISSIVE in gtid_mode ", aber nicht in " ONändern.

Um die Replikation konsistent zu halten, können Sie sie nicht für einen primären oder Replikatserver aktualisieren.

Festlegen enforce_gtid_consistency auf ON vor der Einstellung gtid_mode auf ON.

Aktualisieren Sie die gtid_mode Parameter und enforce_gtid_consistency Serverparameter, um GTID zu aktivieren und das Konsistenzverhalten zu konfigurieren. Verwenden Sie "Konfigurieren von Serverparametern" in der Azure-Datenbank für MySQL – Flexibler Server mithilfe des Azure-Portals oder Konfigurieren von Serverparametern in Azure-Datenbank für MySQL – Flexibler Server mithilfe der Azure CLI.

Wenn ein Quellserver GTID (gtid_mode = ON) aktiviert, aktivieren neu erstellte Replikate auch GTID und verwenden die GTID-Replikation. Um die Replikationskonsistenz sicherzustellen, können Sie sich nach dem Erstellen von primären oder Replikatservern mit aktivierter GTID nicht ändern gtid_mode .

Überlegungen und Einschränkungen

Szenario Einschränkung/Überlegung
Replikat auf Server im Tarif „Burstfähig“ Nicht unterstützt
Preise Die Kosten für die Ausführung des Replikatservers hängen von der Region ab, in der der Replikatserver ausgeführt wird.
Ausfall/Neustart des Quellservers Beim Erstellen eines Lesereplikats ist kein Neustart oder Ausfallzeit erforderlich. Dieser Vorgang ist ein Onlinevorgang.
Neue Replikate Sie erstellen ein Lesereplikat als neue Azure-Datenbank für mySQL Flexible Server-Instanz. Sie können keinen vorhandenen Server in ein Replikat umwandeln. Es kann kein Replikat eines anderen Lesereplikats erstellt werden.
Replikatkonfiguration Sie erstellen ein Replikat mithilfe derselben Serverkonfiguration wie die Quelle. Nachdem Sie ein Replikat erstellt haben, können Sie mehrere Einstellungen unabhängig vom Quellserver ändern: Berechnungsgenerierung, vCores, Speicher und Sicherungsaufbewahrungszeitraum. Sie können die Computeebene auch unabhängig voneinander ändern.

WICHTIG : Bevor Sie eine Quellserverkonfiguration auf neue Werte aktualisieren, aktualisieren Sie die Replikatkonfiguration auf gleiche oder höhere Werte. Durch diese Aktion wird sichergestellt, dass das Replikat mit allen Änderungen, die auf dem Quellserver erfolgen, Schritt halten kann.
Verbindungsmethoden- und Parametereinstellungen werden beim Erstellen des Replikats vom Quellserver an das Replikat 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. Sie können den eigenständigen Server nicht erneut zu einem Replikat machen.
Gelöschte Quellserver Wenn Sie einen Quellserver löschen, stoppt die Replikation für alle gelesenen Replikate. 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 eine Verbindung mit einem Lesereplikat herstellen, indem Sie die auf dem Quellserver verfügbaren Benutzerkonten verwenden.
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 vorherigen 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 Stellen Sie beim Konfigurieren von Parametern auf Sitzungsebene wie "foreign_keys_checks" für das Lesereplikat sicher, dass die Parameterwerte, die Sie für das Lesereplikat festlegen, mit denen des Quellservers konsistent sind.
Hinzufügen einer AUTO_INCREMENT Primärschlüsselspalte zur vorhandenen Tabelle auf dem Quellserver Es wird nicht empfohlen, die Tabelle AUTO_INCREMENT nach dem Erstellen eines Lesereplikats zu ändern, da die Replikation durch diese Aktion unterbrochen wird. Wenn Sie nach dem Erstellen eines Replikatservers eine Automatische Inkrementspalte hinzufügen möchten, sollten Sie die folgenden Ansätze in Betracht ziehen:
– Erstellen Sie eine neue Tabelle mit demselben Schema wie die 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. Legen Sie die alte Tabelle ab, und benennen Sie sie in der Quelle um; Für diesen Ansatz ist kein Löschen des Replikatservers erforderlich, es kann jedoch zu großen Einfügekosten führen, um eine Sicherungstabelle zu erstellen.
– Erstellen Sie das Replikat nach dem Hinzufügen aller automatischen Inkrementspalten neu.
Andere – Die Erstellung eines Replikats eines Replikats wird nicht unterstützt.
- Speichertabellen können dazu führen, dass Replikate nicht mehr synchronisiert werden. Diese Einschränkung ist auf die MySQL-Replikationstechnologie zurückzuführen. 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.
- Überprüfen Sie die vollständige Liste der MySQL-Replikationseinschränkungen in der MySQL-Dokumentation.

Verwandte Inhalte

  • Last updated on