Skalierung auf 0 ACUs mit automatischem Anhalten und Fortsetzen für Aurora Serverless v2 - Amazon Aurora
Überblick über die die Auto-Pause-Funktion Voraussetzungen und Einschränkungen Aktivieren und Deaktivieren der Auto-Pause-Funktion Funktionsweise der Auto-Pause-Funktion Auto-Pause-Funktion und Aurora-Cluster-Konfigurationen Auto-Pause bei der Überwachung Fehlerbehebung für die Auto-Pause-Funktion Anwendungsdesign für die Auto-Pause-Funktion

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.

Skalierung auf 0 ACUs mit automatischem Anhalten und Fortsetzen für Aurora Serverless v2

Sie können angeben, dass Aurora Serverless v2-DB-Instances auf 0 ACUs herunterskaliert und automatisch angehalten werden, wenn innerhalb eines bestimmten Zeitraums keine durch Benutzeraktivitäten initiierte Verbindungen vorhanden sind. Dazu geben Sie für Ihren DB-Cluster einen ACU-Mindestwert von 0 an. Ihnen wird die Instance-Kapazität nicht in Rechnung gestellt, solange sich eine Instance im angehaltenen Status befindet. Die Aktivierung der Funktion zum automatischen Anhalten und Fortsetzen (Auto-Pause) für Aurora-Cluster, die wenig genutzt werden oder längere Zeit inaktiv sind, kann Ihnen helfen, die Kosten für Ihre Datenbankflotte zu kontrollieren.

Anmerkung

Die Auto-Pause-Funktion ist für Aurora Serverless v2 mit Aurora PostgreSQL und Aurora MySQL verfügbar. Möglicherweise müssen Sie die Engine-Version Ihrer Aurora-Datenbank aktualisieren, um diese Funktion nutzen zu können. Informationen zu den Engine-Versionen, für die eine Mindestkapazität von 0 ACUs verfügbar ist, finden Sie unter Kapazität von Aurora Serverless v2.

Überblick über die Auto-Pause-Funktion von Aurora Serverless v2

Aurora Serverless v2-DB-Instances können nach einem Zeitraum ohne Benutzerverbindungen automatisch angehalten und automatisch fortgesetzt werden, wenn eine Verbindungsanfrage eingeht. Die Funktion zum automatischen Anhalten/Fortsetzen in Aurora Serverless v2 hilft bei der Kostenkontrolle für Systeme, die kein strenges Service Level Objective (SLO) haben. Sie können diese Funktion beispielsweise für Cluster aktivieren, die für Entwicklung und Tests verwendet werden, oder für interne Anwendungen, bei denen eine kurze Pause akzeptabel ist, während die Verbindung zur Datenbank wieder aufgenommen wird. Wenn Ihre Workload Phasen der Inaktivität aufweist und leichte Verzögerungen beim Verbindungsaufbau toleriert werden können, während die Verbindung zur Instance wieder aufgenommen wird, sollten Sie die Auto-Pause-Funktion für Ihre Aurora Serverless v2-Instances in Betracht ziehen, um die Kosten zu senken.

Sie steuern dieses Verhalten, indem Sie angeben, ob die Aurora Serverless v2-DB-Instances in einem Cluster automatisch angehalten werden können oder nicht und wie lange jede Instance inaktiv sein muss, bevor sie angehalten wird. Um das die Auto-Pause-Verhalten für alle Aurora Serverless v2-DB-Instances in einem Aurora-Cluster zu aktivieren, legen Sie den Mindestkapazitätswert für den Cluster auf 0 ACUs fest.

Wenn Sie zuvor die Aurora Serverless v1-Funktion genutzt haben, die nach einer gewissen Zeit der Inaktivität auf 0 ACUs skaliert hat, können Sie ein Upgrade auf Aurora Serverless v2 ausführen und die entsprechende Auto-Pause-Funktion verwenden.

Die Vorteile der Auto-Pause-Funktion zur Kosteneinsparung ähneln denen der Stop/Start-Funktion für Cluster. Das automatische Anhalten für Aurora Serverless v2 bietet den zusätzlichen Vorteil einer schnelleren Wiederaufnahme als das Starten eines gestoppten Clusters. Außerdem wird der Prozess automatisiert, mit dem bestimmt wird, wann jede DB-Instance angehalten und wieder fortgesetzt werden soll.

Die Auto-Pause-Funktion bietet außerdem zusätzliche Granularität bei der Kontrolle der Kosten für Rechenressourcen innerhalb Ihres Clusters. Sie können festlegen, dass einige Reader-Instances angehalten werden, auch wenn die Writer-Instance und andere Reader im Cluster jederzeit aktiv bleiben. Dazu weisen Sie den Reader-Instances, die unabhängig von anderen Instances angehalten werden können, eine Failover-Priorität im Bereich 2–15 zu.

Die Writer-Instance und alle Reader-Instances mit der Failover-Priorität 0 und 1 werden immer gleichzeitig angehalten und fortgesetzt. Daher werden die Instances in dieser Gruppe angehalten, nachdem keine von ihnen für das angegebene Zeitintervall Verbindungen hergestellt hat.

Aurora-DB-Cluster können eine Kombination aus Writer- und Reader-DB-Instances sowie bereitgestellten und Aurora Serverless v2-DB-Instances enthalten. Um diese Funktion effektiv nutzen zu können, ist es daher hilfreich, die folgenden Aspekte des Auto-Pause-Mechanismus zu kennen:

  • die Umstände, unter denen eine DB-Instance möglicherweise automatisch angehalten wird.

  • wann verhindert werden könnte, dass eine DB-Instance angehalten wird. Wenn Sie beispielsweise einige Aurora-Funktionen aktivieren oder bestimmte Arten von Vorgängen auf dem Cluster ausführen, können Instances möglicherweise nicht angehalten werden, auch wenn keine Verbindungen zu diesen Instances bestehen.

  • die Folgen für die Überwachung und Abrechnung, wenn eine Instance pausiert ist.

  • welche Aktionen bewirken, dass eine DB-Instance die Verarbeitung fortsetzt.

  • wie sich die Kapazität einer DB-Instance zum Zeitpunkt der Ereignisse zum Anhalten und Fortsetzen ändert.

  • wie Sie das Leerlaufintervall steuern, bevor eine DB-Instance angehalten wird.

  • wie Sie die Anwendungslogik so programmieren, dass sie den Zeitraum behandelt, in dem eine DB-Instance die Verarbeitung fortsetzt.

Voraussetzungen und Einschränkungen für die Auto-Pause-Funktion in Aurora Serverless v2

Bevor Sie die Auto-Pause-Funktion verwenden, überprüfen Sie, welche Engine-Versionen Sie verwenden möchten. Prüfen Sie außerdem, ob die Auto-Pause-Funktion in Kombination mit den anderen Aurora-Funktionen funktioniert, die Sie verwenden möchten. Sie können die Auto-Pause-Funktion nicht aktivieren, wenn Sie eine Engine-Version verwenden, die sie nicht unterstützt. Bei inkompatiblen Funktionen wird keine Fehlermeldung angezeigt, wenn Sie sie in Kombination mit der Auto-Pause-Funktion verwenden. Wenn der Cluster inkompatible Funktionen oder Einstellungen verwendet, werden die Aurora Serverless v2-Instances nicht automatisch angehalten.

Bestimmte Bedingungen oder Einstellungen verhindern, dass Aurora Serverless v2-Instances automatisch angehalten werden. Weitere Informationen finden Sie unter Situationen, in denen Aurora Serverless v2 nicht automatisch angehalten wird.

Aktivieren und Deaktivieren der Auto-Pause-Funktion

