Replizieren von Daten in Azure Database for MySQL: Flexible Server

  • Artikel

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

Die Replikation eingehender Daten ermöglicht das Synchronisieren von Daten von einem externen MySQL-Server in eine Instanz von Azure Database for MySQL Flexibler Server. 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 Replikation eingehender Daten für Server, die für Hochverfü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:

  • Synchronisierung von Hybriddaten: Mit der Datenreplikation können Sie Daten zwischen Ihren lokalen Servern und Azure Database for MySQL Flexible Server synchron halten. 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.
  • Synchronisierung von Daten in verschiedenen Clouds: Verwenden Sie bei komplexen Cloudlösungen die Datenreplikation, um Daten zwischen Azure Database for MySQL Flexible Server und unterschiedlichen 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 über das Azure-Portal zu ändern, navigieren Sie zu der als Replikat verwendeten Instanz von Azure Database for MySQL Flexibler Server, und wählen Sie „Serverparameter“ aus, um den-Parameter replicate_wild_ignore_table 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 die Quelle Azure Database for MySQL Flexibler Server ist, finden Sie weitere Informationen zum Konfigurieren von „binlog_expire_logs_seconds“ unter Flexibler Server oder Einzelserver.

  • 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. Wenn Sie über einen privaten Endpunkt verfügen und den öffentlichen Zugriff deaktiviert haben, wird die Datenreplikation nicht unterstützt.

  • Stellen Sie bei privatem Zugriff (VNet-Integration) sicher, dass der Name des Quellservers aufgelöst werden kann und über das virtuelle Netzwerk (VNet) zugänglich ist, in dem die Azure Database for MySQL Flexibler Server-Instanz 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 sind generierte unsichtbare Primärschlüssel (Generated Invisible Primary Keys, GIPK) standardmäßig für alle Instanzen von Azure Database for MySQL Flexibler Server 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