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 Null ACUs mit automatischer Pause und Wiederaufnahme für Aurora Serverless v2

Das können Sie angeben Aurora Serverless v2 DB-Instances werden auf Null herunterskaliert ACUs und automatisch angehalten, wenn innerhalb eines bestimmten Zeitraums keine durch Benutzeraktivitäten initiierten Verbindungen hergestellt wurden. Sie tun dies, indem Sie einen ACU Mindestwert von Null für Ihren DB-Cluster angeben. Die Instance-Kapazität wird Ihnen nicht in Rechnung gestellt, solange sich eine Instance im angehaltenen Zustand befindet. Die Aktivierung der automatischen Funktion zum Anhalten und Wiederaufnehmen (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.

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

Aurora Serverless v2 DB-Instances können nach einem Zeitraum ohne Benutzerverbindungen automatisch angehalten und automatisch wieder aufgenommen werden, wenn eine Verbindungsanfrage eingeht. Das Tool Aurora Serverless v2 Die automatische Funktion zum Anhalten/Wiederaufnehmen hilft dabei, die Kosten für Systeme zu kontrollieren, für die kein striktes Service Level Objective () SLO festgelegt ist. 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 während der Wiederaufnahme der Datenbank akzeptabel ist. Wenn Ihr Workload Phasen der Inaktivität aufweist und leichte Verzögerungen bei der Verbindungsherstellung toleriert werden können, während die Instance wieder aufgenommen wird, sollten Sie die automatische Pause mit Ihrem Aurora Serverless v2 Instanzen zur Kostensenkung.

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

Wenn Sie früher die Vorteile genutzt haben Aurora Serverless v1 Funktion, die ACUs nach einer gewissen Zeit der Inaktivität auf Null skaliert wurde, können Sie upgraden auf Aurora Serverless v2 und verwenden Sie die entsprechende Auto-Pause-Funktion.

Die Vorteile der Auto-Pause-Funktion zur Kosteneinsparung ähneln denen der Stop/Start-Cluster-Funktion. Automatische Pause für Aurora Serverless v2 bietet die zusätzlichen Vorteile einer schnelleren Wiederaufnahme als beim Starten eines gestoppten Clusters und der Automatisierung des Prozesses, bei dem bestimmt wird, wann jede DB-Instance angehalten und wieder aufgenommen werden muss.

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 pausieren können, eine Failover-Priorität im Bereich 2-15 zu.

Die Writer-Instanzen und alle Reader-Instanzen mit der Failover-Priorität 0 und 1 werden immer gleichzeitig angehalten und fortgesetzt. Daher werden die Instanzen in dieser Gruppe angehalten, nachdem für das angegebene Zeitintervall keine Verbindung mehr hergestellt wurde.

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

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

Bevor Sie die Auto-Pause-Funktion verwenden, überprüfen Sie, welche Engine-Versionen Sie verwenden möchten. Prüfen Sie außerdem, ob die automatische Pause in Kombination mit den anderen Aurora-Funktionen funktioniert, die Sie verwenden möchten. Sie können die automatische Pause 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 automatischen Pause verwenden. Wenn der Cluster inkompatible Funktionen oder Einstellungen verwendet, Aurora Serverless v2 Instanzen werden nicht automatisch angehalten.

Bestimmte Bedingungen oder Einstellungen verhindern Aurora Serverless v2 Instanzen können nicht automatisch angehalten werden. Weitere Informationen finden Sie unter Situationen, in denen Aurora Serverless v2 pausiert nicht automatisch.

Ein- und Ausschalten der Auto-Pause-Funktion

Sie können die Auto-Pausen-Funktion auf Cluster-Ebene ein- und ausschalten. Dazu verwenden Sie dieselben 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.

Automatische Pause einschalten für Aurora Serverless v2 Instanzen in einem Cluster

Folgen Sie dem Verfahren unter Einstellung der Aurora Serverless v2 Kapazitätsbereich für einen Cluster. Wählen Sie für die Mindestkapazität 0 ACUs aus. Wenn Sie eine Mindestkapazität von 0 wählenACUs, 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-Pausen-Intervall erstellen könnten.

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 können. In diesem Beispiel wird das Intervall für die automatische Pause 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
}

Konfigurierbar Aurora Serverless v2 Timeout-Intervall für automatische Pause

Das Timeout-Intervall wird im ServerlessV2ScalingConfiguration Attribut Ihres Aurora-Clusters dargestellt. Sie können dieses Intervall AWS Management Console beim Erstellen oder Ändern eines Aurora-Clusters angeben, wenn die Mindestkapazität auf Null gesetzt istACUs. Sie können es in der angeben, AWS CLI indem Sie den --serverless-v2-scaling-configuration Parameter verwenden, wenn Sie einen Aurora-Cluster erstellen oder ändern. Sie können es in der angeben, RDS API 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). Das ist die Standardeinstellung, wenn Sie kein Intervall angeben. Das maximale Intervall, das Sie festlegen können, beträgt 86.400 Sekunden (ein Tag).