Sie können die Auto-Pause-Funktion auf Cluster-Ebene aktivieren und deaktivieren. Dazu verwenden Sie die gleichen Verfahren wie beim Anpassen der Mindest- und Höchstkapazität für den Cluster. Die Auto-Pause-Funktion wird durch eine Mindestkapazität von 0 ACUs dargestellt.

Aktivieren der Auto-Pause-Funktion für Aurora Serverless v2-Instances in einem Cluster

Folgen Sie dem Verfahren unter Festlegen des Aurora Serverless v2-Kapazitätsbereichs für einen Cluster. Wählen Sie als Mindestkapazität 0 ACUs aus. Wenn Sie eine Mindestkapazität von 0 ACUs auswählen, können Sie auch angeben, wie lange die Instance inaktiv sein soll, bevor sie automatisch angehalten wird.

Das folgende CLI-Beispiel zeigt, wie Sie einen Aurora-Cluster mit aktivierter Auto-Pause-Funktion und einem auf zehn Minuten (600 Sekunden) eingestellten Auto-Pause-Intervall erstellen. 

aws rds create-db-cluster \
    --db-cluster-identifier my-serverless-v2-cluster \
    --region eu-central-1 \
    --engine aurora-mysql \
    --engine-version 8.0 \
    --serverless-v2-scaling-configuration MinCapacity=0,MaxCapacity=4,SecondsUntilAutoPause=600 \
    --master-username myuser \
    --manage-master-user-password

Das folgende CLI-Beispiel zeigt, wie Sie die Auto-Pause-Funktion für einen vorhandenen Aurora-Cluster aktivieren. In diesem Beispiel wird das Auto-Pause-Intervall auf eine Stunde (3600 Sekunden) festgelegt. 

aws rds modify-db-cluster --db-cluster-identifier serverless-v2-cluster \
  --serverless-v2-scaling-configuration MinCapacity=0,MaxCapacity=80,SecondsUntilAutoPause=3600

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]'
{
    "MinCapacity": 0,
    "MaxCapacity": 80.0,
    "SecondsUntilAutoPause": 3600
}

Konfigurierbares Timeout-Intervall für die Auto-Pause-Funktion in Aurora Serverless v2

Das Timeout-Intervall wird im ServerlessV2ScalingConfiguration-Attribut Ihres Aurora-Clusters dargestellt. Sie können dieses Intervall beim Erstellen oder Ändern eines Aurora-Clusters in der AWS Management Console angeben, wenn die Mindestkapazität auf 0 ACUs festgelegt ist. Sie können es in der AWS CLI angeben, indem Sie den --serverless-v2-scaling-configuration-Parameter verwenden, wenn Sie einen Aurora-Cluster erstellen oder ändern. Sie können es in der RDS-API angeben, indem Sie den ServerlessV2ScalingConfiguration-Parameter verwenden, wenn Sie einen Aurora-Cluster erstellen oder ändern.

Das Mindestintervall, das Sie festlegen können, beträgt 300 Sekunden (fünf Minuten). Dies ist die Standardeinstellung, wenn Sie kein Intervall angeben. Das maximale Intervall, das Sie festlegen können, beträgt 86.400 Sekunden (einen Tag).

Angenommen, Sie deaktivieren die Auto-Pause-Funktion für einen Cluster, indem Sie die Mindestkapazität des Clusters auf einen Wert ungleich 0 ändern. In diesem Fall wird die Intervalleigenschaft aus dem ServerlessV2ScalingConfiguration-Attribut entfernt. Das Fehlen dieser Eigenschaft ist eine zusätzliche Bestätigung dafür, dass die Auto-Pause-Funktion für diesen Cluster deaktiviert ist. Wenn Sie die Auto-Pause-Funktion später wieder aktivieren, können Sie zu diesem Zeitpunkt erneut ein beliebiges benutzerdefiniertes Intervall angeben.

Fortsetzen einer automatisch angehaltenen Aurora Serverless v2-Instance

  • Wenn Sie eine Verbindung zu einer angehaltenen Aurora Serverless v2-Instance herstellen, wird die Verbindung automatisch fortgesetzt und akzeptiert.

  • Ein Verbindungsversuch, der keine gültigen Anmeldeinformationen enthält, führt dennoch dazu, dass die DB-Instance fortgesetzt wird.

  • Wenn Sie eine Verbindung über den Writer-Endpunkt herstellen, setzt Aurora die Writer-DB-Instance fort, falls sie automatisch angehalten wurde. Gleichzeitig setzt Aurora alle automatisch angehaltenen Reader-Instances fort, die die Failover-Priorität 0 oder 1 haben, was bedeutet, dass ihre Kapazität an die Kapazität der Writer-Instance gebunden ist.

  • Wenn Sie eine Verbindung über den Reader-Endpunkt herstellen, wählt Aurora nach dem Zufallsprinzip eine Reader-Instance aus. Wenn diese Reader-Instance angehalten ist, setzt Aurora sie fort. Aurora setzt außerdem zuerst die Writer-Instance fort, da die Writer-Instance immer aktiv sein muss, wenn Reader-Instances aktiv sind. Wenn Aurora diese Writer-Instance fortsetzt, führt dies auch dazu, dass alle Reader-Instances in den Failover-Hochstufungsstufen 0 und 1 fortgesetzt werden.

  • Wenn Sie über die RDS-Daten-API eine Anfrage an Ihren Cluster senden, setzt Aurora die Writer-Instance fort, falls sie angehalten wurde. Dann verarbeitet Aurora die Abfrage der Daten-API.

  • Wenn Sie den Wert eines Konfigurationsparameters in einer DB-Cluster-Parametergruppe ändern, setzt Aurora automatisch alle angehaltenen Aurora Serverless v2-Instances in allen Clustern fort, die diese Cluster-Parametergruppe verwenden. Wenn Sie einen Parameterwert in einer DB-Parametergruppe ändern, setzt Aurora entsprechend automatisch alle angehaltenen Aurora Serverless v2-Instances fort, die diese DB-Parametergruppe verwenden. Das gleiche Verhalten für das automatische Fortsetzen gilt, wenn Sie einen Cluster ändern, um eine andere Cluster-Parametergruppe zuzuweisen, oder wenn Sie eine Instance ändern, um eine andere DB-Parametergruppe zuzuweisen.

  • Wenn Sie eine Rückverfolgungsanfrage ausführen, wird die Aurora Serverless v2-Writer-Instance automatisch fortgesetzt, falls sie angehalten wurde. Aurora verarbeitet die Rückverfolgungsanfrage, nachdem die Writer-Instance fortgesetzt wurde. Sie können die Rückverfolgung zu einer Zeit ausführen, zu der eine Aurora Serverless v2-Instance angehalten war.

  • Das Erstellen eines Cluster-Snapshots oder das Löschen eines Snapshots führt nicht dazu, dass Aurora Serverless v2-Instances wieder aufgenommen werden.

  • Durch das Erstellen eines Aurora-Klons setzt Aurora die Writer-Instance des Clusters fort, der geklont wird.

  • Wenn eine angehaltene Instance eine große Anzahl von Verbindungsanfragen empfängt, bevor die Fortsetzung abgeschlossen ist, können einige Sitzungen möglicherweise keine Verbindung herstellen. Wir empfehlen, die Wiederholungslogik für Verbindungen zu Aurora-Clustern zu implementieren, bei denen einige Aurora Serverless v2-Instances mit aktivierter Auto-Pause-Funktion vorhanden sind. Sie können beispielsweise jede fehlgeschlagene Verbindung dreimal wiederholen.

  • Aurora kann einige Arten kleinerer interner Wartungsarbeiten durchführen, ohne eine Instance zu aktivieren. Für bestimmte Wartungsarten, die während des Wartungsfensters des Clusters durchgeführt werden, muss Aurora die Instance jedoch fortsetzen. Wenn die Wartung abgeschlossen ist, wird die Instance automatisch wieder angehalten, wenn nach dem angegebenen Intervall keine Aktivität mehr stattfindet.

    Anmerkung

    Aurora setzt eine angehaltene Instance für Engine-spezifische geplante Aufträge, wie die in der pg_cron-PostgreSQL-Erweiterung oder dem MySQL-Ereignisplaner, nicht automatisch fort. Um sicherzustellen, dass solche Aufträge ausgeführt werden, stellen Sie vor dem geplanten Zeitpunkt manuell eine Verbindung zur Instance her. Aurora stellt keine Aufträge in die Warteschlange, bei denen die geplante Zeit in der Zeit liegt, in der die DB-Instance angehalten ist. Solche Aufträge werden übersprungen, wenn die Instance später wieder fortgesetzt wird.

  • Wenn der Aurora-Cluster einen Failover durchläuft, während eine Aurora Serverless v2-Instance automatisch angehalten ist, setzt Aurora möglicherweise eine Instance fort und stuft diese Instance dann zum Writer hoch. Das Gleiche kann passieren, wenn eine oder mehrere DB-Instances aus dem Cluster entfernt werden, während eine Instance angehalten ist. In diesem Fall wird die Instance sofort zum Writer, wenn sie fortgesetzt wird.

  • Operationen, die die Eigenschaften des Clusters ändern, führen auch dazu, dass alle automatisch angehaltenen Aurora Serverless v2-Instances fortgesetzt werden. Beispielsweise wird eine automatisch angehaltene Instance für folgende Operationen fortgesetzt:

    • Ändern des Skalierungsbereichs des Clusters.

    • Aktualisieren der Engine-Version des Clusters.

    • Beschreiben oder Herunterladen von Protokolldateien aus einer angehaltenen Instance. Sie können historische Protokolldaten von angehaltenen Instances untersuchen, indem Sie Protokolluploads auf CloudWatch aktivieren und die Logs über CloudWatch analysieren.

