Replizieren von Daten in Azure Database for MySQL: Flexible Server

  • Artikel

GILT FÜR: Azure Database for MySQL – Flexible Server

Mit der Datenreplikation können Sie Daten von einem externen MySQL-Server mit einer flexiblen Azure-Serverinstanz für MySQL synchronisieren. Der externe Server kann lokal, in VMs, in Azure Database for MySQL-Einzelserver oder in einem von anderen Cloudanbietern gehosteten Datenbankdienst vorhanden sein. Die Replikation eingehender Daten basiert auf der Position der Binärprotokoll (binlog)-Datei oder der GTID-basierten Replikation. Weitere Informationen zur binlog-Replikation finden Sie unter MySQL-Replikation.

Hinweis

Das Konfigurieren der Data-In-Replikation für Server, die mit hoher Verfügbarkeit aktiviert sind, wird nur über die GTID-basierte Replikation unterstützt.

Szenarien für die Verwendung der Datenreplikation

Zu den wichtigsten Szenarien, bei denen die Verwendung der Datenreplikation infrage kommt, zählen Folgende:

  • Hybride Datensynchronisierung hronisierung: Mit der Data-In-Replikation können Sie Daten zwischen Ihren lokalen Servern und azure Database für mySQL flexiblen Server synchronisieren. Diese Synchronisierung hilft beim Erstellen von hybriden Anwendungen. Diese Methode ist optimal geeignet, wenn Sie über einen lokalen Datenbankserver verfügen, die Daten jedoch in eine Region verschieben möchten, die sich näher bei den Endbenutzern befindet.
  • Multi-Cloud-Synchronisierung: Verwenden Sie für komplexe Cloudlösungen die Datenreplikation, um Daten zwischen Azure-Datenbank für MySQL flexiblen Server und verschiedenen Cloudanbietern zu synchronisieren, einschließlich virtueller Computer und Datenbankdienste, die in diesen Clouds gehostet werden.
  • Migration: Kunden können mit minimalem Zeitaufwand mithilfe von Open-Source-Tools wie MyDumper/MyLoader mit der Replikation eingehender Daten migrieren. Eine selektive Übernahme der Produktionslast von der Quell- zur Zieldatenbank ist mit der Datenreplikation möglich.

Verwenden Sie bei Migrationsszenarien den Azure Database Migration Service(DMS).

Einschränkungen und Aspekte

Nicht replizierte Daten

Die Systemdatenbank „mysql“ auf dem Quellserver wird nicht repliziert. Außerdem werden Änderungen an Konten und Berechtigungen auf dem Quellserver nicht repliziert. Wenn Sie ein Konto auf dem Quellserver erstellen und dieses Konto Zugriff auf den Replikatserver erfordert, erstellen Sie dasselbe Konto manuell auf dem Replikatserver. Einen Überblick über die Tabellen in der Systemdatenbank finden Sie im Leitfaden zu MySQL.

Die Replikation eingehender Daten wird auf Servern mit aktivierter Hochverfügbarkeit (High Availability, HA) unterstützt

Der Support für die Replikation eingehender Daten für Hochverfügbarkeits (HA)-fähige Server ist nur über die GTID-basierte Replikation verfügbar.

Die gespeicherte Prozedur für die Replikation mit GTID ist auf allen HA-fähigen Servern unter dem Namen mysql.az_replication_change_master_with_gtidverfügbar.

Filtern

Der Parameter replicate_wild_ignore_table erstellt einen Replikationsfilter für Tabellen auf dem Replikatserver. Um diesen Parameter aus dem Azure-Portal zu ändern, navigieren Sie zur azure-Datenbank für mySQL flexible Serverinstanz, die als Replikat verwendet wird, und wählen Sie "Serverparameter" aus, um den replicate_wild_ignore_table Parameter anzuzeigen/zu bearbeiten.

