Arbeiten mit MySQL Read Replicas (Lesereplikaten) - Amazon Relational Database Service

Arbeiten mit MySQL Read Replicas (Lesereplikaten)

Dieser Abschnitt enthält spezifische Informationen zum Arbeiten mit Lesereplikaten unter Amazon RDS-MySQL. Allgemeine Informationen zu Lesereplikaten und Anleitungen zu ihrer Verwendung finden Sie in Arbeiten mit Lesereplikaten.

Konfiguration von Read Replicas mit MySQL

Bevor eine MySQL-DB-Instance als Replikationsquelle dienen kann, stellen Sie sicher, dass automatische Sicherungen für die Quell-DB-Instance aktiviert werden. Hierzu legen Sie für den Aufbewahrungszeitraum für Sicherungen einen anderen Wert als 0 fest. Diese Anforderung gilt auch für ein Lesereplikat, das die Quell-DB-Instance für ein anderes Lesereplikat ist. Automatische Sicherungen werden nur für Lesereplikate unterstützt, die mit MySQL-Version 5.6 oder neuer ausgeführt werden. Sie können die Replikation basierend auf den Binärprotokollkoordinaten für eine MySQL-DB-Instance konfigurieren.

Bei Amazon RDS-MySQL Version 5.7.23 und höheren Versionen von MySQL 5.7 können Sie die Replikation über globale Transaktionskennungen (GTIDs) konfigurieren. Weitere Informationen finden Sie unter Verwenden der GTID-basierten Replikation für Amazon RDS-MySQL.

Sie können bis zu fünf Lesereplikate von einer DB-Instance erstellen. Damit die Replikation effektiv durchgeführt werden kann, sollte jedes Lesereplikat über die selbe Menge an Rechen- und Speicherressourcen wie die Quell-DB-Instance verfügen. Wenn Sie die Quell-DB-Instance skalieren, skalieren Sie auch die Lesereplikate.

Wenn ein Lesereplikat eine MySQL-Version ab 5.6 ausführt, können Sie es als die Quell-DB-Instance für ein anderes Lesereplikat festlegen. Sie können beispielsweise ReadReplica1 aus MyDBInstance erstellen und anschließend ReadReplica2 aus ReadReplica1. Updates für MyDBInstance werden auf ReadReplica1 und anschließend von ReadReplica1 auf ReadReplica2 repliziert. Sie können nicht mehr als vier Instances haben, die in einer Replikationskette mitwirken. Sie können beispielsweise ReadReplica1 aus MySourceDBInstance erstellen und anschließend ReadReplica2 aus ReadReplica1 erstellen und anschließend ReadReplica3 aus ReadReplica2 erstellen, aber Sie können nicht ReadReplica4 aus ReadReplica3 erstellen.

Wenn Sie ein MySQL-Lesereplikat hochstufen, das wiederum in andere Lesereplikate repliziert, bleiben jene Lesereplikate aktiv. Betrachten Sie ein Beispiel, bei dem MyDBInstance1 nach MyDBInstance2 repliziert und MyDBInstance2 nach MyDBInstance3 repliziert. Wenn Sie MyDBInstance2 hochstufen, wird die Replikation von MyDBInstance1 nach MyDBInstance 2 beendet, aber MyDBInstance2 repliziert weiterhin nach MyDBInstance3.

Um automatische Sicherungen auf einem Lesereplikat für Amazon RDS-MySQL-Version 5.6 und höher zu aktivieren, erstellen Sie zuerst das Lesereplikat. Ändern Sie dann das Lesereplikat, um automatische Sicherungen zu aktivieren.

Sie können mehrere Erstellungs- oder Löschaktionen für Lesereplikate gleichzeitig ausführen, die auf die gleiche Quell-DB-Instance verweisen. Bleiben Sie dazu innerhalb der Grenze von fünf Lesereplikaten für jede Quell-Instance.

Eine Lesereplikat einer MySQL-DB-Instance kann keine niedrigere DB-Engine-Version als die Quell-DB-Instance verwenden.