Angenommen, Sie deaktivieren die Funktion zum automatischen Anhalten für einen Cluster, indem Sie die Mindestkapazität des Clusters auf einen Wert ungleich Null ä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 ausgeschaltet ist. Wenn Sie die automatische Pause später wieder einschalten, können Sie zu diesem Zeitpunkt erneut ein beliebiges benutzerdefiniertes Intervall angeben.

Wiederaufnahme einer automatisch angehaltenen Aurora Serverless v2 Instance

Automatische Pause ausschalten für Aurora Serverless v2 Instanzen in einem Cluster

Folgen Sie dem Verfahren unter Einstellung der Aurora Serverless v2 Kapazitätsbereich für einen Cluster. Wählen Sie für die Mindestkapazität einen Wert von 0,5 oder mehr. Wenn Sie die Auto-Pause-Funktion ausschalten, wird das Intervall, in dem sich die Instance im Leerlauf befindet, zurückgesetzt. Wenn Sie die automatische Pause wieder einschalten, 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 können. Die describe-db-clusters Ausgabe zeigt, dass das SecondsUntilAutoPause Attribut entfernt wird, wenn die Mindestkapazität auf einen Wert ungleich Null 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
}

Wie Aurora Serverless v2 Die Auto-Pause-Funktion funktioniert

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

Was passiert wann Aurora Serverless v2 Instanzen pausieren

Wann ein Aurora Serverless v2 Die DB-Instance wird nach einem Zeitraum ohne Verbindungen angehalten:

Was passiert, wenn es automatisch angehalten wird Aurora Serverless v2 Instanzen werden wieder aufgenommen

Wann ein Aurora Serverless v2 Die DB-Instance wird wieder aufgenommen, nachdem sie automatisch angehalten wurde, und es gelten die folgenden Bedingungen:

So funktioniert die Instanzabrechnung für automatisch pausierte Aurora Serverless v2 Cluster

Während eines Aurora Serverless v2 Die Instanz wird automatisch angehalten, ihre Instanzgebühr ist Null. Die ServerlessV2Usage Metrik ist in diesem Zeitraum Null. AWS Es fallen weiterhin Gebühren für Aurora-Speicher und andere Aspekte des Clusters an, die nicht an diese spezifische DB-Instance gebunden sind.

Situationen, in denen Aurora Serverless v2 pausiert nicht automatisch

So funktioniert die automatische Pause mit der Cluster-Stop-/Start-Funktion

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

Während ein Aurora-Cluster gestoppt ist, wird jeder angehalten Aurora Serverless v2 Instances werden aufgrund von Verbindungsversuchen nicht automatisch wieder aufgenommen. Sobald der Cluster erneut gestartet wird, gelten die üblichen Mechanismen für das Anhalten und Wiederaufnehmen Aurora Serverless v2 Instanzen gelten.

So funktionieren Wartung und Upgrades bei automatisch angehaltenen Aurora Serverless v2 Cluster

Unterschiede im Verhalten beim automatischen Pausieren zwischen Aurora Serverless v2 and Aurora Serverless v1

Wie Aurora Serverless v2 Auto-Pause funktioniert 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-Promotion-Stufen die Reader-Instances haben und ob alle Instances Aurora Serverless v2 oder eine Kombination aus Aurora Serverless v2 und bereitgestellt.

Empfohlene Aurora-Cluster-Layouts bei Verwendung von Auto-Pause

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. Sie tun dies, indem Sie die Kombination von wählen Aurora Serverless v2 Instances, bereitgestellte Instances und Failover-Promotion-Stufen für die DB-Instances in Ihrem Cluster.

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

Wie Aurora Serverless v2 Auto-Pause funktioniert für die Writer-Instanz 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 Wiederaufnehmen der DB-Instance unkompliziert. Dies 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 Einzelinstanz-DB-Cluster führt der Versuch, eine Verbindung zum Leser-Endpunkt herzustellen, dazu, dass die automatisch angehaltene Writer-DB-Instance wieder aufgenommen wird.

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

Wie Aurora Serverless v2 Auto-Pause funktioniert für Multi-AZ-Cluster