Requirements (Anforderungen)

  • Der Quellserver muss mindestens die MySQL-Version 5.7 aufweisen.
  • Es wird empfohlen, dass der Quellserver und der Replikatserver dieselbe Version aufweisen. Beispielsweise müssen beide die Version MySQL 5.7 oder beide die Version MySQL 8.0 aufweisen.
  • Es wird empfohlen, dass in jeder Tabelle ein Primärschlüssel vorhanden ist. Wenn wir eine Tabelle ohne Primärschlüssel haben, kann sich die Replikation verlangsamen.
  • Der Quellserver sollte die MySQL InnoDB-Engine verwenden.
  • Der Benutzer muss über die richtigen Berechtigungen zum Konfigurieren der binären Protokollierung und zum Erstellen neuer Benutzer auf dem Quellserver verfügen.
  • Binäre Protokolldateien auf dem Quellserver sollten nicht gelöscht werden, bevor das Replikat diese Änderungen angewandt hat. Wenn es sich bei der Quelle um die Azure-Datenbank für mySQL flexiblen Server handelt, erfahren Sie, wie Sie binlog_expire_logs_seconds für flexible Server oder Einzelserver konfigurieren.
  • Wenn für den Quellserver SSL aktiviert ist, vergewissern Sie sich, dass das für die Domäne bereitgestellte SSL-Zertifizierungsstellenzertifikat in die gespeicherte Prozedur mysql.az_replication_change_master eingefügt wurde. Sehen Sie sich die folgenden Beispiele und den Parameter master_ssl_ca an.
  • Vergewissern Sie sich, dass für den Computer, der den Quellserver hostet, sowohl ein- als auch ausgehender Datenverkehr am Port 3306 zugelassen wird.
  • Stellen Sie bei öffentlichem Zugriff sicher, dass der Quellserver eine öffentliche IP-Adresse hat, DNS öffentlich zugänglich ist oder der Quellserver über einen vollqualifizierten Domänenname (FQDN) verfügt.
  • Stellen Sie mit privatem Zugriff sicher, dass der Quellservername aufgelöst werden kann und über das VNet zugänglich ist, auf das die Azure-Datenbank für MySQL flexible Serverinstanz ausgeführt wird. (Weitere Informationen finden Sie unter Namensauflösung für Ressourcen in virtuellen Azure-Netzwerken.)

Generierter unsichtbarer Primärschlüssel

Für MySQL Version 8.0 und höher ist "Generated Invisible Primary Keys(GIPK)" standardmäßig für alle flexiblen Serverinstanzen der Azure-Datenbank für MySQL aktiviert. MySQL 8.0+-Server fügt die unsichtbare Spalte my_row_id zu den Tabellen und einen Primärschlüssel für diese Spalte hinzu, in der die InnoDB-Tabelle ohne expliziten Primärschlüssel erstellt wird. Wenn diese Funktion aktiviert ist, kann sich dies auf einige Anwendungsfälle für die Datenreplikation auswirken, wie unten beschrieben:

  • Die Datenreplikation schlägt mit dem Replikationsfehler „FEHLER 1068 (42000): Mehrere Primärschlüssel definiert“ fehl, wenn der Quellserver einen Primärschlüssel für die Tabelle ohne Primärschlüssel erstellt. Führen Sie zur Entschärfung den folgenden SQL-Befehl aus, überspringen Sie den Replikationsfehler, und starten Sie die Datenreplikation neu.

    alter table <table name> drop column my_row_id, add primary key <primary key name>(<column name>);

  • Fehler bei der Datenreplikation mit Replikationsfehler: „FEHLER 1075 (42000): Falsche Tabellendefinition; es kann nur eine automatische Spalte geben, und sie muss als Schlüssel definiert sein“, wenn der Quellserver eine auto_increment-Spalte als eindeutigen Schlüssel hinzufügt. Führen Sie zur Entschärfung den folgenden SQL-Befehl aus, legen Sie „sql_generate_invisible_primary_key“ auf OFF fest, überspringen Sie den Replikationsfehler, und starten Sie die Datenreplikation neu.

    alter table <table name> drop column my_row_id, modify <column name> int auto_increment;

  • Die Datenreplikation schlägt fehl, wenn der Quellserver eine andere SQL-Instanz ausführt, die nicht unterstützt wird, wenn „sql_generate_invisible_primary_key“ auf ON festgelegt ist. Erstellen Sie beispielsweise eine Partitionstabelle. In einem solchen Szenario besteht die Entschärfung darin, „sql_generate_invisible_primary_key“ auf OFF festzulegen und die Datenreplikation neu zu starten.

Nächste Schritte