Vorbereiten von MySQL-DB-Instances, die MyISAM verwenden

Wenn Ihre MySQL-DB-Instance eine nicht-transaktionale Engine, wie MyISAM, verwendet, müssen Sie die folgenden Schritte erfolgreich ausführen, um Ihr Lesereplikat einzurichten. Diese Schritte sind unbedingt notwendig, damit das Lesereplikat eine konsistente Kopie Ihrer Daten enthält. Diese Schritte sind nicht erforderlich, wenn alle Ihre Tabellen eine transaktionale Engine wie InnoDB nutzen.

  1. Halten Sie alle Data Manipulation Language (DML)- und Data Definition Language (DDL)-Operationen in nicht-transaktionalen Tabellen in der Quell-DB-Instance an und warten Sie bis diese abgeschlossen sind. SELECT-Anweisungen können weiter ausgeführt werden.

  2. Bereinigen und sperren Sie die Tabellen in der Quell-DB-Instance.

  3. Erstellen Sie das Lesereplikat mithilfe der Methoden in den folgenden Abschnitten.

  4. Überprüfen Sie den Vorgang der Lesereplikat-Erstellung mithilfe von beispielsweise der API-Operation DescribeDBInstances. Sobald das Lesereplikat verfügbar ist, entsperren Sie die Tabellen in der Quell-DB-Instance und fahren Sie mit den normalen Datenbank-Operationen fort.

Konfigurieren der verzögerten Replikation mit MySQL

Sie können die verzögerte Replikation als Strategie für die Notfallwiederherstellung einsetzen. Für die verzögerte Replikation geben Sie die Mindestanzahl von Sekunden an, um die die Replikation von der Quelle in das Lesereplikat verzögert werden soll. Wenn es zu einem Notfall kommt, weil beispielsweise eine Tabelle versehentlich gelöscht wurde, können Sie das Problem mit den folgenden Schritten schnell beheben:

  • Beenden Sie die Replikation im Lesereplikat, bevor die Änderung, die den Notfall verursacht hat, an das Lesereplikat gesendet wird.

    Verwenden Sie die gespeicherte Prozedur mysql.rds_stop_replication, um die Replikation zu stoppen.

  • Starten Sie die Replikation und geben Sie an, dass die Replikation automatisch an einer bestimmten Position in der Protokolldatei stoppen soll.

    Mit der gespeicherten Prozedur mysql.rds_start_replication_until geben Sie eine Position unmittelbar vor Eintreten des Notfalls an.

  • Stufen Sie das Lesereplikat zur neuen Quell-DB-Instance hoch, indem Sie der Anleitung unter Hochstufen eines Lesereplikats zur eigenständigen DB-Instance folgen.

Anmerkung
  • Unter Amazon RDS MySQL 5.7 wird die verzögerte Replikation für MySQL ab 5.7.22 unterstützt. Unter Amazon RDS MySQL 5.6 wird die verzögerte Replikation für MySQL ab 5.6.40 unterstützt. Verzögerte Replikation wird von Amazon RDS-MySQL 8.0 nicht unterstützt.

  • Verwenden Sie gespeicherte Prozeduren, um die verzögerte Replikation zu konfigurieren. Sie können die verzögerte Replikation nicht mit der AWS Management Console, der AWS CLI oder der Amazon RDS-API konfigurieren.

  • Bei Amazon RDS-MySQL 5.7.23 und höheren MySQL 5.7 Versionen können Sie die GTID-basierte Replikation in einer verzögerten Replikationskonfiguration verwenden. Wenn Sie die GTID-basierte Replikation verwenden, nutzen Sie die gespeicherte Prozedur mysql.rds_start_replication_until_gtid anstelle der gespeicherten Prozedur mysql.rds_start_replication_until. Weitere Informationen zu GTID-basierten Replikationen finden Sie unter Verwenden der GTID-basierten Replikation für Amazon RDS-MySQL.

Konfigurieren der verzögerten Replikation während der Erstellung von Read Replicas