Deaktivieren der Auto-Pause-Funktion für Aurora Serverless v2-Instances in einem Cluster

Folgen Sie dem Verfahren unter Festlegen des Aurora Serverless v2-Kapazitätsbereichs für einen Cluster. Wählen Sie als Mindestkapazität einen Wert von 0,5 oder höher aus. Wenn Sie die Auto-Pause-Funktion deaktivieren, wird das Intervall, in dem sich die Instance im Leerlauf befindet, zurückgesetzt. Wenn Sie die Auto-Pause-Funktion wieder aktivieren, geben Sie ein neues Timeout-Intervall an.

Das folgende CLI-Beispiel zeigt, wie Sie die Auto-Pause-Funktion für einen vorhandenen Aurora-Cluster deaktivieren. Die describe-db-clusters-Ausgabe zeigt, dass das SecondsUntilAutoPause-Attribut entfernt wird, wenn die Mindestkapazität auf einen Wert ungleich 0 gesetzt wird. 

aws rds modify-db-cluster --db-cluster-identifier serverless-v2-cluster \
  --serverless-v2-scaling-configuration MinCapacity=2,MaxCapacity=80

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]'
{
    "MinCapacity": 2,
    "MaxCapacity": 80.0
}

Funktionsweise der Auto-Pause-Funktion in Aurora Serverless v2

Sie können die folgenden Informationen verwenden, um Ihre Nutzung der Auto-Pause-Funktion zu planen. Wenn Sie wissen, unter welchen Umständen Instances angehalten oder fortgesetzt werden oder aktiv bleiben, können Sie ein ausgewogenes Verhältnis zwischen Verfügbarkeit, Reaktionsfähigkeit und Kosteneinsparungen finden.

Was passiert, wenn Aurora Serverless v2-Instances angehalten werden

Wenn eine Aurora Serverless v2-DB-Instance nach einem Zeitraum ohne Verbindungen angehalten wird:

  • Aurora beginnt, die Instance nach Ablauf des angegebenen Intervalls ohne Verbindungen zur Instance anzuhalten, unabhängig davon, wie viele ACUs die Instance zu diesem Zeitpunkt hat.

  • Das Anhalten erfolgt nicht sofort. Eine Aurora Serverless v2-Instance, die kurz davor steht, automatisch angehalten zu werden, wartet möglicherweise kurz, bis alle Änderungen am Aurora-Speicher übernommen wurden.

  • Die Instance-Gebühren für diese Instance werden ausgesetzt. Die ServerlessV2Usage-Metrik hat den Wert 0, während die Instance angehalten ist.

  • Der Statuswert für die Instance ändert sich nicht. Der Status wird weiterhin als „verfügbar“ angezeigt.

  • Die Instance beendet das Schreiben in die Datenbank-Protokolldateien. Sie sendet keine Metriken mehr an CloudWatch, außer dass null 0 Prozent für CPUUtilization und ACUUtilization sowie 0 für ServerlessDatabaseCapacity registriert werden.

  • Aurora gibt Ereignisse aus, wenn mit dem Anhalten einer Aurora Serverless v2-DB-Instance begonnen wird, das Anhalten beendet wird und wenn der Mechanismus zum Anhalten unterbrochen wird oder nicht erfolgreich ist. Weitere Informationen zu diesen Ereignissen finden Sie unter DB-Instance-Ereignisse.

Was passiert, wenn automatisch angehaltene Aurora Serverless v2-Instances fortgesetzt werden

Wenn eine Aurora Serverless v2-DB-Instance fortgesetzt wird, nachdem sie automatisch angehalten wurde, gilt Folgendes:

  • Alle Parameteränderungen, die sich in pending-reboot-Änderungen befinden, werden angewendet, wenn die Instance fortgesetzt wird.

  • Aurora gibt Ereignisse auf Instance-Ebene aus, wenn jede Aurora Serverless v2-DB-Instance mit dem Fortsetzen beginnt, das Fortsetzen beendet wird und wenn die Instance aus irgendeinem Grund nicht fortgesetzt werden kann. Weitere Informationen zu diesen Ereignissen finden Sie unter DB-Instance-Ereignisse.

  • Alle angeforderten Verbindungen werden hergestellt, nachdem die DB-Instance das Fortsetzen abgeschlossen hat. Da die typische Zeit für das Fortsetzen etwa 15 Sekunden betragen kann, empfehlen wir, dass Sie alle Einstellungen für das Client-Timeout so anpassen, dass sie länger als 15 Sekunden sind. Beispielsweise können Sie in Ihren JDBC-Treibereinstellungen die Werte für die Einstellungen connectTimeout und sslResponseTimeout so anpassen, dass sie länger als 15 Sekunden sind.

Anmerkung

Wenn eine Aurora Serverless v2-Instance länger als 24 Stunden angehalten wird, kann Aurora die Instance in einen tieferen Ruhezustand versetzen, bei dem das Fortsetzen länger dauert. In diesem Fall kann die Zeit bis zur Fortsetzung 30 Sekunden oder länger betragen, was in etwa einem Neustart der Instance entspricht. Wenn Ihre Datenbank Inaktivitätsperioden aufweist, die länger als einen Tag andauern, empfehlen wir, Verbindungs-Timeouts auf 30 Sekunden oder mehr festzulegen.

Funktionsweise der Instance-Abrechnung für automatisch angehaltene Aurora Serverless v2-Cluster

