Behebung eines My SQL Read Replica-Problems - Amazon Relational Database Service

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Behebung eines My SQL Read Replica-Problems

Bei My SQL DB-Instances führen Read Replicas in einigen Fällen zu Replikationsfehlern oder Dateninkonsistenzen (oder beidem) zwischen der Read Replica und ihrer Quell-DB-Instance. 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 folgenden Parameterwerte einstellen: sync_binlog=1 und innodb_flush_log_at_trx_commit=1. Diese Einstellungen könnten die Leistung reduzieren, daher ist es ratsam, sie vor der Implementierung in einer Produktionsumgebung ausgiebig zu testen.

Warnung

In der Parametergruppe, die mit der Quell-DB-Instance verknüpft ist, sollten diese Parameterwerte beibehalten werden: sync_binlog=1 und innodb_flush_log_at_trx_commit=1. Diese Parameter sind dynamisch. Wenn Sie diese Einstellungen nicht verwenden möchten, empfehlen wir Ihnen, diese Werte vorübergehend festzulegen, bevor Sie einen Vorgang für die Quell-DB-Instance ausführen, der einen Neustart verursachen könnte. Zu diesen Vorgängen gehören unter anderem Neustart, Neustart mit Failover, das Aktualisieren der Datenbankversion und das Ändern der DB-Instance-Klasse oder ihres Speichers. Die gleiche Empfehlung gilt für das Erstellen neuer Lesereplikate für die Quell-DB-Instance.

Die Nichteinhaltung dieser Anleitung erhöht das Risiko, dass Lesereplikate Replikationsfehler oder Dateninkonsistenzen (oder beides) zwischen dem Lesereplikat und seiner DB-Quell-Instance aufweisen.

Die Replikationstechnologien für My sind asynchron. SQL 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 I/O-Thread seriell abgearbeitet. Dies kann zu einer Verzögerung zwischen der Quell-DB-Instance und dem Lesereplikat führen. Weitere Informationen zu schreibgeschützten Replikaten finden Sie in der SQL Dokumentation zu My unter Details zur Replikationsimplementierung.

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 Read Replicas und aktualisiert das Replication State Feld der Read Replica-Instance auf den Error Fall, dass die Replikation aus irgendeinem Grund beendet wird. Ein Beispiel könnte sein, wenn DML Abfragen, die auf Ihrer Read Replica ausgeführt werden, in Konflikt mit den Aktualisierungen stehen, die auf der Quell-DB-Instance vorgenommen wurden.

Sie können die Details des zugehörigen Fehlers, der von der My SQL Engine ausgelöst wurde, überprüfen, indem Sie sich das Replication Error Feld ansehen. Ereignisse, die den Status des Lesereplikats angeben, werden ebenfalls generiert, einschließlich RDS-EVENT-0045, RDS-EVENT-0046 und RDS-EVENT-0047. Weitere Informationen über Ereignisse und Abonnements zu Ereignissen finden Sie unter Mit RDS Amazon-Event-Benachrichtigungen arbeiten. Wenn die Meldung Meine SQL Fehlermeldung zurückgegeben wird, überprüfen Sie die Fehlernummer in der Dokumentation Meine SQL Fehlermeldung.

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 max_allowed_packet-Parameter ist ein benutzerdefinierter Parameter, den Sie in einer DB-Parametergruppe festlegen können. Sie geben max_allowed_packet damit die maximale DML Codegröße an, die 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.

  • Verwenden Sie eine nicht transaktionale Speicher-Engine wie My. ISAM Read Replicas erfordern eine transaktionale Speicher-Engine. Die Replikation wird nur für die InnoDB-Speicher-Engine auf My SQL 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 des aktuellen Replikationsfehlers für RDS für My SQL. 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.