Warum habe ich nach einem Failover eines Amazon Aurora DB Clusters eine Schreibgeschützt-Fehlermeldung erhalten?

Kurzbeschreibung

Wenn es in einem Amazon Aurora DB Cluster zu einem Multi-AZ-Failover kommt, werden die Cluster-Endpunkte automatisch aktualisiert, sodass sie die neu ernannten Rollen von Leser und Schreiber berücksichtigen und auf sie verweisen. Der alte Schreiber wird neu gestartet und dann in einen schreibgeschützten Modus versetzt, während ein vorhandenes Replikat zu einem Schreiber heraufgestuft wird.

Wenn Sie eine Schreibgeschützt-Fehlermeldung erhalten, bedeutet dies, dass Sie versuchen, eine Data Definition Language (DDL), Data Manipulation Language (DML) oder Data Control Language (DCL) Operation über einen vorhandenen Knoten auszuführen, der die Rolle eines Lesers hat. In Aurora MySQL können Sie dies bestätigen, indem Sie die Variable innodb\ _read\ _only wie folgt überprüfen:

mysql> show variables where variable_name='innodb_read_only';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| innodb_read_only | ON    |
+------------------+-------+
1 row in set (0.01 sec)

Behebung

Den Cluster-Schreiber-Endpunkt verwenden

Da sich die Rolle einer DB Instance in einem Aurora Cluster ändern kann, empfiehlt es sich, den Cluster-Schreiber-Endpunkt zu verwenden, um sicherzustellen, dass Sie immer auf den neuesten Schreiber verweisen. Wenn Sie den DB-Instance-Endpunkt oder eine direkte IP-Adresse verwenden, ist Ihnen möglicherweise nicht bewusst, dass ein Failover aufgetreten ist, und Sie erhalten eine Schreibgeschützt-Meldung, wenn Sie sich erneut mit demselben Host verbinden. Dadurch werden Sie daran gehindert, wie vorgesehen DDL/DML-Änderungen vorzunehmen.

DNS nicht übermäßig zwischenspeichern

Wenn Sie keinen intelligenten Treiber verwenden, sind Sie darauf angewiesen, dass die DNS-Einträge aktualisiert und weitergegeben werden, nachdem ein Failover-Ereignis eingetreten ist. Aurora-DNS-Zonen verwenden eine kurze Time to Live (TTL) von 5 Sekunden. Daher ist es wichtig, dass Ihre Netzwerk- und Client-Konfigurationen diese nicht weiter erhöhen. DNS-Caching kann auf mehreren Ebenen einer Architektur erfolgen, z. B. auf dem Betriebssystem (OS), der Netzwerkebene und dem Anwendungscontainer. Es ist wichtig, dass Sie verstehen, wie jede dieser Ebenen konfiguriert ist. Wenn es zu einem unbeabsichtigten DNS-Caching kommt, das die TTL von 5 Sekunden überschreitet, ist es möglich, dass Sie nach einem Failover erneut eine Verbindung zum alten Schreiber herstellen.

Java Virtual Machines (JVM) können DNS auf unbestimmte Zeit übermäßig zwischenspeichern. Wenn die JVM einen Hostnamen in eine IP-Adresse auflöst, speichert sie die IP-Adresse für einen bestimmten Zeitraum (TTL) im Cache. Bei einigen Konfigurationen ist die JVM-Standard-TTL so eingestellt, dass DNS-Einträge erst aktualisiert werden, wenn die JVM neu gestartet wird. Dies kann nach einem Failover zu Schreibgeschützt-Fehlern führen. In diesem Fall ist es wichtig, manuell eine kurze TTL einzustellen, damit sie regelmäßig aktualisiert wird.

Einen intelligenten Treiber verwenden

Die DB-Cluster-Endpunkte von Amazon Aurora verteilen DNS-Datensatzaktualisierungen automatisch, aber der Vorgang erfolgt nicht sofort. Dies kann zu Verzögerungen bei der Reaktion auf ein Ereignis führen, das in der Datenbank aufgetreten ist, und das Ereignis wird möglicherweise von der Anwendung verarbeitet. Ein intelligenter Treiber verwendet die Topographie des DB Clusters mithilfe der Metadatentabelle INFORMATION\ _SCHEMA.REPLICA\ _HOST\ _STATUS, die nahezu in Echtzeit verfügbar ist. Dies hilft dabei, Verbindungen an die richtige Rolle weiterzuleiten, und hilft bei der Lastverteilung zwischen den vorhandenen Replikaten. MariaDB Connector/J ist ein Beispiel für einen intelligenten Treiber eines Drittanbieters, der Aurora MySQL nativ unterstützt.

Hinweis: Sogar intelligente Treiber könnten von übermäßigem DNS-Caching betroffen sein.

Testen, mit welcher Instance Sie verbunden sind

Wie in den bewährten Methoden des Aurora-Verbindungsmanagement-Handbuchs erwähnt, sollten Sie, wenn Sie keinen intelligenten Treiber verwenden, testen und verstehen, bei welcher Instance Sie angemeldet sind, nachdem Sie eine neue Verbindung hergestellt haben. Auf diese Weise können Sie sicherstellen, dass Sie mit der richtigen Instance verbunden sind. Mit der Variablen @@innodb_read_only können Sie testen, ob Sie mit der Schreiber-Instance oder einem Aurora-Leser verbunden sind. Dieses Beispiel zeigt einen Wert von 0, was bedeutet, dass Sie mit dem Schreiber verbunden sind.

mysql> select @@innodb_read_only;
+--------------------+
| @@innodb_read_only |
+--------------------+
| 0                  |
+--------------------+
1 row in set (0.00 sec)

---

Weitere Informationen

Amazon-Aurora-Verbindungsmanagement

Einstellung der JVM TTL für DNS-Namensabfragen

Handbuch zur Verbindungsverwaltung von DBAs