Um die verzögerte Replikation für zukünftig aus einer DB-Instance erstellte Lesereplikate zu konfigurieren, führen Sie die gespeicherte Prozedur mysql.rds_set_configuration mit dem Parameter target delay aus.

So konfigurieren Sie die verzögerte Replikation während der Lesereplikat-Erstellung

  1. Stellen Sie als Master-Benutzer mit einem MySQL-Client eine Verbindung zu der MySQL-DB-Instance her, die als Quelle für Lesereplikate verwendet werden soll.

  2. Führen Sie die gespeicherte Prozedur mysql.rds_set_configuration mit dem Parameter target delay aus.

    Führen Sie beispielsweise die folgende gespeicherte Prozedur aus, um anzugeben, dass die Replikation um mindestens eine Stunde (3.600 Sekunden) für jedes Lesereplikat verzögert werden soll, das aus der aktuellen DB-Instance erstellt wird.

    call mysql.rds_set_configuration('target delay', 3600);
    Anmerkung

    Nach dem Ausführen dieser gespeicherten Prozedur wird jedes Lesereplikat, das Sie mit der AWS CLI oder der Amazon RDS-API erstellen, mit einer um die angegebene Anzahl Sekunden verzögerten Replikation konfiguriert.

Ändern der verzögerten Replikation einer vorhandenen Read Replica

Führen Sie die gespeicherte Prozedur mysql.rds_set_source_delay aus, um die verzögerte Replikation eines vorhandenen Lesereplikats zu ändern.

So ändern Sie die verzögerte Replikation eines existierenden Lesereplikats

  1. Verwenden Sie einen MySQL-Client, um als Master-Benutzer eine Verbindung zum Lesereplikat herzustellen.

  2. Verwenden Sie die gespeicherte Prozedur mysql.rds_stop_replication, um die Replikation zu stoppen.

  3. Führen Sie die gespeicherte Prozedur mysql.rds_set_source_delay aus.

    Führen Sie beispielsweise die folgende gespeicherte Prozedur aus, um anzugeben, dass die Replikation für das Lesereplikat um mindestens eine Stunde (3600 Sekunden) verzögert werden soll.

    call mysql.rds_set_source_delay(3600);
  4. Verwenden Sie die gespeicherte Prozedur mysql.rds_start_replication, um die Replikation zu starten.

Festlegen einer Position zum Stoppen der Replikation zu einer Read Replica

Nachdem Sie die Replikation für ein Lesereplikat gestoppt haben, können Sie die Replikation mit der gespeicherten Prozedur mysql.rds_start_replication_until starten und dann an einer angegebenen Position in der Binärprotokolldatei stoppen lassen.

So starten Sie die Replikation für ein Lesereplikat und stoppen die Replikation an einer bestimmten Position

  1. Verwenden Sie einen MySQL-Client, um als Masterbenutzer eine Verbindung zur MySQL-DB-Instance herzustellen.

  2. Führen Sie die gespeicherte Prozedur mysql.rds_start_replication_until aus.

    Das folgende Beispiel initiiert die Replikation und repliziert die Änderungen, bis die Position 120 in der Binärprotokolldatei mysql-bin-changelog.000777 erreicht wird. Beispiel: In einem Szenario der Notfallwiederherstellung liegt die Position 120 unmittelbar vor der Katastrophe.

    call mysql.rds_start_replication_until( 'mysql-bin-changelog.000777', 120);

Die Replikation stoppt automatisch, sobald der Stopppunkt erreicht ist. Das folgende RDS-Ereignis wird generiert: Replication has been stopped since the replica reached the stop point specified by the rds_start_replication_until stored procedure.

Nachdem die Replikation gestoppt wurde, können Sie in einem Szenario der Notfallwiederherstellung das Lesereplikats zur neuen Quell-DB-Instance hochstufen (Hochstufen eines Lesereplikats zur eigenständigen DB-Instance). Weitere Informationen zum Hochstufen des Lesereplikats finden Sie unter Hochstufen eines Lesereplikats zur eigenständigen DB-Instance.

Aktualisierungen von Read Replicas mit MySQL