Während eine Aurora Serverless v2-Instance automatisch angehalten ist, ist ihre Instance-Gebühr gleich 0. Die ServerlessV2Usage-Metrik ist in diesem Zeitraum 0. AWS berechnet weiterhin Gebühren für Aurora-Speicher und andere Aspekte des Clusters, die nicht an diese spezifische DB-Instance gebunden sind.

Situationen, in denen Aurora Serverless v2 nicht automatisch angehalten wird

  • Wenn der Mindestkapazitätswert für Ihren DB-Cluster höher als 0 ACUs ist, werden die Aurora Serverless v2-Instances im Cluster nicht automatisch angehalten. Wenn Sie bereits Cluster mit Aurora Serverless v2-Instances aus der Zeit haben, als die Auto-Pause-Funktion noch nicht verfügbar war, lag die niedrigste Mindestkapazitätseinstellung bei 0,5 ACUs. Um die Auto-Pause-Funktion mit solchen Clustern zu verwenden, ändern Sie die Einstellung für die Mindestkapazität auf 0 ACUs.

  • Wenn vom Benutzer initiierte Verbindungen zu einer Aurora Serverless v2-Instance geöffnet sind, wird die Instance nicht angehalten. Die Instance wird auch nicht angehalten, während Aktivitäten wie Patches und Upgrades ausgeführt werden. Administrative Verbindungen, die Aurora für Zustandsprüfungen verwendet, werden nicht als Aktivität gezählt und verhindern nicht, dass die Instance angehalten wird.

  • In einem Aurora-PostgreSQL-Cluster, für den die logische Replikation aktiviert ist, oder in einem Aurora-MySQL-Cluster, für den die Binlog-Replikation aktiviert ist, werden die Writer-Instance und alle Reader-Instances in den Failover-Hochstufungsstufen 0 und 1 nicht automatisch angehalten. Aurora führt eine konstante Mindestanzahl von Aktivitäten aus, um den Zustand der Replikationsverbindung zu überprüfen.

    Für Cluster mit aktivierter Replikation können Sie weiterhin Aurora-Reader-Instances im Quell-Cluster haben, die automatisch angehalten werden. Setzen Sie dazu ihre Failover-Priorität auf einen anderen Wert als 0 oder 1. Auf diese Weise können sie unabhängig von der Writer-Instance angehalten werden.

  • Wenn Ihr Aurora-Cluster über einen zugehörigen RDS-Proxy verfügt, behält der Proxy eine offene Verbindung zu jeder DB-Instance im Cluster bei. Daher werden Aurora Serverless v2-Instances in einem solchen Cluster nicht automatisch angehalten.

  • Wenn Ihr Cluster der primäre Cluster in einer globalen Aurora-Datenbank ist, hält Aurora die Aurora Serverless v2-Writer-Instance nicht automatisch an. Das liegt daran, dass auf der Writer-Instance ein konstantes Aktivitätsniveau erforderlich ist, um die anderen Cluster in der globalen Datenbank zu verwalten. Da die Writer-Instance aktiv bleibt, werden auch alle Aurora Serverless v2-Reader-Instances mit der Failover-Priorität 0 oder 1 nicht automatisch angehalten.

  • Aurora Serverless v2-Instances in den sekundären Clustern einer globalen Aurora-Datenbank werden nicht automatisch angehalten. Wenn ein DB-Cluster zu einem eigenständigen Cluster heraufgestuft wird, wird die Auto-Pause-Funktion wirksam, sofern alle anderen Bedingungen erfüllt sind.

  • In einem Cluster mit einer zugehörigen Null-ETL-Integration zu Redshift werden die Writer-Instance und alle Reader-Instances in den Failover-Promotion-Hochstufungsstufen 0 und 1 nicht automatisch angehalten.

  • Wenn für eine Aurora PostgreSQL-Instance die Babelfish-Funktion aktiviert ist, verhindern alle Verbindungen und Aktivitäten am T-SQL-Port zusätzlich zur Aktivität auf dem Hauptdatenbankport für die Instance, dass die Instance automatisch angehalten wird.

Funktionsweise der Auto-Pause-Funktion mit der Stoppen/Starten-Funktion für Cluster

Sie können einen Aurora-Cluster beenden und starten, wenn die Auto-Pause-Funktion aktiviert ist. Es spielt keine Rolle, ob einige Instances angehalten sind. Wenn Sie den Cluster erneut starten, werden alle angehaltenen Aurora Serverless v2-Instances automatisch fortgesetzt.

Solange ein Aurora-Cluster gestoppt ist, werden angehaltene Aurora Serverless v2-Instances nicht automatisch aufgrund von Verbindungsversuchen fortgesetzt. Sobald der Cluster erneut gestartet wird, gelten die üblichen Mechanismen zum Anhalten und Fortsetzen von Aurora Serverless v2-Instances.

Funktionsweise von Wartung und Upgrades für automatisch angehaltene Aurora Serverless v2-Cluster

  • Wenn eine Aurora Serverless v2-Instance automatisch angehalten wurde und Sie versuchen, den Aurora-Cluster zu aktualisieren, setzt Aurora die Instance fort und aktualisiert sie.

  • Aurora setzt alle automatisch angehaltenen Aurora Serverless v2-Instances regelmäßig fort, um Wartungsarbeiten wie Unterversion-Upgrades und Änderungen an Eigenschaften wie Parametergruppen durchzuführen.

  • Nachdem eine Aurora Serverless v2-Instance für einen administrativen Vorgang wie ein Upgrade oder die Wartung wieder aktiviert wurde, wartet Aurora mindestens 20 Minuten, bevor diese Instance wieder angehalten wird. Dadurch können alle Hintergrundvorgänge abgeschlossen werden. Durch den Zeitraum von zwanzig Minuten wird außerdem vermieden, dass die Instance mehrmals angehalten und fortgesetzt wird, wenn auf der Instance mehrere Verwaltungsvorgänge nacheinander ausgeführt werden.

Unterschiede im Verhalten der Auto-Pause-Funktion zwischen Aurora Serverless v2 und Aurora Serverless v1

  • Die Fortsetzungszeit wurde in Aurora Serverless v2 im Vergleich zu Aurora Serverless v1 verbessert. Bis zur Fortsetzung dauert es in der Regel etwa 15 Sekunden, wenn die Instance für weniger als 24 Stunden angehalten wurde. Wenn die Instance länger als 24 Stunden angehalten ist, kann das Fortsetzen länger dauern.

  • Dadurch, wie Aurora Serverless v2 auf Multi-AZ-Cluster angewendet wird, können einige DB-Instances im Cluster möglicherweise angehalten sein, während andere aktiv sind. Die Writer-Instance wird immer dann fortgesetzt, wenn ein Reader ausgeführt wird, da der Writer zur Koordination bestimmter Aktivitäten innerhalb des Clusters benötigt wird. Da Aurora Serverless v1 keine Reader-Instances verwendet, wäre immer der gesamte Cluster angehalten oder aktiv.

  • Wenn der Reader-Endpunkt nach dem Zufallsprinzip eine Reader-Instance auswählt, zu der eine Verbindung hergestellt werden soll, ist diese Reader-Instance möglicherweise bereits aktiv oder wurde automatisch angehalten. Daher kann die Zeit für den Zugriff auf die Reader-Instance variieren und schwieriger vorherzusagen sein. Multi-AZ-Cluster, die Aurora Serverless v2 und die Auto-Pause-Funktion verwenden, könnten daher von der Einrichtung benutzerdefinierter Endpunkte für bestimmte schreibgeschützte Anwendungsfälle profitieren, anstatt alle schreibgeschützten Sitzungen an den Reader-Endpunkt weiterzuleiten.

  • Aurora Serverless v2-Instances werden mit derselben Häufigkeit wie bereitgestellte Instances Wartungsvorgängen unterzogen. Da Aurora Instances automatisch fortsetzt, wenn eine solche Wartung erforderlich ist, stellen Sie möglicherweise fest, dass Aurora Serverless v2-Instances häufiger fortgesetzt werden als Aurora Serverless v1-Cluster.

