Warum wird meine Verbindung zur Reader-Instance umgeleitet, wenn ich versuche, eine Verbindung zu meinem Amazon Aurora Writer-Endpunkt herzustellen?

Kurzbeschreibung

Wenn Sie versuchen, eine Verbindung zu Ihrem Aurora-Cluster-Endpunkt oder Writer-Endpunkt herzustellen, stellt Ihre Anwendung möglicherweise stattdessen eine Verbindung zur Reader-Instance her. Dies geschieht, wenn der Endpunkt und die zugeordneten IP-Adressen auf der Seite der Client-Anwendung zwischengespeichert werden.

Aurora-Cluster-Endpunkte zeigen immer auf die Aurora Writer-Instanz. Wenn ein Failover stattfindet, zeigt der Aurora-Cluster-Endpunkt auf die neue Writer-Instanz. Wenn Sie den Cluster-Endpunkt verwenden, werden Ihre Lese-/Schreibverbindungen während des Failovers automatisch an ein Aurora-Replikat umgeleitet. Diese Replikatinstanz wird zur primären Instanz heraufgestuft.

Während des Failovers kann sich also die zugrunde liegende IP-Adresse Ihrer Aurora-Instance ändern, und der zwischengespeicherte Wert ist möglicherweise nicht mehr in Betrieb.

Ein Client, der versucht, über einen DNS-Namen eine Verbindung zu einer Datenbank herzustellen, muss diesen DNS-Namen in eine IP-Adresse auflösen, indem er einen DNS-Server abfragt. Der Client speichert dann die Antworten im Cache. Pro Protokoll geben DNS-Antworten die Time to Live (TTL) an, die festlegt, wie lange der Client den Datensatz zwischenspeichern soll. Aurora-DNS-Zonen verwenden eine kurze TTL von fünf Sekunden. Viele Systeme implementieren jedoch Client-Caches mit unterschiedlichen Einstellungen, wodurch die TTL länger werden kann.

Wenn ein Client versucht, eine Verbindung zum Cluster herzustellen, obwohl die Änderungen an den DNS-Einträgen nicht weitergegeben wurden, erhält der Client eine alte Adresse. Dadurch stellt der Client eine Verbindung zur vorherigen primären Instanz her, die jetzt die Reader-Instanz ist.

Daher kann ein längeres Zwischenspeichern der DNS-Daten zu Verbindungsfehlern führen.

Der Client erhält keinen TCP-Verkehr mehr von der Datenbank, nachdem das Failover initiiert wurde. Stattdessen liegt es am Kunden, eine Auszeit zu nehmen. Diese harte Abgrenzung der ursprünglichen Primärdatenbank bei jedem Failover bedeutet, dass der Client bei geplanten und ungeplanten Failovers ein ähnliches Verhalten beobachtet.

Lösung

Überprüfen Sie, ob Sie eine Verbindung zur Writer-Instanz oder zu einer Aurora-Replik herstellen.

Um festzustellen, ob Ihr Client eine Verbindung zur Writer-Instanz oder zu einem Aurora-Replikat herstellt, verwenden Sie die @ @innodb_read_only -Variable:

mysql> select @@innodb_read_only;

Ein Wert von 0 bedeutet, dass Sie mit der Writer-Instanz verbunden sind.

Führen Sie diese Abfrage aus, um festzustellen, mit welchem Server Sie verbunden sind und ob es sich bei diesem Server um einen Writer oder Reader handelt:

mysql> select concat("You are connected to '",server_id,"', which is a ",if(SESSION_ID='MASTER_SESSION_ID',"Writer","Reader")) as CONNECTION_STATUS from information_schema.replica_host_status where SERVER_ID in (select @@aurora_server_id);
+-----------------------------------------------------------------+
| CONNECTION_STATUS                                               |
+-----------------------------------------------------------------+
| You are connected to 'aurora-test-instance1', which is a Writer |
+-----------------------------------------------------------------+
1 row in set (0.08 sec)

Beheben Sie Fehler bei mehreren Reader-Instanzen in einem Cluster

Aurora-Reader-Endpunkte sind DNS-CNAME-Einträge. Wenn ein Cluster mehrere Reader-Instanzen hat, erhalten Sie, wenn Sie den Reader-Endpunkt auflösen, eine Instanz-IP, die im Round-Robin-Modus ausgewählt wird. Dies liegt daran, dass der Reader-Endpunkt alle Aurora-Replikate enthält und einen DNS-basierten Round-Robin-Lastenausgleich für neue Verbindungen bietet.

Stellen Sie sicher, dass Sie den Endpunkt weiterhin auflösen, ohne DNS zwischenzuspeichern, um bei jeder Auflösung eine andere Instanz-IP zu erhalten. Wenn Sie den Endpunkt nur einmal auflösen und die Verbindung in Ihrem Pool behalten, geht jede Abfrage für diese Verbindung an dieselbe Instanz. Wenn Sie DNS zwischenspeichern, erhalten Sie jedes Mal dieselbe Instanz-IP, wenn Sie den Endpunkt auflösen.

Befolgen Sie bewährte Methoden

• Stellen Sie sicher, dass Ihre Netzwerk- und Client-Konfigurationen die DNS-Cache-TTL nicht weiter erhöhen. Wenn Sie irgendeine Form von Verbindungspooling oder sonstigem Multiplexing verwenden, müssen Sie möglicherweise alle zwischengespeicherten DNS-Informationen leeren oder die Time-to-Live für zwischengespeicherte DNS-Informationen reduzieren. Wenn Ihre Client-Anwendung die DNS-Daten Ihrer DB-Instances zwischenspeichert, legen Sie einen TTL-Wert von weniger als 30 Sekunden fest.
• Verwenden Sie Amazon Relational Database Service (Amazon RDS) Proxy, um Verbindungen zu verwalten. Weitere Informationen finden Sie unter Verwendung von Amazon RDS Proxy.
• Lesen Sie die bewährten Methoden für die Verwendung intelligenter Treiber.
• Verwenden Sie einen TCP-basierten Load Balancer wie Elastic Load Balancing oder HA/Proxy.

---

Ähnliche Informationen

Arten von Aurora-Endpunkten

DNS-Caching

Warum habe ich nach dem Ausfall eines Amazon-Aurora-DB-Clusters einen Nur-Lesen-Fehler erhalten?