Innerhalb eines Aurora-DB-Clusters, der sowohl eine Writer- als auch eine oder mehrere Reader-DB-Instances enthält, einige Aurora Serverless v2 DB-Instances können angehalten werden, während andere DB-Instances aktiv sind. Die Writer-Instance und alle Reader-Instances mit der Failover-Priorität 0 und 1 werden immer gleichzeitig angehalten und fortgesetzt. Reader-Instances mit einer anderen Priorität als 0 oder 1 können unabhängig von den anderen Instanzen 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 den Umgang mit hohem Leseverkehr 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 Lesers Null oder Eins ist, entspricht die Kapazität des Lesegeräts der Kapazität der Writer-DB-Instance. Damit Leser-DB-Instances in den unterschiedlichsten Situationen automatisch pausieren können, setzen Sie ihre Priorität daher auf einen höheren Wert als eins.

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

Wie Aurora Serverless v2 Auto-Pause funktioniert für Cluster mit bereitgestellten Instanzen

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, Aurora Serverless v2 Die Writer-Instance wird nicht automatisch angehalten. Das liegt an der Anforderung, dass die Writer-Instanz verfügbar bleibt, solange alle Reader-Instanzen aktiv sind. Die Tatsache, dass Aurora Serverless v2 Der Autor bleibt aktiv, bedeutet auch, dass jeder Aurora Serverless v2 Reader-Instances mit der Failover-Priorität 0 und 1 werden in einem Hybrid-Cluster, der bereitgestellte Instanzen enthält, nicht automatisch angehalten.

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

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

Es wird geprüft, ob ein Aurora Serverless v2 Instanz ist angehalten

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

Während ein Aurora Serverless v2 Die Instanz ist angehalten, ihr Statuswert wird immer noch als Verfügbar aufgeführt. Das Gleiche gilt, wenn eine angehaltene Aurora Serverless v2 Die Instanz wird gerade wieder aufgenommen. Das liegt daran, dass Sie erfolgreich eine Verbindung zu einer solchen Instanz 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 wurde, als Zeit, in der die Instance verfügbar war.

Ereignisse für automatische Pause- und automatische Wiederaufnahme von Vorgängen

Aurora sendet Ereignisse für Aurora Serverless v2 Instanzen, in denen die automatische Pause und automatische Wiederaufnahme von Vorgängen gestartet, beendet oder abgebrochen werden. Die Ereignisse im Zusammenhang mit der Auto-Pause-Funktion sind abgeschlossenRDS-EVENT-0370. RDS-EVENT-0374 Einzelheiten zu diesen Ereignissen finden Sie unterDB-Instance-Ereignisse.

So funktioniert die automatische Pause mit Performance Insights und Enhanced Monitoring

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

Wie Aurora Serverless v2 Die Auto-Pause-Funktion interagiert mit Aurora-Metriken

Während ein Aurora Serverless v2 Eine Instanz ist angehalten, gibt aber die meisten CloudWatch Metriken nicht aus und schreibt auch keine Informationen in ihre Datenbankprotokolle. Die einzigen Messwerte, an die gesendet werden, CloudWatch während eine Instanz angehalten istACUUtilization, sind null Prozent für CPUUtilization und und Null für. ServerlessDatabaseCapacity

Wann beziehen CloudWatch sich Rechenstatistiken auf die Verfügbarkeit und Verfügbarkeit von Instances oder Clustern, Aurora Serverless v2 Instances gelten während der Zeit, in der sie angehalten wurden, als verfügbar.

Wenn Sie eine AWS CLI RDS API OR-Aktion initiieren, um die Logs für eine angehaltene Datei zu beschreiben oder herunterzuladen Aurora Serverless v2 Die Instanz wird automatisch wieder aufgenommen, um die Protokollinformationen verfügbar zu machen.

Beispiel für Metriken CloudWatch

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 Instanz automatisch angehalten und dann wieder aufgenommen. Während der Pause meldet die ServerlessDatabaseCapacity Metrik einen Wert von Null. Um festzustellen, ob die Instance zu irgendeinem Zeitpunkt während des Zeitraums angehalten wurde, prüfen wir, ob die Mindestkapazität in diesem Zeitraum Null war.

Das folgende Linux-Beispiel stellt eine Aurora Serverless v2 Instanz, die für einige Zeit automatisch angehalten wurde. Wir testen sie ServerlessDatabaseCapacity jede Minute über einen Zeitraum von drei Minuten. Der ACU Mindestwert von 0,0 bestätigt, dass die Instanz zu einem bestimmten 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 zur angehaltenen Datei herzustellen Aurora Serverless v2 sein. In diesem Beispiel verwenden wir absichtlich ein falsches Passwort, sodass der Verbindungsversuch nicht erfolgreich ist. Trotz des Fehlers führt der Verbindungsversuch dazu, dass Aurora die angehaltene Instance wieder aufnimmt.