Funktionsweise der Auto-Pause-Funktion von Aurora Serverless v2 für verschiedene Arten von Aurora-Clustern

Die Überlegungen zur Auto-Pause-Funktion hängen davon ab, wie viele Instances sich in Ihrem Aurora-Cluster befinden, welche Failover-Hochstufungsstufen die Reader-Instances haben und ob alle Instances Aurora Serverless v2 oder eine Kombination von Aurora Serverless v2 und bereitgestellt sind.

Wenn die Auto-Pause-Funktion aktiviert ist, können Sie Ihren Aurora-Cluster so einrichten, dass er das richtige Gleichgewicht zwischen Hochverfügbarkeit, schneller Reaktion und Skalierbarkeit für Ihren Anwendungsfall bietet. Dazu wählen Sie die entsprechende Kombination aus Aurora Serverless v2-Instances, bereitgestellten Instances und Failover-Hochstufungsstufen für die DB-Instances in Ihrem Cluster aus.

Die folgenden Konfigurationstypen zeigen unterschiedliche Kompromisse zwischen Hochverfügbarkeit und Kostenoptimierung für Ihren Cluster:

  • Für ein Entwicklungs- und Testsystem können Sie einen Single-AZ-DB-Cluster mit einer Aurora Serverless v2-DB-Instance einrichten. Die einzelne Instance bearbeitet alle Lese- und Schreibanforderungen. Wenn der Cluster für längere Zeit nicht verwendet wird, wird die DB-Instance angehalten. Zu diesem Zeitpunkt werden auch die DB-Datenverarbeitungskosten für Ihren Cluster angehalten.

  • Für ein System, in dem eine Anwendung ausgeführt wird, bei der Hochverfügbarkeit Priorität hat, der Cluster aber immer noch Zeiten hat, in denen er vollständig inaktiv ist, können Sie einen Multi-AZ-Cluster einrichten, bei dem sowohl die Writer- als auch die Reader-DB-Instances Aurora Serverless v2 sind. Stellen Sie die Reader-Instance auf die Failover-Priorität 0 oder 1 ein, sodass die Writer- und die Reader-Instance gleichzeitig angehalten und fortgesetzt werden. Jetzt profitieren Sie von einem schnellen Failover, während der Cluster aktiv ist. Wenn der Cluster länger als der Auto-Pause-Schwellenwert inaktiv bleibt, werden die DB-Instance-Gebühren für beide Instances angehalten. Wenn der Cluster die Verarbeitung fortsetzt, benötigt die erste Datenbanksitzung eine kurze Zeit, um eine Verbindung herzustellen.

  • Angenommen, Ihr Cluster ist ständig mit einer minimalen Aktivität aktiv und erfordert eine schnelle Reaktion für jede Verbindung. In diesem Fall können Sie einen Cluster mit mehr als einer Aurora Serverless v2-Reader-Instance erstellen und die Kapazitäten einiger Reader-Instances vom Writer entkoppeln. Geben Sie die Failover-Priorität 0 oder 1 für die Writer-Instance und eine Reader-Instance an. Geben Sie für die anderen Reader-Instances eine Priorität größer 1 an. Auf diese Weise können die Reader-Instances der höheren Prioritätsstufen automatisch angehalten werden, auch wenn der Writer und einer der Reader aktiv bleiben.

    In diesem Fall können Sie einige andere Techniken einsetzen, um sicherzustellen, dass der Cluster kontinuierlich verfügbar bleibt und gleichzeitig in Leerlaufphasen auf eine niedrige Kapazität herunterskaliert wird:

    • Sie können bereitgestellte Instances für den Writer und den Reader mit Priorität 0 oder 1 verwenden. Auf diese Weise werden zwei DB-Instances nie automatisch angehalten und sind immer verfügbar, um den Datenbankverkehr zu verarbeiten und Failover durchzuführen.

    • Sie können einen benutzerdefinierten Endpunkt einrichten, der die Aurora Serverless v2-Instances der höheren Prioritätsstufen enthält, aber nicht den Writer oder die Reader der Hochstufungsstufen 0 oder 1. Auf diese Weise können Sie schreibgeschützte Sitzungen, die nicht latenzempfindlich sind, an die Reader weiterleiten, die möglicherweise automatisch angehalten werden. Sie können vermeiden, den Reader-Endpunkt für solche Anfragen zu verwenden, da Aurora Reader-Endpunktverbindungen möglicherweise an die Always-Awake-Reader-Instance oder an eine der automatisch angehaltenen Instances weiterleitet. Mithilfe des benutzerdefinierten Endpunkts können Sie Verbindungen zu verschiedenen Gruppen von Instances weiterleiten, je nachdem, ob Sie eine schnelle Reaktion oder zusätzliche Skalierungskapazität bevorzugen.

Funktionsweise der Auto-Pause-Funktion von Aurora Serverless v2 für die Writer-Instance in einem DB-Cluster

Wenn ein Aurora-DB-Cluster nur eine einzige DB-Instance enthält, ist der Mechanismus für das automatische Anhalten und Fortsetzen der DB-Instance unkompliziert. Er hängt nur von der Aktivität auf der Writer-Instance ab. Möglicherweise verfügen Sie über eine solche Konfiguration für Cluster, die für Entwicklung und Tests verwendet werden, oder für die Ausführung von Anwendungen, bei denen Hochverfügbarkeit nicht entscheidend ist. Beachten Sie, dass Aurora in einem Single-Instance-Cluster Verbindungen über den Reader-Endpunkt zur Writer-DB-Instance weiterleitet. Bei einem Single-Instance-DB-Cluster führt der Versuch, eine Verbindung mit dem Reader-Endpunkt herzustellen, dazu, dass die automatisch angehaltene Writer-DB-Instance fortgesetzt wird.

Die folgenden zusätzlichen Faktoren gelten für Aurora-Cluster mit mehreren DB-Instances:

  • In einem Aurora-DB-Cluster wird in der Regel häufig auf die Writer-DB-Instance zugegriffen. Daher stellen Sie möglicherweise fest, dass die Writer-DB-Instance auch dann aktiv bleibt, wenn eine oder mehrere der Reader-DB-Instances automatisch angehalten werden.

  • Bestimmte Aktivitäten auf den Reader-DB-Instances setzen voraus, dass diese Writer-DB-Instance verfügbar ist. Daher können die Writer-DB-Instances erst angehalten werden, wenn auch alle Reader-Instances angehalten wurden. Wenn Sie eine Reader-Instance fortsetzen, wird die Writer-Instance automatisch fortgesetzt, auch wenn Ihre Anwendung nicht direkt auf die Writer-Instance zugreift.

  • Aurora Serverless v2-Reader-Instances in den Failover-Hochstufungsstufen 0 und 1 werden skaliert, um ihre Kapazität mit der Writer-Instance synchron zu halten. Wenn also eine Aurora Serverless v2-Writer-Instance fortgesetzt wird, gilt dies auch für alle Aurora Serverless v2-Reader-Instances, die sich in den Hochstufungsstufen 0 und 1 befinden.

Funktionsweise der Auto-Pause-Funktion von Aurora Serverless v2 für Multi-AZ-Cluster

In einem Aurora-DB-Cluster, der sowohl eine Writer- als auch eine oder mehrere Reader-DB-Instances enthält, können einige Aurora Serverless v2-DB-Instances angehalten sein, während andere DB-Instances aktiv sind. Die Writer-Instance und alle Reader-Instances mit der Failover-Priorität 0 und 1 werden immer alle gleichzeitig angehalten und fortgesetzt. Reader-Instances mit einer anderen Priorität als 0 oder 1 können unabhängig von den anderen Instances angehalten und fortgesetzt werden.

