Konfigurieren der Replikation für eingehende Daten in Azure Database for MySQL – Flexibler Server

In diesem Artikel wird beschrieben, wie Daten in Azure Database for MySQL – Flexibler Server replizieren in Azure Database for MySQL – Flexibler Server einrichten, indem Sie die Quell- und Replikatserver konfigurieren. In diesem Artikel wird davon ausgegangen, dass Sie über ein gewisses Maß an Erfahrung mit MySQL-Servern und -Datenbanken verfügen.

Um ein Replikat in der Instanz von Azure Database for MySQL – Flexibler Server zu erstellen, synchronisiert Daten in Azure Database for MySQL – Flexibler Server replizieren Daten von einem lokalen MySQL-Quellserver, in virtuellen Computern (VMs) oder in Cloud-Datenbankdiensten. Die Replikation eingehender Daten kann entweder mit der positionsbasierten Replikation von Binärprotokolldateien (binlog) ODER der GTID-basierten Replikation konfiguriert werden. Weitere Informationen zur binlog-Replikation finden Sie unter MySQL-Replikation.

Überprüfen Sie die Einschränkungen und Anforderungen der Datenreplikation, bevor Sie die Schritte in diesem Artikel ausführen.

Erstellen Sie eine Azure Database for MySQL Flexible Server-Instanz, die als Replikat verwendet werden soll.

1. Erstellen Sie eine neue Instanz von Azure Database for MySQL Flexible Server (z. B. replica.mysql.database.azure.com). Informationen zur Servererstellung finden Sie unter Schnellstart: Erstellen einer Instanz von Azure Database for MySQL mit dem Azure-Portal. Dieser Server ist der Replikatserver für die Datenreplikation.

2. Erstellen Sie dieselben Benutzerkonten und entsprechenden Berechtigungen.

   Benutzerkonten werden nicht vom Quellserver auf den Replikatserver repliziert. Wenn Sie Benutzern den Zugriff auf den Replikatserver gewähren möchten, müssen Sie alle Konten und entsprechenden Berechtigungen für diese neu erstellte Instanz von Azure Database for MySQL – Flexibler Server manuell erstellen.

Konfigurieren des MySQL-Quellservers

Mit den folgenden Schritten wird der MySQL-Server, der lokal, auf einem virtuellen Computer oder von einem von anderen Cloudanbietern gehosteten Datenbankdienst gehostet wird, für die Datenreplikation vorbereitet und konfiguriert. Dieser Server ist die „Quelle“ bei der Datenreplikation.

1. Überprüfen Sie die Anforderungen für den Quellserver, bevor Sie fortfahren.

2. Netzwerkanforderungen

   • Stellen Sie sicher, dass der Quellserver sowohl eingehenden als auch ausgehenden Datenverkehr an Port 3306 zulässt und über eine öffentliche IP-Adresse verfügt, und dass der DNS öffentlich zugänglich ist, oder über einen vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) verfügt.

   • Wenn privater Zugriff (VNet-Integration) verwendet wird, stellen Sie sicher, dass Konnektivität zwischen dem Quellserver und dem VNet besteht, in dem der Replikatserver gehostet wird.

   • Stellen Sie Site-to-Site-Konnektivität zu Ihren lokalen Quellservern sicher, indem Sie entweder ExpressRoute oder VPN verwenden. Weitere Informationen zum Erstellen eines virtuellen Netzwerks finden Sie in der Dokumentation zu Virtual Network und insbesondere in den Schnellstartartikeln mit Schritt-für-Schritt-Anleitungen.

   • Wenn privater Zugriff (VNet-Integration) auf dem Replikatserver verwendet wird und Ihre Quelle Azure-VM ist, stellen Sie sicher, dass die VNet-zu-VNet-Konnektivität hergestellt ist. VNet-Peering wird unterstützt. Sie können auch andere Konnektivitätsmethoden (etwa eine Verbindung zwischen VNets) verwenden, um die regionsübergreifende Kommunikation zwischen VNets zu ermöglichen. Weitere Informationen finden Sie unter Konfigurieren einer VNET-zu-VNET-VPN-Gatewayverbindung über das Azure-Portal.

   • Vergewissern Sie sich, dass die Netzwerksicherheitsgruppen-Regeln Ihres virtuellen Netzwerks den ausgehenden Port 3306 nicht blockieren (auch nicht in eingehender Richtung, wenn MySQL auf einem virtuellen Azure-Computer ausgeführt wird). Ausführlichere Informationen zur NSG-Datenverkehrsfilterung in einem virtuellen Netzwerk finden Sie im Artikel Filtern des Netzwerkdatenverkehrs mit Netzwerksicherheitsgruppen.

   • Konfigurieren Sie die Firewallregeln Ihres Quellservers so, dass die IP-Adresse des Replikatservers zulässig ist.