$ 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 wieder aufgenommen wurde, etwa fünf Minuten lang inaktiv blieb und dann wieder in den angehaltenen Zustand zurückkehrte. Die Instanz wurde mit einer Kapazität von 2,0 wieder aufgenommen. ACUs Dann wurde sie leicht skaliert, um beispielsweise eine interne Bereinigung durchzuführen. Da es innerhalb des fünfminütigen Timeouts keine Benutzerverbindungsversuche erhielt, ging es 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 sollte, wie schnell die Instanz skaliert wurde, um die Arbeitslast zu bewältigen, könnten wir stattdessen Maximum für die Statistik angeben. Minimum Für die Kapazitätsplanung und Kostenschätzung könnten wir einen längeren Zeitraum angeben und die Statistik verwenden. Average Auf diese Weise könnten wir typische Kapazitätswerte in Zeiten hoher Aktivität, geringer Aktivität und unterbrochenem Zustand ermitteln. Um das Verhalten genau zu den Zeiten zwischen Pause und Wiederaufnahme zu untersuchen, könnten 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 und. --start-time --end-time

Problembehandlung für Aurora Serverless v2 automatische Pause

Wenn du das findest Aurora Serverless v2 Instanzen werden nicht so oft angehalten wie erwartet, überprüfen Sie die folgenden möglichen Ursachen:

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

Wann ein Aurora Serverless v2 Die DB-Instance wird wieder aufgenommen, nachdem sie automatisch angehalten wurde. Sie beginnt mit einer relativ geringen Kapazität und wird von dort aus nach oben skaliert. Diese Startkapazität gilt auch dann, wenn die DB-Instance unmittelbar vor der automatischen Pause ü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. Das ist der typische Fall, in dem Aurora Serverless v2 Die Instanz wird aufgrund einer oder einer geringen Anzahl eingehender Verbindungen wieder aufgenommen. Wenn die Instance länger als 24 Stunden angehalten wird, dauert es möglicherweise länger, bis die Instanz wieder aufgenommen wird.

Wenn Ihre Anwendung bereits verwendet hat Aurora Serverless v1 und die automatische Pausenfunktion haben möglicherweise bereits solche Timeout-Intervalle für Verbindungsversuche eingerichtet. Wenn Sie bereits verwenden Aurora Serverless v2 in Kombination mit der Aurora-Stop/Start-Cluster-Funktion wird die Wiederaufnahmezeit für automatisch angehaltene Aurora Serverless v2 Instanzen sind in der Regel viel kürzer als die Zeit zum Starten eines Clusters, der gestoppt wurde.

Wenn Sie die Verbindungslogik in Ihrer Anwendung codieren, versuchen Sie erneut, die Verbindung herzustellen, wenn beim ersten Versuch ein Fehler auftritt, der eine vorübergehende Ursache hat. (Wenn der Fehler auf einen Authentifizierungsfehler zurückzuführen ist, korrigieren Sie die Anmeldeinformationen, bevor Sie es erneut versuchen.) Ein Fehler, der unmittelbar nach der Wiederaufnahme auftritt, kann ein Timeout oder ein Fehler im Zusammenhang mit Datenbanklimits sein. Ein erneuter Versuch kann in den selteneren Fällen Probleme lösen, wenn Aurora Serverless v2 Die Instanz wird aufgrund einer hohen Anzahl gleichzeitiger Verbindungsanfragen wieder aufgenommen. In diesem Fall dauert die Verarbeitung einiger Verbindungen möglicherweise länger als gewöhnlich oder sie überschreiten beim ersten Versuch die maximale Anzahl gleichzeitiger Verbindungen.

Lassen Sie während der Anwendungsentwicklung und beim Debuggen keine Clientsitzungen oder Programmiertools mit Verbindungen zur Datenbank offen. Aurora pausiert eine Instance nicht, wenn vom Benutzer initiierte Verbindungen geöffnet sind, unabhängig davon, ob die Verbindungen keine SQL Anweisungen oder Transaktionen ausführen. Wenn einer Aurora Serverless v2 Eine Instanz in einem Aurora-Cluster kann nicht pausiert werden, andere Instances im Cluster können möglicherweise ebenfalls daran gehindert werden, anzuhalten. Weitere Informationen finden Sie unter Situationen, in denen Aurora Serverless v2 pausiert nicht automatisch.

Aurora sendet Ereignisse aus, wenn ein Aurora Serverless v2 Die DB-Instance beginnt mit der Wiederaufnahme, beendet die Wiederaufnahme und wenn die Instance aus irgendeinem Grund nicht fortgesetzt werden kann. Einzelheiten zu diesen Ereignissen finden Sie unter. DB-Instance-Ereignisse