Wenn Sie diese Funktion für Cluster mit mehreren Reader-Instances verwenden, können Sie die Kosten verwalten, ohne Abstriche bei der Hochverfügbarkeit machen zu müssen. Die Writer-Instance und ein oder zwei weitere Reader-Instances können jederzeit aktiv bleiben, während weitere Reader-Instances angehalten werden können, wenn sie nicht für das Verarbeiten von mit hohem Leseverkehrsvolumen benötigt werden.

Ob eine Reader-Instance automatisch angehalten werden kann, hängt davon ab, ob ihre Kapazität unabhängig skaliert werden kann oder ob die Kapazität an die Kapazität der Writer-DB-Instance gebunden ist. Diese Skalierungseigenschaft hängt von der Failover-Priorität der Reader-DB-Instance ab. Wenn die Priorität des Readers 0 oder 1 ist, verfolgt die Kapazität des Readers die Kapazität der Writer-DB-Instance. Damit Reader-DB-Instances in den unterschiedlichsten Situationen automatisch angehalten werden können, setzen Sie ihre Priorität daher auf einen höheren Wert als 1 fest.

Die Fortsetzung einer Reader-Instance kann etwas länger dauern als die Fortsetzung einer Writer-Instance. Stellen Sie eine Verbindung zum Cluster-Endpunkt her, um die schnellste Reaktion zu erhalten, falls Instances möglicherweise angehalten wurden.

Funktionsweise der Auto-Pause-Funktion von Aurora Serverless v2 für Cluster mit bereitgestellten Instances

Alle bereitgestellten DB-Instances in Ihrem Aurora-DB-Cluster werden nicht automatisch angehalten. Nur Aurora Serverless v2-DB-Instances mit der db.serverless-Instance-Klasse können die Auto-Pause-Funktion verwenden.

Wenn Ihr Aurora-Cluster bereitgestellte DB-Instances enthält, werden Aurora Serverless v2-Writer-Instances nicht automatisch angehalten. Das liegt an der Anforderung, dass die Writer-Instance verfügbar bleiben muss, solange Reader-Instances aktiv sind. Die Tatsache, dass der Aurora Serverless v2-Writer aktiv bleibt, bedeutet auch, dass alle Aurora Serverless v2-Reader-Instances mit der Failover-Priorität 0 und 1 in einem Hybrid-Cluster, der bereitgestellte Instances enthält, nicht automatisch angehalten werden.

Überwachung von Aurora-Clustern, die die Auto-Pause-Funktion verwenden

Um Aurora zu überwachen, sollten Sie bereits mit den Überwachungsverfahren in Überwachen von Amazon Aurora-Metriken mit Amazon CloudWatch und den unter Amazon Aurora-Referenz für Metriken aufgeführten CloudWatch-Metriken vertraut sein. Beachten Sie, dass bei der Überwachung von Aurora-Clustern, die die Auto-Pause-Funktion verwenden, einige besondere Überlegungen zu beachten sind:

  • Es kann Zeiträume geben, in denen Aurora Serverless v2-Instances Protokolldaten und die meisten Metriken nicht aufzeichnen, weil die Instances angehalten sind. Die einzigen Metriken, die an CloudWatch gesendet werden, während eine Instance angehalten ist, sind 0 Prozent für CPUUtilization und ACUUtilization und 0 für ServerlessDatabaseCapacity.

  • Sie können überprüfen, ob Aurora Serverless v2-Instances häufiger oder seltener angehalten werden als erwartet. Prüfen Sie dazu, wie oft sich die ServerlessDatabaseCapacity-Metrik von einem Wert ungleich 0 in 0 ändert und wie lange sie Null bleibt. Wenn die Instances nicht so lange angehalten werden, wie Sie es erwarten, sparen Sie nicht so viel an Kosten, wie Sie könnten. Wenn die Instances häufiger als beabsichtigt angehalten und fortgesetzt werden, kann es bei der Reaktion auf Verbindungsanfragen zu unnötiger Latenz in Ihrem Cluster kommen. Informationen zu den Faktoren, die beeinflussen, ob und wie oft Aurora Serverless v2-Instances angehalten werden können, finden Sie unter Voraussetzungen und Einschränkungen für die Auto-Pause-Funktion in Aurora Serverless v2, Situationen, in denen Aurora Serverless v2 nicht automatisch angehalten wird und Fehlerbehebung für die Auto-Pause-Funktion von Aurora Serverless v2.

  • Sie können auch eine Protokolldatei untersuchen, in der Vorgänge für das automatische Anhalten und Fortsetzen für eine Aurora Serverless v2-Instance aufgezeichnet werden. Wenn eine Instance nach Ablauf des Timeout-Intervalls nicht angehalten wurde, enthält diese Protokolldatei auch den Grund, warum das automatische Anhalten nicht stattgefunden hat. Weitere Informationen finden Sie unter Überwachen von Aurora Serverless v2-Aktivitäten zum Anhalten und Fortsetzen.

Überprüfen, ob eine Aurora Serverless v2-Instance angehalten wurde

Um festzustellen, ob sich eine Aurora Serverless v2-Instance im angehaltenen Zustand befindet, können Sie die ACUUtilization-Metrik für die Instance beobachten. Diese Metrik hat den Wert 0, während die Instance angehalten ist.

Während eine Aurora Serverless v2-Instance angehalten ist, wird ihr Statuswert immer noch als Verfügbar aufgeführt. Dasselbe gilt, wenn eine angehaltene Aurora Serverless v2-Instance gerade fortgesetzt wird. Das liegt daran, dass Sie erfolgreich eine Verbindung zu einer solchen Instance herstellen können, auch wenn es bei der Verbindung zu einer leichten Verzögerung kommt.

Alle Metriken, die sich auf die Verfügbarkeit von Aurora-Instances beziehen, berücksichtigen den Zeitraum, in dem die Instance angehalten ist, als Zeit, in der die Instance verfügbar war.

Ereignisse für die Operationen zum automatischen Anhalten und Fortsetzen

Aurora gibt Ereignisse für Aurora Serverless v2-Instances aus, wenn Operationen zum automatischen Anhalten oder Fortsetzen beginnen, beendet oder abgebrochen werden. Die Ereignisse im Zusammenhang mit der Auto-Pause-Funktion sind RDS-EVENT-0370 bis RDS-EVENT-0374. Weitere Informationen zu diesen Ereignissen finden Sie unter DB-Instance-Ereignisse.

Funktionsweise des automatischen Anhaltens mit Performance Insights und Enhanced Monitoring

Während eine Aurora Serverless v2-Instance angehalten ist, sammelt Aurora keine Monitoring-Informationen für diese Instance, weder über Performance Insights noch über Enhanced Monitoring. Wenn die Instance fortgesetzt wird, kann es zu einer kurzen Verzögerung kommen, bevor Aurora die Erfassung dieser Überwachungsinformationen wieder aufnimmt.

Interaktion der Auto-Pause-Funktion von Aurora Serverless v2 mit Aurora-Metriken

Während eine Aurora Serverless v2-Instance angehalten ist, gibt sie die meisten CloudWatch-Metriken nicht aus und schreibt auch keine Informationen in ihre Datenbankprotokolle. Die einzigen Metriken, die an CloudWatch gesendet werden, während eine Instance angehalten ist, sind 0 Prozent für CPUUtilization und ACUUtilization und 0 für ServerlessDatabaseCapacity.