3. Führen Sie die entsprechenden Schritte aus, je nachdem, ob Sie die auf Binärprotokollposition oder auf GTID basierte Replikation eingehender verwenden möchten.

   • Auf Binärprotokollposition basierte Replikation
   • Auf GTID basierte Replikation

   Überprüfen Sie, ob die binäre Protokollierung auf der Quelle aktiviert wurde, indem Sie den folgenden Befehl ausführen:

   SHOW VARIABLES LIKE 'log_bin';
   

   Wenn die Variable log_bin mit dem Wert „ON“ zurückgegeben wird, ist die binäre Protokollierung auf Ihrem Server aktiviert.

   Wenn log_bin mit dem Wert „OFF“ zurückgegeben und der Quellserver lokal oder auf virtuellen Computern ausgeführt wird, wo Sie auf die Konfigurationsdatei (my.cnf) zugreifen können, können Sie die folgenden Schritte ausführen:

   1. Suchen Sie Ihre MySQL-Konfigurationsdatei („my.cnf“) auf dem Quellserver. (Zum Beispiel: „/etc/my.cnf“)

   2. Öffnen Sie die Konfigurationsdatei, um sie zu bearbeiten und in der Datei nach dem Abschnitt mysqld zu suchen.

   3. Fügen Sie die folgende Zeile im Abschnitt „mysqld“ hinzu:

      log-bin=mysql-bin.log
      

   4. Starten Sie den MySQL-Dienst auf dem Quellserver neu, damit die Änderungen wirksam werden.

   5. Stellen Sie nach dem Neustart des Servers sicher, dass die binäre Protokollierung aktiviert ist, indem Sie dieselbe Abfrage wie zuvor ausführen:

      SHOW VARIABLES LIKE 'log_bin';
      

4. Konfigurieren Sie die Quellservereinstellungen.

   Der Parameter lower_case_table_names muss bei der Datenreplikation zwischen Quell- und Replikatserver konsistent sein. Dieser Parameter ist bei Azure Database for MySQL Flexible Server standardmäßig „1“.

   SET GLOBAL lower_case_table_names = 1;
   

5. Erstellen Sie eine neue Replikationsrolle, und richten Sie Berechtigungen ein.

   Erstellen Sie auf dem Quellserver ein Benutzerkonto, das mit Replikationsberechtigungen konfiguriert ist. Das können Sie über SQL-Befehle oder ein Tool wie MySQL Workbench tun. Treffen Sie die Entscheidung, ob Sie eine Replikation mit SSL durchführen möchten, da dies bei der Erstellung des Benutzers angegeben werden muss. Wie Ihrem Quellserver Benutzerkonten hinzugefügt werden, erfahren Sie in der MySQL-Dokumentation.

   Bei Verwendung der folgenden Befehle kann die neu erstellte Replikationsrolle nicht nur vom Computer, auf dem die Quelle selbst gehostet wird, sondern von jedem Computer aus auf die Quelle zugreifen. Hierfür muss „syncuser@'%'“ im Befehl zum Erstellen von Benutzern angegeben werden. Weitere Informationen finden Sie in der MySQL-Dokumentation unter Specifying Account Names (Angeben von Kontonamen).

   • SQL-Befehl
   • MySQL Workbench

   Replikation mit SSL

   Um für alle Benutzerverbindungen SSL zu erzwingen, verwenden Sie den folgenden Befehl zum Erstellen eines Benutzers:

   CREATE USER 'syncuser'@'%' IDENTIFIED BY 'yourpassword';
   GRANT REPLICATION SLAVE ON *.* TO ' syncuser'@'%' REQUIRE SSL;
   

   Replikation ohne SSL

   Wenn SSL nicht für alle Verbindungen erforderlich ist, verwenden Sie den folgenden Befehl zum Erstellen eines Benutzers:

   CREATE USER 'syncuser'@'%' IDENTIFIED BY 'yourpassword';
   GRANT REPLICATION SLAVE ON *.* TO ' syncuser'@'%';
   

6. Versetzen Sie den Quellserver in den schreibgeschützten Modus.

   Bevor Sie mit dem Sichern der Datenbank beginnen, muss der Server in den schreibgeschützten Modus versetzt werden. Im schreibgeschützten Modus kann die Quelle keine Schreibtransaktionen verarbeiten. Werten Sie die Auswirkungen auf Ihr Unternehmen aus, und planen Sie das Fenster für den schreibgeschützten Modus bei Bedarf in der Nebenzeit.

   FLUSH TABLES WITH READ LOCK;
   SET GLOBAL read_only = ON;
   

