Fehlerbehebung bei Problemen mit einer MariaDB Read Replica - 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.

Fehlerbehebung bei Problemen mit einer MariaDB Read Replica

Die Replikationstechnologien für MariaDB arbeiten asynchron. 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 über schreibgeschützte Replikate in der MariaDB-Dokumentation finden Sie unter Replikation - Übersicht.

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 MariaDB-Engine zurückgegebenen Fehlers im Feld Replication Error überprüfen. 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 Arbeiten mit Amazon-RDS-Ereignisbenachrichtigungen. Wenn eine MariaDB-Fehlermeldung zurückgegeben wird, überprüfen Sie den Fehler in der MariaDB error message documentation.

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, mit der die maximale Größe des auf der Datenbank ausführbaren DML-Codes angegeben wird. In einigen Fällen ist der Parameterwert max_allowed_packet in der mit einer Quell-DB-Instance verknüpften DB-Parametergruppe kleiner als der Parameterwert max_allowed_packet in der mit dem Lesereplikat der Quelle verknüpften DB-Parametergruppe. In diesen Fällen kann der Replikationsvorgang einen Fehler zurückgeben (Paket größer als "max_allowed_packet" Bytes) und die Replikation anhalten. Sie können den Fehler beheben, indem Sie die DB-Parametergruppe der Quelle und des Lesereplikats mit denselben Parameterwerten für max_allowed_packet verwenden.

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

  • Schreibvorgänge auf Tabellen in einem Lesereplikat. Wenn Sie Indizes für ein Lesereplikat erstellen, müssen Sie den read_only-Parameter auf 0 setzen, um die Indizes zu erstellen. Wenn Sie in dem Lesereplikat in Tabellen schreiben, kann die Replikation unterbrochen werden.

  • Bei Verwendung einer nicht-transaktionalen Speicher-Engine wie MyISAM, erfordern Lesereplikate eine transaktionale Speicher-Engine. Die Replikation wird nur für die InnoDB-Speicher-Engine für MariaDB 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 in Überspringen des aktuellen Replikationsfehlers für RDS für MySQL. Andernfalls können Sie das Lesereplikat löschen und eine Instance mit derselben DB-Instance-Kennung erstellen, sodass der Endpunkt mit dem alten Lesereplikat übereinstimmt. Wird ein Replikationsfehler behoben, ändert sich das Feld Replication State zu Replicating.

Bei MariaDB-DB-Instances kann in manchen Fällen nicht auf sekundäre Lesereplikate umgestellt werden, wenn während des Fehlers nicht alle Binärprotokollereignisse (binlog) bereinigt wurden. 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.