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

  • Artikel

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

In diesem Artikel wird beschrieben, wie Sie die Data-In-Replikation in azure Database for MySQL flexiblen 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.

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.

Zum Erstellen eines Replikats in der Azure-Datenbank für die flexible Serverinstanz von MySQL synchronisiert die Data-In-Replikation Daten von einem lokalen Quellserver, auf virtuellen Computern (VMs) oder in Clouddatenbankdiensten. 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 einer Azure-Datenbank für eine flexible Serverinstanz für MySQL, die als Replikat verwendet werden soll

  1. Erstellen Sie eine neue Instanz von Azure Database für mySQL flexiblen Server (z. B replica.mysql.database.azure.com. ). Weitere Informationen finden Sie unter Erstellen einer Azure-Datenbank für mySQL flexible Serverinstanz mithilfe der Azure-Portal für die Servererstellung. 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 beabsichtigen, Benutzern Zugriff auf den Replikatserver zu gewähren, müssen Sie alle Konten und entsprechenden Berechtigungen manuell für diese neu erstellte Azure-Datenbank für mySQL flexible Serverinstanz 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 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 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.

    Ü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 standardmäßig 1 in der Azure-Datenbank für den flexiblen MySQL-Server.

    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).

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'@'%';

Sichern und Wiederherstellen des Quellservers

  1. Bestimmen Sie, welche Datenbanken und Tabellen Sie in Azure Database for MySQL flexiblen Server replizieren möchten, und führen Sie das Dump 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;

[!NOTE]

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

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

    Stellen Sie die Speicherabbilddatei auf dem Server wieder her, der in der Azure-Datenbank für mySQL flexiblen 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 sie aus dem virtuellen Computer in der Azure-Datenbank für MySQL flexible Serverinstanz wieder her.

Hinweis

Wenn Sie vermeiden möchten, dass die Datenbank beim Sichern und Wiederherstellen auf schreibgeschützt festgelegt wird, können Sie mydumper/myloader verwenden.

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.

Hinweis

DIE GTID-Zurücksetzung kann nicht auf einem georedundanzfähigen Server ausgeführt werden. Deaktivieren Sie georedundanz, um die GTID-Zurücksetzung auf dem Server durchzuführen. Sie können die Option "Georedundanz" nach dem Zurücksetzen der GTID erneut aktivieren. DIE GTID-Zurücksetzungsaktion ungültig macht alle verfügbaren Sicherungen ungültig, und daher kann es einen Tag dauern, bis die Geowiederherstellung auf dem Server ausgeführt werden kann, sobald Georedundanz erneut aktiviert ist.

  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 im 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-----'

Replikation mit SSL wird zwischen einem quellserver eingerichtet, der in der Do gehostet wird Standard "companya.com" und einem Replikatserver, der in Azure Database für 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

Replikation ohne SSL wird zwischen einem quellserver eingerichtet, der in der Do gehostet wird Standard "companya.com" und einem Replikatserver, der in Azure Database für 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, '');

  1. Starten Sie die Replikation.

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

    CALL mysql.az_replication_start;

  2. Ü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]

Show binary log results

Nächste Schritte

  • Erfahren Sie mehr über die Data-In-Replikation für azure Database für mySQL flexiblen Server.