7. Rufen Sie den Namen und das Offset der binären Protokolldatei ab.

   Führen Sie den Befehl show master status aus, um den aktuellen Namen und das Offset der binären Protokolldatei zu ermitteln.

   show master status;
   

   Die Ergebnisse sollten in etwa wie folgt aussehen. Notieren Sie sich unbedingt den Namen der Binärdatei für die nachfolgenden Schritte.

   

Sichern und Wiederherstellen des Quellservers

1. Legen Sie fest, welche Datenbanken und Tabellen in Azure Database for MySQL Flexible Server repliziert werden sollen, und führen Sie die Sicherung vom Quellserver aus.

   Mit „mysqldump“ können Sie Datenbanken von Ihrem primären Server sichern. Weitere Informationen finden Sie unter Migrieren der MySQL-Datenbank auf Azure-Datenbank für MySQL durch Sicherungen und Wiederherstellungen. Die MySQL-Bibliothek und die Testbibliothek müssen nicht gesichert werden.

2. Versetzen Sie den Quellserver in den Lese-/Schreibmodus.

   Versetzen Sie den MySQL-Quellserver nach dem Sichern der Datenbank wieder in den Lese-/Schreibmodus.

   SET GLOBAL read_only = OFF;
   UNLOCK TABLES;
   

   Hinweis

   Bevor der Server wieder in den Lese-/Schreibmodus versetzt wird, können Sie die GTID-Informationen mithilfe der globalen Variablen GTID_EXECUTED abrufen. Dies wird zu einem späteren Zeitpunkt verwendet, um die GTID auf dem Replikatserver festzulegen.

3. Stellen Sie die Sicherungsdatei auf dem neuen Server wieder her.

   Stellen Sie die Sicherungsdatei auf dem Server wieder her, der in Azure Database for MySQL – Flexibler Server erstellt wurde. Informationen zum Wiederherstellen einer Sicherungsdatei auf einem MySQL-Server finden Sie unter Migrieren der MySQL-Datenbank auf Azure-Datenbank für MySQL durch Sicherungen und Wiederherstellungen. Handelt es sich um eine große Sicherungsdatei, laden Sie sie auf einen virtuellen Computer in Azure in der gleichen Region wie Ihr Replikatserver hoch. Stellen Sie diese von der VM auf dem Server mit Azure Database for MySQL – Flexibler Server wieder her.

Festlegen der GTID auf dem Replikatserver

1. Überspringen des Schritts bei Verwendung der auf Binärprotokollposition basierten Replikation

2. GTID-Informationen aus der Speicherabbilddatei aus der Quelle sind erforderlich, um den GTID-Verlauf des Zielservers (Replikatserver) zurückzusetzen.

3. Verwenden Sie diese GTID-Informationen aus der Quelle, um die GTID-Zurücksetzung auf dem Replikatserver mit dem folgenden CLI-Befehl auszuführen:

   az mysql flexible-server gtid reset --resource-group  <resource group> --server-name <replica server name> --gtid-set <gtid set from the source server> --subscription <subscription id>
   

Weitere Informationen finden Sie unter GTID-Zurücksetzung.

Verknüpfen des Quell- und Replikatservers zum Starten der Datenreplikation

