Warum wurden DB-Verbindungen auf meiner RDS-DB-Instance unterbrochen?

Lesedauer: 5 Minute
0

Meine Datenbankverbindungen im Amazon Relational Database Service (Amazon RDS) wurden plötzlich unterbrochen, was zu unerwarteten Ausfallzeiten führte. Warum wurden meine DB-Verbindungen unterbrochen?

Auflösung

Amazon-RDS-DB-Verbindungen können aus verschiedenen Gründen unterbrochen werden. Um die Ursache für die Unterbrechung Ihrer DB-Verbindungen zu ermitteln, müssen Sie prüfen, ob die DB-Verbindungen während oder außerhalb des Wartungsfensters für Ihre RDS-DB-Instance unterbrochen wurden.

Wenn DB-Verbindungen während des RDS-Wartungsfensters unterbrochen werden

Während des Wartungsfensters der DB-Instance führt AWS Wartungsaktivitäten durch, die zum Ausfall von DB-Verbindungen führen können.

Automatisches Upgrade auf Nebenversion (falls auf Amazon RDS aktiviert)

Wenn Amazon RDS eine neue bevorzugte Engine-Nebenversion festlegt und auf Ihrer DB-Instance eine frühere Version läuft, führt Amazon RDS während des geplanten Wartungsfensters ein Upgrade durch, wenn Sie die Funktion Auto Minor Version Upgrade aktiviert haben. Dies kann zu Unterbrechungen der DB-Verbindungen während des Upgrades auf die Nebenversion führen, da jedes Upgrade der Engine-Version mit RDS-Ausfallzeiten verbunden ist.

Hardware-Wartung

Amazon RDS plant eine Hardware-Wartung, wenn die zugrunde liegenden Hosts Ihrer DB-Instances auf mangelhafter Hardware ausgeführt werden. Die Hardware-Wartung wird während des für die DB-Instances konfigurierten Wartungsfensters durchgeführt. Bevor die Wartung geplant wird, erhalten Sie eine E-Mail-Benachrichtigung über geplante Hardware-Wartungsfenster, die den Zeitpunkt der Wartung und die betroffenen Availability Zones enthält.

Wartung des Betriebssystems

Amazon RDS führt während des für Ihre DB-Instance konfigurierten Wartungsfensters regelmäßig Aktualisierungen des zugrunde liegenden Betriebssystems durch. Wenn das Betriebssystem-Update Ausfallzeiten mit sich bringt, plant Amazon RDS die Wartung für das nächste Wartungsfenster. Wenn das Betriebssystem-Update keine Wartung erfordert, können Sie das Wartungsfenster verschieben, indem Sie das bevorzugte Wartungsfenster anpassen. Wenn eine Wartung erforderlich ist, kann das Betriebssystem-Update nicht verschoben werden, und das Update wird während des folgenden Wartungsfensters angewendet.

In Amazon RDS durchgeführte Änderungen durch Auswahl von „Im nächsten Wartungsfenster anwenden“

Wenn Sie Änderungen an Ihrer RDS-Konfiguration vornehmen, können Sie wählen, ob Sie die Änderungen sofort oder im nächsten Wartungsfenster anwenden möchten. Wenn Sie sich dafür entscheiden, die Änderungen im nächsten Wartungsfenster durchzuführen, gibt es keine sofortige Ausfallzeit. Die folgenden Änderungen können zu Ausfallzeiten führen, wenn sie während des nächsten Wartungsfensters angewendet werden:

  • Umbenennen von DB-Instance-IDs
  • Ändern von DB-Instance-Klassen
  • Ändern der Aufbewahrungsfristen für Backups
  • Ändern von DB-Ports
  • Ändern der DB-Engine-Version
  • Anfügen einer neuen Subnetzgruppe

In den Informationen zu den DB-Instance-Einstellungen finden Sie detaillierte Einstellungen, die für Änderungen verfügbar sind, sowie die Auswirkungen und Ausfallzeiten von DB-Instances.

Wenn DB-Verbindungen außerhalb des RDS-Wartungsfensters unterbrochen werden