Wenn CloudWatch Statistiken zur Verfügbarkeit und Betriebszeit von Instances oder Clustern berechnet, gelten Aurora Serverless v2-Instances während der Zeit, in der sie angehalten sind, als verfügbar.

Wenn Sie eine AWS CLI- oder eine RDS-API-Aktion initiieren, um die Protokolle für eine angehaltene Instance zu beschreiben oder herunterzuladen, wird die Aurora Serverless v2-Instance automatisch fortgesetzt, um die Protokollinformationen verfügbar zu machen.

Beispiel für CloudWatch-Metriken

Die folgenden AWS CLI-Beispiele zeigen, wie Sie beobachten können, wie sich die Kapazität einer Instance im Laufe der Zeit ändert. Während dieses Zeitraums wird die Instance automatisch angehalten und dann wieder fortgesetzt. Während der Pause meldet die ServerlessDatabaseCapacity-Metrik einen Wert von 0. Um festzustellen, ob die Instance zu irgendeinem Zeitpunkt während des Zeitraums angehalten war, prüfen wir, ob die Mindestkapazität in diesem Zeitraum 0 war.

Das folgende Linux-Beispiel zeigt eine Aurora Serverless v2-Instance, die für einige Zeit automatisch angehalten wurde. Wir testen ServerlessDatabaseCapacity jede Minute über einen Zeitraum von drei Minuten. Der ACU-Mindestwert von 0,0 bestätigt, dass die Instance zu einem Zeitpunkt in jeder Minute angehalten wurde. 


$ aws cloudwatch get-metric-statistics \
  --metric-name "ServerlessDatabaseCapacity" \
  --start-time "$(date -d '3 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
  --statistics Minimum \
  --namespace "AWS/RDS" --dimensions Name=DBInstanceIdentifier,Value=my-autopause-instance \
  --output text | sort -k 3

ServerlessDatabaseCapacity
DATAPOINTS	0.0	2024-08-02T22:11:00+00:00	None
DATAPOINTS	0.0	2024-08-02T22:12:00+00:00	None
DATAPOINTS	0.0	2024-08-02T22:13:00+00:00	None

Als Nächstes versuchen wir, eine Verbindung zu der angehaltenen Aurora Serverless v2-Instance herzustellen. In diesem Beispiel verwenden wir absichtlich ein falsches Passwort, sodass der Verbindungsversuch nicht erfolgreich ist. Trotz des Fehlers veranlasst der Verbindungsversuch Aurora, die angehaltene Instance fortzusetzen. 


$ mysql -h my_cluster_endpoint.rds.amazonaws.com -u admin -pwrong-password

ERROR 1045 (28000): Access denied for user 'admin'@'ip_address' (using password: YES)

Das folgende Linux-Beispiel zeigt, dass die angehaltene Instance fortgesetzt wurde, etwa fünf Minuten lang inaktiv blieb und dann wieder in den angehaltenen Zustand zurückkehrte. Die Instance wurde mit einer Kapazität von 2,0 ACUs fortgesetzt. Dann wurde sie leicht hochskaliert, beispielsweise um eine interne Bereinigung durchzuführen. Da innerhalb des fünfminütigen Timeouts keine Benutzerverbindungsversuche eingingen, ging die Instance von 4,0 ACUs direkt in den angehaltenen Zustand über. 


$ aws cloudwatch get-metric-statistics \
  --metric-name "ServerlessDatabaseCapacity" \
  --start-time "$(date -d '8 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
  --statistics Minimum \
  --namespace "AWS/RDS" --dimensions Name=DBInstanceIdentifier,Value=my-autopause-instance \
  --output text | sort -k 3

ServerlessDatabaseCapacity
DATAPOINTS	0.0	2024-08-02T22:13:00+00:00	None
DATAPOINTS	2.0	2024-08-02T22:14:00+00:00	None
DATAPOINTS	3.0	2024-08-02T22:15:00+00:00	None
DATAPOINTS	3.0	2024-08-02T22:16:00+00:00	None
DATAPOINTS	4.0	2024-08-02T22:17:00+00:00	None
DATAPOINTS	4.0	2024-08-02T22:18:00+00:00	None
DATAPOINTS	4.0	2024-08-02T22:19:00+00:00	None
DATAPOINTS	0.0	2024-08-02T22:20:00+00:00	None

Wenn der Bericht zeigen soll, wie schnell die Instance hochskaliert wurde, um die Workload zu bewältigen, können wir Maximum statt Minimum für die Statistik angeben. Für die Kapazitätsplanung und Kostenschätzung können wir einen längeren Zeitraum angeben und die Average-Statistik verwenden. Auf diese Weise können wir typische Kapazitätswerte in Zeiten hoher Aktivität, geringer Aktivität und im angehaltenen Zustand ermitteln. Um das Verhalten genau zu den Zeiten des Anhaltens und Fortsetzens zu untersuchen, können wir einen Zeitraum von einer Sekunde angeben und ein kürzeres Zeitintervall untersuchen. Die Zeitstempelwerte in der Ausgabe, z. B. 2024-08-02T22:13:00+00:00, demonstrieren das Format zur Angabe genauer Parameter für die Optionen --start-time und --end-time.

Fehlerbehebung für die Auto-Pause-Funktion von Aurora Serverless v2