1. Legen Sie den Quellserver fest.

   Alle Datenreplikationsfunktionen werden von gespeicherten Prozeduren ausgeführt. Alle Prozeduren finden Sie unter Gespeicherte Prozeduren für die Azure Database for MySQL-Verwaltung. Die gespeicherten Prozeduren können in der MySQL-Shell oder in MySQL Workbench ausgeführt werden.

   Um zwei Server zu verknüpfen und die Replikation zu starten, melden Sie sich beim Zielreplikatserver im „Azure Database for MySQL“-Dienst an, und legen Sie die externe Instanz als Quellserver fest. Hierfür verwenden Sie die gespeicherte Prozedur mysql.az_replication_change_master oder mysql.az_replication_change_master_with_gtid auf dem Azure Database for MySQL-Server.

   CALL mysql.az_replication_change_master('<master_host>', '<master_user>', '<master_password>', <master_port>, '<master_log_file>', <master_log_pos>, '<master_ssl_ca>');
   

   CALL mysql.az_replication_change_master_with_gtid('<master_host>', '<master_user>', '<master_password>', <master_port>,'<master_ssl_ca>');
   

   • master_host: Hostname des Quellservers
   • master_user: Benutzername des Quellservers
   • master_password: Kennwort des Quellservers
   • master_port: Portnummer, auf der der Quellserver auf Verbindungen lauscht. (3306 ist der Standardport, an dem MySQL lauscht.)
   • master_log_file: Name der binären Protokolldatei durch Ausführung von show master status
   • master_log_pos: Position des binären Protokolls durch Ausführung von show master status
   • master_ssl_ca: Der Kontext des Zertifizierungsstellenzertifikats. Wenn SSL nicht verwendet wird, übergeben Sie eine leere Zeichenfolge.

   Es wird empfohlen, diesen Parameter als Variable zu übergeben. Weitere Informationen finden Sie in den folgenden Beispielen.

   Hinweis

   • Wenn der Quellserver auf einer Azure-VM gehostet wird, legen Sie „Zugriff auf Azure-Dienste erlauben“ auf „EIN“ fest, damit Quell- und Replikatserver miteinander kommunizieren können. Diese Einstellung kann über die Optionen für die Verbindungssicherheit geändert werden. Weitere Informationen finden Sie unter Verwalten von Firewallregeln für Azure Database for MySQL – flexibler Server mit Azure-Portal.
   • Wenn Sie „mydumper/myloader“ zum Sichern der Datenbank verwendet haben, können Sie „master_log_file“ und „master_log_pos“ aus der Datei /backup/metadata abrufen.

   Beispiele

   Replikation mit SSL

   Die Variable @cert wird durch Ausführung der folgenden MySQL-Befehle erstellt:

   SET @cert = '-----BEGIN CERTIFICATE-----
   PLACE YOUR PUBLIC KEY CERTIFICATE'`S CONTEXT HERE
   -----END CERTIFICATE-----'
   

   Eine Replikation mit SSL wird zwischen einem Quellserver, der in der Domäne companya.com gehostet wird, und einem Replikatserver eingerichtet, der in Azure Database for MySQL Flexible Server gehostet wird. Diese gespeicherte Prozedur wird auf dem Replikat ausgeführt.

   CALL mysql.az_replication_change_master('master.companya.com', 'syncuser', 'P@ssword!', 3306, 'mysql-bin.000002', 120, @cert);
   

   CALL mysql.az_replication_change_master_with_gtid('master.companya.com', 'syncuser', 'P@ssword!', 3306, @cert);
   

   Replikation ohne SSL

   Eine Replikation ohne SSL wird zwischen einem Quellserver, der in der Domäne companya.com gehostet wird, und einem Replikatserver eingerichtet, der in Azure Database for MySQL Flexible Server gehostet wird. Diese gespeicherte Prozedur wird auf dem Replikat ausgeführt.

   CALL mysql.az_replication_change_master('master.companya.com', 'syncuser', 'P@ssword!', 3306, 'mysql-bin.000002', 120, '');
   

   CALL mysql.az_replication_change_master_with_gtid('master.companya.com', 'syncuser', 'P@ssword!', 3306, '');
   

2. Starten Sie die Replikation.

   Rufen Sie die gespeicherte Prozedur mysql.az_replication_start auf, um die Replikation zu starten.

   CALL mysql.az_replication_start;
   

3. Überprüfen Sie den Replikationsstatus.

   Rufen Sie den Befehl show slave status auf dem Replikatserver auf, um den Replikationsstatus anzuzeigen.

   show slave status;
   

   Informationen zum richtigen Replikationsstatus finden Sie unter Replikationsmetriken – Replikat-E/A-Status und Replikat-SQL-Status auf der Seite „Überwachung“.

   Wenn Seconds_Behind_Master „0“ lautet, funktioniert die Replikation ordnungsgemäß. Seconds_Behind_Master gibt an, wie stark das Replikat verzögert ist. Wenn der Wert nicht „0“ ist, bedeutet dies, dass das Replikat Updates verarbeitet.

Andere nützliche gespeicherte Prozeduren für Datenreplikationsvorgänge

Beenden der Replikation

Um die Replikation zwischen dem Quell- und Replikatserver zu beenden, verwenden Sie die folgende gespeicherte Prozedur:

CALL mysql.az_replication_stop;

Entfernen der Replikationsbeziehung

Um die Replikationsbeziehung zwischen Quell- und Replikatserver zu entfernen, verwenden Sie die folgende gespeicherte Prozedur:

CALL mysql.az_replication_remove_master;

Überspringen des Replikationsfehlers

Um einen Replikationsfehler zu überspringen und die Fortsetzung der Replikation zuzulassen, verwenden Sie die folgende gespeicherte Prozedur:

CALL mysql.az_replication_skip_counter;

SHOW BINLOG EVENTS [IN 'log_name'] [FROM pos][LIMIT [offset,] row_count]

Nächster Schritt