Lesereplikate wurden zur Unterstützung von Leseabfragen entwickelt. Jedoch könnten gelegentliche Updates notwendig sein. Sie könnten beispielsweise einen Index hinzufügen, um die spezifischen Abfragetypen zu optimieren, die auf das Replica zugreifen. Sie können Updates aktivieren, indem Sie den Parameter read_only in der DB-Parametergruppe für das Lesereplikat auf 0 setzen. Seien Sie beim Deaktivieren des Schreibschutzes in einem Lesereplikat vorsichtig, da Probleme auftreten können, wenn das Lesereplikat nicht mehr mit der Quell-DB-Instance kompatibel ist. Ändern Sie den Wert des Parameters read_only sobald wie möglich zurück auf 1.

Multi-AZ-Read-Replica-Bereitstellungen mit MySQL

Sie können ein Lesereplikat aus Single-AZ- oder Multi-AZ-DB-Instance-Bereitstellungen erstellen. Sie können Multi-AZ-Bereitstellungen verwenden, um die Haltbarkeit und Verfügbarkeit kritischer Daten zu verbessern, aber Sie können Multi-AZ nicht zweitranging noch für schreibgeschützte Abfragen verwenden. Stattdessen können Sie Lesereplikate aus Multi-AZ-DB-Instances mit hohem Datenverkehr erstellen, um schreibgeschützte Abfragen auslagern zu können. Wenn die Quell-Instance einer Multi-AZ-Bereitstellung ein Failover zur sekundären Instance durchführt, werden alle zugehörigen Lesereplikate automatisch auf die Verwendung der sekundären (jetzt primären) Instance als Replikationsquelle umgeschaltet. Weitere Informationen finden Sie unter Hohe Verfügbarkeit (Multi-AZ) für Amazon RDS.

Sie können ein Lesereplikat als Multi-AZ-DB-Instance erstellen. Amazon RDS erstellt eine Standby-Version des Replikats in einer anderen Availability Zone, um ein Failover für das Replikat zu unterstützen. Das Erstellen Ihres Lesereplikats als Multi-AZ-DB-Instance ist unabhängig davon, ob die Quelldatenbank eine Multi-AZ-DB-Instance ist.

Anmerkung

Um ein Lesereplikat als Multi-AZ-DB-Instance zu erstellen, muss die DB-Instance MySQL 5.6 oder höher sein.

Überwachung von MySQL Read Replicas

Für MySQL-Lesereplikat können Sie die Replikationsverzögerung in Amazon CloudWatch überwachen, indem Sie sich die Amazon RDS-Metrik ReplicaLag ansehen. Die Kennzahl ReplicaLag meldet den Wert des Feldes Seconds_Behind_Master des Befehls SHOW SLAVE STATUS.

Häufige Ursachen für Replikationsverzögerungen in MySQL:

  • Ein Netzwerkausfall.

  • Schreiben in Tabellen, die verschiedene Indizes in einem Lesereplikat haben. Wenn der Parameter read_only in einem Lesereplikat auf 0 gesetzt ist, kann die Replikation fehlschlagen, wenn das Lesereplikat nicht mehr mit der Quell-DB-Instance kompatibel ist. Nachdem Sie Wartungsarbeiten für ein Lesereplikat durchgeführt haben, sollten Sie den Parameter read_only wieder zurück auf 1 setzen.

  • Die Verwendung einer nicht-transaktionalen Speicher-Engine wie MyISAM: Die Replikation wird nur für die InnoDB-Speicher-Engine für MySQL unterstützt.

Wenn die Metrik ReplicaLag 0 erreicht, hat das Replica den Stand der Quell-DB-Instance erreicht. Wenn die Metrik ReplicaLag -1 zurückgibt, ist die Replikation aktuell nicht aktiv. ReplicaLag = -1 ist gleich Seconds_Behind_Master = NULL.

Starten und Stoppen der Replikation mit MySQL Read Replicas