Wenn Sie feststellen, dass Aurora Serverless v2-Instances nicht so oft angehalten werden wie erwartet, suchen Sie nach den folgenden möglichen Ursachen:

  • Vergewissern Sie sich, dass die Aurora-Version, die Sie verwenden, eine Mindestkapazität von 0 ACUs unterstützt. Informationen zu den Kapazitätsbereichen der verschiedenen Aurora-Versionen finden Sie unter Kapazität von Aurora Serverless v2.

  • Vergewissern Sie sich, dass der Mindestkapazitätswert für den Cluster auf 0 ACUs festgelegt ist.

  • Vergewissern Sie sich, dass die fragliche Instance tatsächlich die Aurora Serverless v2-Instance-Klasse db.serverless und keine der bereitgestellten Instance-Klassen verwendet.

  • Vergewissern Sie sich, dass der Cluster keine der inkompatiblen Funktionen oder Einstellungen von Voraussetzungen und Einschränkungen für die Auto-Pause-Funktion in Aurora Serverless v2 verwendet.

  • Untersuchen Sie die Protokolldatei, aus der hervorgeht, wann Aurora Serverless v2-Instances angehalten oder fortgesetzt wurden oder Aurora eine Instance aus irgendeinem Grund nicht anhalten oder fortsetzen konnte. Weitere Informationen finden Sie unter Überwachen von Aurora Serverless v2-Aktivitäten zum Anhalten und Fortsetzen.

  • Überprüfen Sie, ob Clients oder Anwendungen die Verbindungen über einen langen Zeitraum geöffnet halten. Prüfen Sie umgekehrt, ob Anwendungen, die die RDS-Daten-API oder Lambda-Funktionen verwenden, häufig Anfragen senden, sodass die Instance nie lange genug inaktiv ist, um angehalten zu werden. Sie können die CloudWatch-Metriken wie ConnectionAttempts und DatabaseConnections untersuchen. Weitere Informationen finden Sie unter Metriken auf Instance-Ebene für Amazon Aurora.

  • Wenn eine Reader-Instance selten oder nie angehalten wird, überprüfen Sie ihre Failover-Priorität. Wenn der Reader für die Leseskalierung und nicht als Standby im Falle eines Failovers verwendet wird, legen Sie dafür eine Priorität im Bereich von 2 bis 15 fest.

  • Wenn die Writer-Instance selten oder nie angehalten wird, überprüfen Sie Ihre Nutzung der Reader-Instances. Der Writer kann nur angehalten werden, wenn der gesamte Cluster inaktiv ist. Das liegt daran, dass eine Verbindung zu einer beliebigen Reader-Instance dazu führt, dass der Writer fortgesetzt wird.

  • Wenn Ihre Anwendung bei Verbindungsanfragen Timeouts erhält, während die Aurora Serverless v2-Instances fortgesetzt werden, sollten Sie erwägen, das von Ihrem Anwendungscode oder dem zugrunde liegenden Datenbank-Framework verwendete Timeout-Intervall zu verlängern. Längere Verbindungs-Timeouts verringern die Wahrscheinlichkeit, dass Verbindungen während der Fortsetzung von Aurora Serverless v2-Instances fehlschlagen. Die längeren Timeouts können jedoch auch dazu führen, dass Ihre Anwendung Verfügbarkeitsprobleme in Ihrem Cluster langsamer erkennt.

    Umgekehrt sollten Sie erwägen, das Auto-Pause-Intervall zu verlängern, damit Anwendungen nicht so oft auf angehaltene Instances stoßen.

    Wenn für Ihre Anwendung kein logisches Gleichgewicht zwischen dem Auto-Pause-Verhalten und der Reaktionsfähigkeit des Clusters besteht, ist dieser Cluster möglicherweise kein geeigneter Kandidat für die Verwendung der Auto-Pause-Funktion.

  • Wenn Sie abschätzen, wie lange Ihre Aurora Serverless v2-Instances angehalten werden, sollten Sie sich darüber im Klaren sein, dass es bestimmte Faktoren gibt, durch die genaue Vorhersagen schwierig sind.

    • Instances können regelmäßig fortgesetzt werden, um Wartungsarbeiten oder Unterversion-Upgrades durchzuführen oder Änderungen an Parametergruppen vorzunehmen.

    • Bei Multi-AZ-Clustern gibt es Situationen, in denen das Fortsetzen einer Instance dazu führt, dass auch andere Instances fortgesetzt werden. Das Fortsetzen eines Readers führt immer dazu, dass der Writer fortgesetzt wird. Wenn der Writer fortgesetzt wird, werden immer alle Reader mit der Failover-Priorität 0 und 1 fortgesetzt.

    Wir empfehlen, die tatsächliche Dauer des angehaltenen Zustands über einen Zeitraum von mehreren Tagen mit einer realistischen Workload zu messen. Verwenden Sie dann diese Messungen, um eine Baseline für den Anteil der Zeit festzulegen, in dem Sie erwarten können, dass eine Instance angehalten ist.

  • Möglicherweise stellen Sie fest, dass interne Operationen wie die MySQL-Bereinigung, der MySQL-Ereignisplaner, die PostgreSQL-Selbstbereinigung oder PostgreSQL-Aufträge, die über die pg_cron-Erweiterung geplant wurden, nicht ausgeführt oder abgeschlossen werden. Die Instance setzt die Ausführung solcher Operationen, für die keine Benutzerverbindung zur Datenbank erforderlich ist, nicht automatisch fort. Wenn solche internen Operationen nach Ablauf des Auto-Pause-Timeouts ausgeführt werden, werden Wartungsaufgaben wie die MySQL-Bereinigung und PostgreSQL-Selbstbereinigung abgebrochen. Geplante Aufträge aus dem MySQL-Ereignisplaner oder der pg_cron-PostgreSQL-Erweiterung werden ebenfalls abgebrochen, falls sie in Bearbeitung sind, wenn Aurora die Operation zum Anhalten initiiert.

    Wenn Sie sicherstellen müssen, dass die Instance regelmäßig aktiv ist, um geplante Operationen auszuführen, können Sie vor der Startzeit des Auftrags eine Verbindung herstellen, um die Instance fortzusetzen. Sie können auch das Timeout-Intervall für die Auto-Pause-Funktion erhöhen, sodass Operationen wie die Selbstbereinigung länger ausgeführt werden können, nachdem die Benutzeraktivität beendet wurde. Sie können auch Mechanismen wie Lambda-Funktionen verwenden, um Datenbankoperationen nach einem Zeitplan auszuführen, sodass die Instance bei Bedarf automatisch fortgesetzt wird.

Überlegungen zum Anwendungsdesign für die Auto-Pause-Funktion von Aurora Serverless v2

Wenn eine Aurora Serverless v2-DB-Instance fortgesetzt wird, nachdem sie automatisch angehalten wurde, beginnt sie mit einer relativ geringen Kapazität und wird von dort aus hochskaliert. Diese Startkapazität gilt auch dann, wenn die DB-Instance unmittelbar, bevor sie automatisch angehalten wurde, über eine höhere Kapazität verfügte.

Verwenden Sie diese Funktion für Anwendungen, die beim Verbindungsaufbau ein Intervall von etwa 15 Sekunden tolerieren können. Dies entspricht dem typischen Fall, dass eine Aurora Serverless v2-Instance aufgrund einer oder einer geringen Anzahl eingehender Verbindungen fortgesetzt wird. Wenn die Instance länger als 24 Stunden angehalten war, kann das Fortsetzen länger dauern.

Wenn Ihre Anwendung Aurora Serverless v1 und die Funktion zum automatischen Anhalten bereits verwendet hat, haben Sie möglicherweise bereits solche Timeout-Intervalle für Verbindungsversuche eingerichtet. Wenn Sie bereits Aurora Serverless v2 in Kombination mit der Aurora-Stop/Start-Funktion für Cluster verwenden, ist die Zeit für das Fortsetzen automatisch angehaltener Aurora Serverless v2-Instances in der Regel viel kürzer als die Zeit zum Starten eines gestoppten Clusters.

Wenn Sie die Verbindungslogik in Ihrer Anwendung codieren, versuchen Sie, die Verbindung erneut herzustellen, wenn beim ersten Versuch ein Fehler auftritt, der eine vorübergehende Ursache hat. (Falls der Fehler auf einen Authentifizierungsfehler zurückzuführen ist, korrigieren Sie die Anmeldeinformationen, bevor Sie es erneut versuchen.) Ein Fehler, der unmittelbar nach dem Fortsetzen auftritt, kann ein Timeout oder ein Fehler im Zusammenhang mit Datenbanklimits sein. Durch den erneuten Versuch können Probleme in den selteneren Fällen gelöst werden, in denen eine Aurora Serverless v2-Instance aufgrund einer hohen Anzahl gleichzeitiger Verbindungsanfragen fortgesetzt wird. In diesem Fall kann die Verarbeitung einiger Verbindungen länger als gewöhnlich dauern oder beim ersten Versuch die maximale Anzahl gleichzeitiger Verbindungen überschritten werden.

Lassen Sie während der Anwendungsentwicklung und beim Debuggen keine Clientsitzungen oder Programmiertools mit Verbindungen zur Datenbank offen. Aurora hält eine Instance nicht an, wenn vom Benutzer initiierte Verbindungen geöffnet sind, auch wenn die Verbindungen keine SQL-Anweisungen oder Transaktionen ausführen. Wenn eine Aurora Serverless v2-Instance in einem Aurora-Cluster nicht angehalten werden kann, können auch andere Instances im Cluster daran gehindert werden, angehalten zu werden. Weitere Informationen finden Sie unter Situationen, in denen Aurora Serverless v2 nicht automatisch angehalten wird.

Aurora gibt Ereignisse aus, wenn eine Aurora Serverless v2-DB-Instance mit dem Fortsetzen beginnt, das Fortsetzen beendet wird und wenn die Instance aus irgendeinem Grund nicht fortgesetzt werden kann. Weitere Informationen zu diesen Ereignissen finden Sie unter DB-Instance-Ereignisse.