Freigeben über

Gewusst wie: Konfigurieren der Datenreplikation in Azure Database for MySQL

  • Artikel

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

Wichtig

Azure Database for MySQL Single Server wird eingestellt. Es wird dringend empfohlen, ein Upgrade auf Azure Database for MySQL Flexible Server auszuführen. Weitere Informationen zum Migrieren zu Azure Database for MySQL Flexible Server finden Sie unter Was geschieht mit Azure Database for MySQL Single Server?

In diesem Artikel erfahren Sie, wie Sie die Datenreplikation in Azure Database for MySQL einrichten, indem Sie 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.

Die Datenreplikationsfunktion synchronisiert Daten von einem lokalen MySQL-Quellserver, virtuellen Computern (VMs) oder Clouddatenbankdiensten, um ein Replikat im Azure Database for MySQL-Dienst zu erstellen. Die Datenreplikation basiert auf der nativen MySQL-Replikation, die wiederum auf der Position der binären Protokolldatei (binlog) oder GTID basiert. Weitere Informationen zur binlog-Replikation finden Sie unter Binary Log File Position Based Replication Configuration Overview (Konfiguration der auf der Position der binären Protokolldatei basierenden Replikation – Übersicht).

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

Erstellen einer Azure Database for MySQL Single Server-Instanz, die als Replikat verwendet werden soll

  1. Erstellen Sie eine neue Instanz von Azure Database for MySQL Single Server (z. B. replica.mysql.database.azure.com). Informationen zur Servererstellung finden Sie unter Erstellen eines Azure Database for MySQL-Servers über das Azure-Portal. Dieser Server ist der Replikatserver für die Datenreplikation.

    Wichtig

    Der Azure Database for MySQL-Server muss in den Tarifen Universell oder Arbeitsspeicheroptimiert erstellt werden, da die Datenreplikation nur in diesen Tarifen unterstützt wird. GTID wird in den Versionen 5.7 und 8.0 unterstützt, und zwar nur auf Servern mit Speichergrößen bis zu 16 TB (universeller Speicher v2).

  2. Erstellen Sie dieselben Benutzerkonten und entsprechenden Berechtigungen.

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

  3. Fügen Sie den Firewallregeln des Replikats die IP-Adresse des Quellservers hinzu.

    Aktualisieren Sie Firewallregeln über das Azure-Portal oder über die Azure-Befehlszeilenschnittstelle.

  4. Optional – Wenn Sie die GTID-basierte Replikation vom Quellserver auf den Azure-Datenbank für MySQL-Replikatserver verwenden möchten, müssen Sie die folgenden Serverparameter auf der Azure-Datenbank für MySQL-Server aktivieren:

    • enforce_gtid_consistency
    • gtid_mode

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 Replikation eingehender Daten 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. 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.

    Testen Sie die Konnektivität mit dem Quellserver, indem Sie versuchen, eine Verbindung über ein Tool wie die MySQL-Befehlszeile auf einem anderen Computer oder über die im Azure-Portal verfügbare Azure Cloud Shell herzustellen.

    Wenn in Ihrer Organisation strenge Sicherheitsrichtlinien gelten, die nicht zulassen, dass alle IP-Adressen auf dem Quellserver die Kommunikation von Azure mit dem Quellserver ermöglichen, können Sie möglicherweise mit dem folgenden Befehl die IP-Adresse Ihres MySQL-Servers ermitteln.

    1. Melden Sie sich bei Ihrer Azure Database for MySQL-Server mit einem Tool wie der MySQL-Befehlszeile an.

    2. Führen Sie die folgenden Abfrage aus.

      mysql> SELECT @@global.redirect_server_host;

      Nachstehend ist eine Beispielausgabe aufgeführt:

      +-----------------------------------------------------------+