Sie können den Replikationsvorgang für eine Amazon RDS-DB-Instance anhalten oder neustarten, indem Sie die gespeicherten Systemprozeduren mysql.rds_stop_replication und mysql.rds_start_replication aufrufen. Dies können Sie tun, wenn Sie eine Replikation zwischen Amazon RDS-Instances für langandauernde Operationen, wie dem Erstellen von großen Indexen, durchführen. Sie müssen Replikation auch anhalten und starten, wenn Sie Datenbanken importieren oder exportieren. Weitere Informationen finden Sie unter Importieren von Daten in eine Amazon RDS-MySQL oder MariaDB-DB-Instance mit reduzierter Ausfallzeit und Exportieren von Daten aus einer MySQL DB-Instance mithilfe der Replikation.

Wenn eine Replikation für mehr als 30 aufeinanderfolgende Tage manuell oder aufgrund eines Replikationsfehlers gestoppt wird, beendet Amazon RDS die Replikation zwischen der Quell-DB-Instance und allen Lesereplikaten. um erhöhten Speicheranforderungen in der Quell-DB-Instance vorzubeugen und lange Failover-Zeiten zu vermeiden. Die Lesereplikat-DB-Instance ist weiterhin verfügbar. Die Replikation kann jedoch nicht fortgesetzt werden, da die vom Lesereplikat benötigten Binärprotokolle aus der Quell-DB-Instance nach Beendigung der Replikation gelöscht wurden. Sie können ein neues Lesereplikat für die Quell-DB-Instance erstellen, um die Replikation erneut aufzunehmen.

Fehlerbehebung für ein Problem mit einer MySQL Read Replica

Im Fall von MySQL-DB-Instances zeigen Lesereplikate manchmal Replikationsfehler oder Dateninkonsistenzen zwischen dem Lesereplikat und seiner DB-Quell-Instance an. Dieses Problem tritt auf, wenn einige Binärprotokoll (Binlog)-Ereignisse oder InnoDB-Wiederholungsprotokolle während eines Fehlers des Lesereplikats oder der Quell-DB-Instance nicht bereinigt werden. In diesen Fällen müssen Sie die Lesereplikate manuell löschen und neu erstellen. Sie können das Risiko minimieren, indem Sie die Werte der folgenden dynamischen Variablen einstellen: sync_binlog=1, innodb_flush_log_at_trx_commit=1 und innodb_support_xa=1. Diese Einstellungen könnten die Leistung reduzieren, daher ist es ratsam, sie vor der Implementierung in einer Produktionsumgebung ausgiebig zu testen. Unter MySQL 5.5 hat sync_binlog standardmäßig den Wert 0, aber in MySQL ab 5.6 sind Probleme unwahrscheinlicher, da all diese Parameter standardmäßig auf die empfohlenen Werte eingestellt sind.

Die Replikationstechnologien in MySQL funktionieren nach einem asynchronen Prinzip. Da sie asynchron sind, steigt gelegentlich BinLogDiskUsage in der Quell-DB-Instance an und ReplicaLag ist im Lesereplikat zu erwarten. Beispielsweise kann auf der Quell-DB-Instance eine große Anzahl von Schreibvorgängen gleichzeitig ausgeführt werden. Dagegen werden Schreibvorgänge zum Lesereplikat über einen einzigen E/A-Thread seriell abgearbeitet. Dies kann zu einer Verzögerung zwischen der Quell-DB-Instance und dem Lesereplikat führen. Weitere Informationen über schreibgeschützte Replikate in der MySQL-Dokumentation finden Sie unter Details zur Implementierung der Replikation.

Sie können folgende Dinge tun, um die Verzögerungszeit zwischen Aktualisierungen einer Quell-DB-Instance und der nachfolgenden Aktualisierung des Lesereplikats zu reduzieren:

  • Passen Sie die Speichergröße und die DB-Instance-Klasse eines Lesereplikats an die der Quell-DB-Instance an.

  • Stellen Sie sicher, dass Parametereinstellungen in den DB-Parametergruppen, die von der Quell-DB-Instance und den Lesereplikaten verwendet werden, kompatibel sind. Weitere Informationen und ein Beispiel finden Sie in der Beschreibung des max_allowed_packet-Parameters weiter unten in diesem Abschnitt.