DB-Verbindungen werden möglicherweise unterbrochen, wenn die DB-Verbindungen das client-/serverseitige Timeout erreichen.

Auf Anwendungsseite konfigurierte Client-Timeout-Parameter

Auf Anwendungsseite konfigurierte Client-Timeout-Parameter können zum Ausfall von DB-Verbindungen führen. Wenn die Verarbeitungszeit einer Abfrage zu lang ist, wird die Sitzung vom Client möglicherweise falsch beendet. Um dieses Problem zu beheben, erhöhen Sie die Timeout-Einstellung des Clients.

In der an Amazon RDS angehängten benutzerdefinierten Parametergruppe konfigurierte Server-Timeout-Parameter

Aggressiv festgelegte TCP-Keepalives führen zu Timeouts bei der Client-Verbindung. Timeouts treten auf, wenn sich der Client für die in tcp_keepalives_idle festgelegte Zeit und die in tcp_keepalives_count festgelegte Anzahl von Nachrichten im Leerlauf befindet. Ein Timeout kann auch auftreten, wenn eine Verbindung auf eine Serverantwort wartet, während lang andauernde Abfragen auf der DB-Instance ausgeführt werden.

Wenn idle_in_transaction_session_timeout auf einen niedrigeren Wert als die standardmäßigen 24 Stunden festgelegt ist, wird jede Sitzung beendet, die länger als den konfigurierten Wert inaktiv war. Wenn Sie diesen Wert aggressiv festlegen, selbst wenn die ausgeführten Abfragen mehr Zeit benötigen, um eine Antwort vom Server zu erhalten, wird die Verbindung unterbrochen, wenn sich die Sitzung länger als der konfigurierte Timeout-Wert im Leerlauf befindet.

Ungeplanter DB-Neustart/Failover

Ein vorübergehendes Problem mit der zugrunde liegenden Hardware kann zum Verlust der Kommunikation mit der DB-Instance führen. Ein Hardwareproblem kann ein Failover in einer Multi-AZ-Bereitstellung und eine Wiederherstellung in einer Single-AZ-Bereitstellung auslösen, indem der zugrunde liegende Host ersetzt wird. Dieses Problem kann dazu führen, dass die DB-Instance fehlerhaft wird, da das RDS-Überwachungssystem nicht mit der RDS-Instance kommunizieren konnte, um die Zustandsprüfungen durchzuführen.

Ein vorübergehendes Netzwerkproblem wirkt sich auf den zugrunde liegenden Host Ihrer DB-Instance aus. Das interne Überwachungssystem erkennt dieses Problem und initiiert proaktiv die Wiederherstellung für eine Single-AZ-Bereitstellung und ein Failover für Multi-AZ-Bereitstellungen.

Die DB-Instance reagiert nicht mehr, wenn eine hohe DB-Auslastung zu einer Speicherknappheit in der Datenbank führt, die verhindert, dass das RDS-Überwachungssystem den zugrunde liegenden Host kontaktiert. Um ein Failover und einen Neustart Ihrer DB-Instance aufgrund einer Datenbanküberlastung zu vermeiden, konfigurieren Sie die Speicherparameter auf der DB-Instance entsprechend.

Ein vorübergehendes Problem mit dem zugrunde liegenden Speichersubsystem kann zu einer erhöhten Latenz für ein Volume im Amazon Elastic Block Store (Amazon EBS) führen, die von einem internen Überwachungssystem erkannt wird. Als proaktive Maßnahme leitet das Überwachungssystem die Wiederherstellung für eine Single-AZ-Bereitstellung ein. In einer Multi-AZ-Bereitstellung wird ein Failover zur sekundären Bereitstellung durchgeführt.


Relevante Informationen

Wie minimiere ich Ausfallzeiten während einer erforderlichen Amazon RDS-Wartung?

Arbeiten mit Betriebssystem-Updates

Wie behebe ich Probleme beim Herstellen einer Verbindung zu meiner Amazon-RDS-DB-Instance?

Wie führe ich die Ursachenanalyse für einen Multi-AZ-Failover und Neustart meiner Amazon-RDS-Instance durch?

AWS OFFICIAL
AWS OFFICIALAktualisiert vor 2 Jahren