| @@global.redirect_server_host                             |
+-----------------------------------------------------------+
| e299ae56f000.tr1830.westus1-a.worker.database.windows.net |
 +-----------------------------------------------------------+

    3. Schließen Sie die MySQL-Befehlszeile.

    4. Führen Sie den folgenden Befehl im Hilfsprogramm ping aus, um die IP-Adresse abzurufen:

      ping <output of step 2b>

      Beispiel:

      C:\Users\testuser> ping e299ae56f000.tr1830.westus1-a.worker.database.windows.net
Pinging tr1830.westus1-a.worker.database.windows.net (**11.11.111.111**) 56(84) bytes of data.

    5. Konfigurieren Sie die Firewallregeln des Quellservers so, dass die im letzten Schritt ausgegebene IP-Adresse an Port 3306 eingeschlossen ist.

      Hinweis

      Diese IP-Adresse kann sich bei Wartungs- und Bereitstellungsvorgängen ändern. Diese Verbindungsmethode gilt nur für Kunden, die nicht alle IP-Adressen an Port 3306 zulassen können.

  3. Aktivieren Sie die binäre Protokollierung.

    Ü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-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 standardmäßig „1“.

    SET GLOBAL lower_case_table_names = 1;

    Optional: Wenn Sie die GTID-basierte Replikation verwenden möchten, müssen Sie überprüfen, ob GTID auf dem Quellserver aktiviert ist. Sie können den folgenden Befehl für Ihren MySQL-Quellserver ausführen, um zu prüfen, ob gtid_mode auf ON festgelegt ist.

    show variables like 'gtid_mode';

    Wichtig

    Für alle Server ist gtid_mode auf den Standardwert OFF festgelegt. Sie müssen die GTID nicht gesondert auf dem MySQL-Quellserver aktivieren, um die Datenreplikation einzurichten. Wenn GTID bereits auf dem Quellserver aktiviert ist, können Sie optional die GTID-basierte Replikation verwenden, um auch für Azure Database for MySQL Single Server die Datenreplikation einzurichten. Sie können die dateibasierte Replikation verwenden, um die Datenreplikation für alle Server einzurichten, unabhängig von der „gtid_mode“-Konfiguration auf dem Quellserver.

  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

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

    MySQL Workbench

    Um die Replikationsrolle in MySQL Workbench zu erstellen, öffnen Sie im Bereich Verwaltung den Bereich Benutzer und Berechtigungen, und wählen Sie dann Konto hinzufügen aus.

    Geben Sie den Benutzernamen in das Feld Anmeldename ein.

    Wählen Sie den Bereich Administratorrollen aus, und wählen Sie dann in der Liste Globale Berechtigungen den Eintrag Replikationsslave aus. Wählen Sie anschließend Übernehmen aus, um die Replikationsrolle zu erstellen.

  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.

    +------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000002 |      120 |              |                  |                   |
+------------------+----------+--------------+------------------+-------------------+