Amazon RDS überwacht den Replikationsstatus Ihrer Lesereplikate und setzt den Replication State der Lesereplikat-Instance auf Error, wenn die Replikation aus irgendeinem Grund beendet wird. Ein Beispiel wären auf Ihrem Lesereplikat ausgeführte DML-Abfragen, die mit den Aktualisierungen auf der Quell-DB-Instance in Konflikt treten.

Sie können die Details des von der MySQL-Engine zurückgegebenen Fehlers dem Feld Replication Error entnehmen. Ereignisse, die den Status des Lesereplikats angeben, werden auch generiert, einschließlich RDS-EVENT-0045, RDS-EVENT-0046 und RDS-EVENT-0047. Weitere Informationen über Ereignisse und Abonnements zu Ereignissen finden Sie unter Verwenden von Amazon RDS-Ereignisbenachrichtigungen. Wenn eine MySQL-Fehlermeldung zurückgegeben wird, überprüfen Sie die Fehlernummer in der MySQL-Fehlermeldungsdokumentation.

Ein häufiges Problem, das Replikationsfehler verursachen kann, besteht, wenn der Wert für den max_allowed_packet-Parameter eines Lesereplikats niedriger ist als der Wert für den max_allowed_packet-Parameter der Quell-DB-Instance. Der Parameter max_allowed_packet ist ein benutzerdefinierter Parameter, den Sie in einer DB-Parametergruppe festlegen können. Sie verwenden max_allowed_packet, um die maximale Größe von DML-Code anzugeben, der in der Datenbank ausgeführt werden kann. In einigen Fällen ist der max_allowed_packet-Wert in der mit einer Quell-DB-Instance verknüpften DB-Parametergruppe kleiner als der max_allowed_packet-Wert in der mit dem Lesereplikat der Quelle verknüpften DB-Parametergruppe. In diesen Fällen kann der Replikationsprozess den Fehler Packet bigger than 'max_allowed_packet' bytes auslösen und die Replikation beenden. Um den Fehler zu beheben, lassen Sie die DB-Quell-Instance und das Lesereplikat DB-Parametergruppen mit denselben max_allowed_packet-Parameterwerten verwenden.

Weitere Situationen, bei denen Replikationsfehler auftreten können, sind die Folgenden:

  • Schreibvorgänge auf Tabellen in einem Lesereplikat. In einigen Fällen können Sie Indizes für ein Lesereplikat erstellen, die sich von den Indizes in der Quell-DB-Instance unterscheiden. Wenn Sie dies tun, setzen Sie den Parameter read_only auf 0, um die Indizes zu erstellen. Wenn Sie in einem Lesereplikat in Tabellen schreiben, kann die Replikation unterbrochen werden, wenn das Lesereplikat nicht mehr mit der Quell-DB-Instance kompatibel ist. Nachdem Sie Wartungsarbeiten für ein Lesereplikat durchgeführt haben, sollten Sie den Parameter read_only wieder zurück auf 1 setzen.

  • Die Verwendung einer nicht-transaktionalen Speicher-Engine wie MyISAM: Read Replicas erfordern eine transaktionale Speicher-Engine. Die Replikation wird nur für die InnoDB-Speicher-Engine für MySQL unterstützt.

  • Verwenden von nicht-deterministischen Abfragen wie SYSDATE(). Weitere Informationen finden Sie unter Erkennen sicherer und nicht sicherer Anweisungen in der binären Protokollierung.

Wenn Sie entscheiden, dass Sie einen Fehler problemlos überspringen können, folgen Sie den Schritten im Abschnitt Überspringen von Fehlern für die aktuelle Replikation. Andernfalls können Sie zuerst das Lesereplikat löschen. Anschließend erstellen Sie eine Instance mit derselben DB-Instance-Kennung, sodass der Endpunkt mit dem des alten Lesereplikats übereinstimmt. Wird ein Replikationsfehler behoben, ändert sich das Feld Replication State zu Replicating.