Erreichen der Lese- und Schreib-Abfrage Verfügbarkeit in AWS Multi-AZ RDS

Question

Ich habe Multi-AZ RDS Mysql-Instanz ohne gelesene Replikate in einer Entwicklungsumgebung konfiguriert und ich Multi-AZ RDS Fail-Over durch Neustart der DB-Instanz testen.

Unten ist meine Beobachtung: Während RDS Fail-Over, wird die Client-Anwendung Verbindung nicht verloren, aber zur gleichen Zeit wird es nicht in der Lage sein, auf die Datenbank als auch zugreifen und einmal Fail-Over abgeschlossen, Client wird kann auf die Datenbank zugreifen.

Update 1: Die obige Beobachtung ist falsch.Was ich gerade beobachtet habe, ist, dass nach der Beendigung des Failover-Vorgangs der Fehler unterschritten wird und die Verbindung beendet wird.

ERROR 2003 (HY000): Can't connect to MySQL server on 'rds-test.czswqpewzqas.---------.amazonaws.com' (110) 

Kurz gesagt, meine Abfragen sind während des Neustarts von Multi-AZ mysql-Instanz fehlgeschlagen. Hat jemand eine Idee, was ich hier vermisse.

Update - Erreichbarkeit lesen Verfügbarkeit: Jetzt habe ich eine Read Replica für die Multi-AZ mysql-Instanz und auf den oben genannten Fehler, umleiten "Select-Abfragen" auf die Read Replica-Instanz.

Also, ich benutze Read replica Ich bin in der Lage, Lesefähigkeit zu erreichen.Ist das der richtige Weg? Möchte wissen, ob es andere Möglichkeiten gibt, es zu tun.

Auch, wie ich erreichen kann Verfügbarkeit schreiben in Multi-AZ RDS?

Answer 1

Ihre Beobachtungen sind korrekt. Während des Fail-Over gehen TCP-Verbindungen verloren, die Zeit zum Failover auf die sekundäre Datenbank und die Umschaltung der IP-Adressen in DNS.

Es ist bis zu der Anwendung

a/versuchen, ziehen sie sich zurück mit exponentiellen wieder zu verbinden. Die Wiederverbindung ist innerhalb von Minuten möglich.

b/Entscheiden Sie, wie Sie sich während des Failovers verhalten.

Lesetransaktionen (SELECT) können an eine Lesereplik übergeben werden. Moderne JDBC- und ODBC-Treiber können Lese-Replikate selbst verarbeiten, geben Sie einfach die Liste der IP-Adresse/DNS-Namen Ihrer Replikate an. Der Fahrer wird den Lastausgleich automatisch anwenden. Es ist keine Codeänderung erforderlich.

Schreibtransaktionen sind komplexer zu handhaben und es gibt keine einheitliche Antwort für alle Anwendungen. Die richtige Antwort hängt von Ihrer Anwendung ab & Geschäftsanforderungen.

Einige Kunden entscheiden sich dafür, alle Schreibvorgänge zu blockieren und geben eine Fehlermeldung an die Endbenutzer zurück, in der sie aufgefordert werden, es einige Minuten später erneut zu versuchen.

Einige Kunden stellen Schreibtransaktionen in eine SQS-Warteschlange ein. Sie entwickeln eine Queue-Reader-Anwendung, um ausstehende Transaktionen zu löschen, wenn die Master-Datenbank wieder verfügbar ist. (Abhängig von der Auslastung kann auch S3 oder DynamoDB verwendet werden). Natürlich sind Ihre Daten während des Fail-Over und einer kurzen Zeitspanne gleich nach dem Failover nicht konsistent, die Zeit, die erforderlich ist, um alle ausstehenden Schreibvorgänge zu löschen.

Bitte zögern Sie nicht zu anderen Strategien in realen Szenarien zu kommentieren.