Sichern und Wiederherstellen des Quellservers

  1. Legen Sie fest, welche Datenbanken und Tabellen in Azure Database for MySQL 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. Optional: Wenn Sie die GTID-basierte Replikation verwenden möchten, müssen Sie die GTID der letzten Transaktion ermitteln, die auf dem primären Server ausgeführt wurde. Sie können den folgenden Befehl verwenden, um die GTID der letzten Transaktion zu notieren, die auf dem Masterserver ausgeführt wurde.

    show global variables like 'gtid_executed';

  3. 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;

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

    Stellen Sie die Sicherungsdatei auf dem Server wieder her, der im Dienst Azure Database for MySQL 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 auf dem Azure Database for MySQL-Server vom virtuellen Computer wieder her.

  5. Optional: Notieren Sie sich die GTID des wiederhergestellten Servers auf Azure Database for MySQL, um sicherzustellen, dass dieser mit dem primären Server identisch ist. Sie können den folgenden Befehl verwenden, um die GTID des bereinigten GTID-Werts auf dem Azure Database for MySQL-Replikatserver zu notieren. Der Wert von gtid_purged muss mit dem Wert gtid_executed auf dem Masterserver identisch sein, der in Schritt 2 notiert wurde, damit die GTID-basierte Replikation funktioniert.

    show global variables like 'gtid_purged';

  1. Legen Sie den Quellserver fest.

    Alle Datenreplikationsfunktionen erfolgen über gespeicherte Prozeduren. Alle Prozeduren finden Sie unter Gespeicherte Prozeduren für Datenreplikationen in Azure Database for MySQL. 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 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>');

    Optional: Wenn Sie die GTID-basierte Replikation verwenden möchten, müssen Sie den folgenden Befehl verwenden, um die beiden Server zu verknüpfen:

    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.

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

    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 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, '');

  2. Einrichten von Filtern

    Wenn Sie die Replikation einiger Tabellen von Ihrem Master überspringen möchten, aktualisieren Sie den Serverparameter replicate_wild_ignore_table auf Ihrem Replikatserver. Mithilfe einer durch Trennzeichen getrennten Liste können Sie mehr als ein Tabellenmuster angeben.

    Weitere Informationen zu diesem Parameter finden Sie in der MySQL-Dokumentation.

    Sie können den Parameter über das Azure-Portal oder die Azure-Befehlszeilenschnittstelle aktualisieren.

  3. Starten Sie die Replikation.

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

    CALL mysql.az_replication_start;

  4. Überprüfen Sie den Replikationsstatus.

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

    show slave status;

    Wenn der Status von Slave_IO_Running und Slave_SQL_Running „yes“ lautet und der Wert von Seconds_Behind_Master „0“ ist, 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;

Optional: Wenn Sie die GTID-basierte Replikation verwenden möchten, verwenden Sie die folgende gespeicherte Prozedur, um eine Transaktion zu überspringen.

call mysql. az_replication_skip_gtid_transaction(‘<transaction_gtid>’)

Die Prozedur kann die Transaktion für die angegebenen GTID überspringen. Wenn das GTID-Format nicht richtig ist oder die GTID-Transaktion bereits ausgeführt wurde, kann die Prozedur nicht ausgeführt werden. Die GTID für eine Transaktion kann durch Analyse des binären Protokolls bestimmt werden, um die Transaktionsereignisse zu überprüfen. MySQL bietet das Hilfsprogramm mysqlbinlog, um binäre Protokolle zu analysieren und deren Inhalt im Textformat anzuzeigen. Damit können Sie die GTID der Transaktion ermitteln.

Wichtig

Diese Prozedur kann nur verwendet werden, um eine Transaktion zu überspringen, und nicht, um „gtid set“ oder „set gtid_purged“ zu überspringen.

Verwenden Sie den folgenden Befehl, um die GTID der nächsten Transaktion wie unten dargestellt zu ermitteln, und die nächste Transaktion nach der aktuellen Replikationsposition zu überspringen.

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

mysql> show binlog event is 'mysql-bin.000007' from 194 limit 10;
+------------------+-----+-------------+-----------+-------------+-----------------------------------------------------------------+
| Log_name         | Pos | Event_type  | Server_id | End_log_pos | Info                                                            |
+------------------+-----+-------------+-----------+-------------+-----------------------------------------------------------------+
| mysql-bin.000007 | 194 | Gtid        |         2 |         259 | Set @@SESSION.GTID_NEXT= 'aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb' |
| mysql-bin.000007 | 259 | Query       |         2 |         331 | BEGIN                                                           |
| mysql-bin.000007 | 331 | Table_map   |         2 |         383 | table_id: 108 (test.testgtid)                                   |
| mysql-bin.000007 | 383 | Delete_rows |         2 |         463 | table_id: 108 flags: STMT_END_F                                 |
| mysql-bin.000007 | 463 | Xid         |         2 |         949 | COMMIT /* xid=14 */                                             |
+------------------+-----+-------------+-----------+-------------+-----------------------------------------------------------------+
5 rows in set (0.00 sec)

Nächste Schritte