Skalierung auf Null ACUs mit automatischer Pause und Wiederaufnahme für Aurora Serverless v2 - Amazon Aurora

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.

Anmerkung

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

Ü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:

  • 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 wieder aufnimmt.

  • Wie sich die Kapazität einer DB-Instance zum Zeitpunkt der Ereignisse „Pause“ und „Wiederaufnahme“ ändert.

  • So steuern Sie das Leerlaufintervall, bevor eine DB-Instance pausiert wird.

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

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

  • Wenn Sie eine Verbindung zu einer angehaltenen Verbindung herstellen Aurora Serverless v2 Instanz nimmt die Verbindung automatisch wieder auf und akzeptiert sie.

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

  • Wenn Sie eine Verbindung über den Writer-Endpunkt herstellen, nimmt Aurora die Writer-DB-Instance wieder auf, wenn sie automatisch angehalten wurde. Gleichzeitig nimmt Aurora alle automatisch angehaltenen Reader-Instances wieder auf, 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-Instanz angehalten ist, nimmt Aurora sie wieder auf. Aurora nimmt auch zuerst die Writer-Instanz wieder auf, da die Writer-Instanz immer aktiv sein muss, wenn Reader-Instanzen aktiv sind. Wenn Aurora diese Writer-Instance wieder aufnimmt, führt dies auch dazu, dass alle Reader-Instances in den Failover-Promotion-Stufen Null und Eins wieder aufgenommen werden.

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

  • Wenn Sie den Wert eines Konfigurationsparameters in einer DB-Cluster-Parametergruppe ändern, nimmt Aurora automatisch alle angehaltenen Parameter wieder auf Aurora Serverless v2 Instances in allen Clustern, die diese Cluster-Parametergruppe verwenden. Wenn Sie einen Parameterwert in einer DB-Parametergruppe ändern, nimmt Aurora ebenfalls automatisch alle angehaltenen Werte wieder auf Aurora Serverless v2 Instances, die diese DB-Parametergruppe verwenden. Das gleiche automatische Wiederaufnahmeverhalten gilt, wenn Sie einen Cluster ändern, um ihm eine andere Cluster-Parametergruppe zuzuweisen, oder wenn Sie eine Instance ändern, um eine andere DB-Parametergruppe zuzuweisen.

  • Durch die Ausführung einer Backtrack-Anfrage wird der Vorgang automatisch fortgesetzt Aurora Serverless v2 Writer-Instanz, wenn sie angehalten ist. Aurora verarbeitet die Backtrack-Anfrage, nachdem die Writer-Instanz wieder aufgenommen wurde. Sie können zu einer Zeit zurückkehren, in der Aurora Serverless v2 Die Instanz wurde angehalten.

  • Das Erstellen eines Cluster-Snapshots oder das Löschen eines Snapshots verursacht keine Aurora Serverless v2 Instanzen, die wieder aufgenommen werden sollen.

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

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

  • Aurora kann einige Arten kleinerer interner Wartungsarbeiten durchführen, ohne eine Instanz zu aktivieren. Für einige Wartungsarten, die während des Wartungsfensters des Clusters durchgeführt werden, muss Aurora die Instance jedoch wieder aufnehmen. 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 Jobs, wie die in der SQL pg_cron Postgre-Erweiterung oder dem My Event Scheduler, nicht automatisch fort. SQL Um sicherzustellen, dass solche Jobs ausgeführt werden, stellen Sie vor dem geplanten Zeitpunkt manuell eine Verbindung zur Instance her. Aurora stellt keine Jobs in die Warteschlange, bei denen die geplante Zeit eintritt, während die DB-Instance angehalten ist. Solche Jobs werden übersprungen, wenn die Instance später wieder aufgenommen wird.

  • Wenn der Aurora-Cluster während eines Aurora Serverless v2 Die Instanz wird automatisch angehalten. Aurora kann eine Instanz fortsetzen und diese Instanz dann zum Autor ernennen. 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 wieder aufgenommen wird.

  • Operationen, die die Eigenschaften des Clusters ändern, führen ebenfalls zu einer automatischen Unterbrechung Aurora Serverless v2 Instanzen, die wieder aufgenommen werden sollen. Beispielsweise wird eine automatisch angehaltene Instanz für Operationen wie die folgenden wieder aufgenommen:

    • Ändern des Skalierungsbereichs des Clusters.

    • Aktualisierung der Engine-Version des Clusters.

    • Beschreibung oder Herunterladen von Protokolldateien aus einer angehaltenen Instanz. Sie können historische Logdaten von angehaltenen Instances untersuchen, indem Sie Log-Uploads in die Instances aktivieren CloudWatch und die Logs analysieren. CloudWatch

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:

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

  • Der Pausenmechanismus ist nicht sofort wirksam. Importieren in &S3; Aurora Serverless v2 Eine Instanz, die kurz davor steht, automatisch angehalten zu werden, wartet möglicherweise kurz, catch sie alle Änderungen am Aurora-Speicher übernommen hat.

  • 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 Instanz beendet das Schreiben in die Datenbank-Logdateien. Sie sendet keine Metriken mehr an CloudWatch, außer dass null Prozent für CPUUtilization und und ACUUtilization Null für registriert ServerlessDatabaseCapacity werden.

  • Aurora sendet Ereignisse aus, wenn ein Aurora Serverless v2 Die DB-Instance beginnt zu pausieren, beendet die Pause und wenn der Pause-Mechanismus unterbrochen wird oder nicht erfolgreich ist. Einzelheiten zu diesen Ereignissen finden Sie unter. DB-Instance-Ereignisse

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:

  • Alle Parameteränderungen, die sich in pending-reboot Änderungen befinden, werden übernommen, wenn die Instance wieder aufgenommen wird.

  • Aurora gibt Ereignisse auf Instanzebene aus, wenn 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

  • Alle angeforderten Verbindungen werden hergestellt, nachdem die DB-Instance die Wiederaufnahme abgeschlossen hat. Da die typische Zeit für die Wiederaufnahme 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 sslResponseTimeout Einstellungen connectTimeout und so anpassen, dass sie länger als 15 Sekunden sind.

Anmerkung

Wenn ein Aurora Serverless v2 Die Instanz bleibt länger als 24 Stunden angehalten. Aurora kann die Instanz in einen tieferen Ruhezustand versetzen, dessen Wiederaufnahme länger dauert. In diesem Fall kann die Wiederaufnahmezeit 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.

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

  • Wenn der Mindestkapazitätswert für Ihren DB-Cluster höher als Null istACUs, Aurora Serverless v2 Instances im Cluster werden nicht automatisch angehalten. Wenn Sie bestehende Cluster haben mit Aurora Serverless v2 Für Instanzen aus der Zeit vor der Verfügbarkeit der Auto-Pause-Funktion lag die niedrigste Mindestkapazitätseinstellung bei 0,5ACUs. Um die Auto-Pause-Funktion mit solchen Clustern zu verwenden, ändern Sie die Einstellung für die Mindestkapazität auf NullACUs.

  • Wenn vom Benutzer initiierte Verbindungen offen sind für Aurora Serverless v2 Instanz, die Instanz wird nicht angehalten. Die Instanz 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 SQL Postgre-Cluster, für den die logische Replikation aktiviert ist, oder in einem Aurora SQL My-Cluster, für den die Binlog-Replikation aktiviert ist, werden die Writer-Instance und alle Reader-Instances in den Failover-Promotion-Stufen Null und Eins nicht automatisch angehalten. Aurora führt eine konstante Mindestmenge an Aktivität 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 pausieren. Setzen Sie dazu ihre Failover-Priorität auf einen anderen Wert als Null oder Eins. Auf diese Weise können sie unabhängig von der Writer-Instanz angehalten werden.

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

  • Wenn Ihr Cluster der primäre Cluster in einer globalen Aurora-Datenbank ist, pausiert Aurora den Aurora Serverless v2 Writer-Instanz. Das liegt daran, dass auf der Writer-Instanz ein konstantes Maß an Aktivität erforderlich ist, um die anderen Cluster in der globalen Datenbank zu verwalten. Da die Writer-Instanz aktiv bleibt, sind alle Aurora Serverless v2 Leserinstanzen mit der Failover-Priorität Null oder Eins werden ebenfalls nicht automatisch angehalten.

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

  • In einem Cluster mit einer zugehörigen ETL Nullintegration zu Redshift werden die Writer-Instance und alle Reader-Instances in der Failover-Promotion nicht automatisch angehalten.

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

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

  • Während ein Aurora Serverless v2 Die Instanz wird automatisch angehalten. Wenn Sie versuchen, den Aurora-Cluster zu aktualisieren, nimmt Aurora die Instance wieder auf und aktualisiert sie.

  • Aurora setzt in regelmäßigen Abständen alle automatisch angehaltenen Aurora Serverless v2 Instanzen zur Durchführung von Wartungsarbeiten, wie z. B. kleinere Versionsupgrades und Änderungen an Eigenschaften wie Parametergruppen.

  • Nach einem Aurora Serverless v2 Die Instanz wird für einen administrativen Vorgang wie ein Upgrade oder die Installation von Wartungsarbeiten aktiviert. Aurora wartet mindestens 20 Minuten, bevor sie diese Instance erneut pausiert. Dadurch können alle Hintergrundvorgänge abgeschlossen werden. Durch den Zeitraum von zwanzig Minuten wird außerdem vermieden, dass die Instanz mehrmals angehalten und wieder aufgenommen wird, wenn auf der Instanz mehrere Verwaltungsvorgänge nacheinander ausgeführt werden.

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

  • Die Wiederaufnahmezeit wurde verbessert in Aurora Serverless v2 verglichen mit Aurora Serverless v1. Die Wiederaufnahme dauert 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 wird, kann die Wiederaufnahme länger dauern.

  • Die Art, dass Aurora Serverless v2 gilt für Multi-AZ-Cluster und bedeutet, dass einige DB-Instances im Cluster möglicherweise angehalten werden, während andere aktiv sind. Die Writer-Instance wird immer dann wieder aufgenommen, wenn ein Reader läuft, da der Writer zur Koordination bestimmter Aktivitäten innerhalb des Clusters benötigt wird. Weil Aurora Serverless v1 verwendet keine Reader-Instanzen, der gesamte Cluster wäre immer angehalten oder aktiv.

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

  • Aurora Serverless v2 Instanzen werden mit derselben Häufigkeit wie bereitgestellte Instanzen Wartungsvorgänge unterzogen. Da Aurora Instances automatisch wieder aufnimmt, wenn eine solche Wartung erforderlich ist, stellen Sie möglicherweise fest, dass Aurora Serverless v2 Instanzen werden häufiger wieder aufgenommen als Aurora Serverless v1 Cluster haben es getan.

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.

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:

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

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

  • Nehmen wir an, 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 einem erstellen Aurora Serverless v2 Reader-Instanz und entkoppeln Sie die Kapazitäten einiger Reader-Instanzen vom Writer. Geben Sie die Failover-Priorität Null oder Eins für die Writer-Instanz und eine Reader-Instanz an. Geben Sie für die anderen Reader-Instanzen eine Priorität an, die größer als eins ist. Auf diese Weise können die Leserinstanzen der höheren Prioritätsstufen automatisch pausieren, auch wenn der Autor und einer der Leser 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 Instanzen für den Writer und das Lesegerät 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 bedienen und Failover durchzuführen.

    • Sie können einen benutzerdefinierten Endpunkt einrichten, der Folgendes umfasst Aurora Serverless v2 Instanzen der höheren Prioritätsstufen, aber nicht die Leser der Stufe „Autor“ oder „Promotion-Stufe 0“ oder „1“. Auf diese Weise können Sie Nur-Lesesitzungen, die nicht latenzempfindlich sind, an die Leser 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.

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:

  • Innerhalb eines Aurora-DB-Clusters 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 pausiert.

  • 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 wieder aufnehmen, wird die Writer-Instance automatisch wieder aufgenommen, auch wenn Ihre Anwendung nicht direkt auf die Writer-Instance zugreift.

  • Aurora Serverless v2 Reader-Instances im Rahmen der Failover-Promotion werden die Stufen Null und Eins skaliert, um ihre Kapazität mit der Writer-Instanz synchron zu halten. Also, wenn ein Aurora Serverless v2 Die Writer-Instanz wird fortgesetzt, ebenso wie jede Aurora Serverless v2 Leser-Instanzen, die sich in den Promotion-Stufen Null oder Eins befinden.

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 kann Zeiträume geben, in denen Aurora Serverless v2 Instances zeichnen keine Logdaten und die meisten Metriken auf, weil die Instances pausiert sind. Die einzigen Messwerte, an die gesendet werden, CloudWatch während eine Instance angehalten istACUUtilization, sind null Prozent für CPUUtilization und und Null für. ServerlessDatabaseCapacity

  • Sie können überprüfen, ob Aurora Serverless v2 Instanzen pausieren mehr oder weniger häufig als erwartet. Prüfen Sie dazu, wie oft sich die ServerlessDatabaseCapacity Metrik von einem Wert ungleich Null auf Null ä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 von Ihnen beabsichtigt angehalten und wieder aufgenommen werden, kann es bei der Beantwortung von Verbindungsanfragen zu unnötiger Latenz in Ihrem Cluster kommen. Informationen zu den Faktoren, die beeinflussen, ob und wie oft Aurora Serverless v2 Instanzen können pausierenVoraussetzungen und Einschränkungen für Aurora Serverless v2 Auto-Pause-Funktion, sieheSituationen, in denen Aurora Serverless v2 pausiert nicht automatisch, undProblembehandlung für Aurora Serverless v2 automatische Pause.

  • Sie können auch eine Protokolldatei untersuchen, in der automatische Anhalten- und Wiederaufnahmevorgänge für ein Aurora Serverless v2 sein. Wenn eine Instance nach Ablauf des Timeout-Intervalls nicht angehalten wurde, enthält diese Protokolldatei auch den Grund, warum die automatische Pause nicht stattgefunden hat. Weitere Informationen finden Sie unter Überwachen Aurora Serverless v2 Aktivität unterbrechen und fortsetzen.

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:

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

  • Vergewissern Sie sich, dass der Mindestkapazitätswert für den Cluster auf Null gesetzt istACUs.

  • Vergewissern Sie sich, dass die fragliche Instanz tatsächlich das verwendet Aurora Serverless v2 Instanzklassedb.serverless, keine der bereitgestellten Instanzklassen.

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

  • Untersuchen Sie die Protokolldatei, aus der hervorgeht, wann Aurora Serverless v2 Instanzen wurden angehalten, wieder aufgenommen oder Aurora konnte eine Instance aus irgendeinem Grund nicht anhalten oder fortsetzen. Weitere Informationen finden Sie unter Überwachen Aurora Serverless v2 Aktivität unterbrechen und fortsetzen.

  • Prüfen Sie, ob Clients oder Anwendungen Verbindungen über einen längeren Zeitraum aufrecht erhalten. Prüfen Sie umgekehrt, ob Anwendungen, die RDS Daten API - oder Lambda-Funktionen verwenden, häufig Anfragen senden, sodass die Instanz nie lange genug inaktiv ist, um anzuhalten. Sie können die CloudWatch Metriken wie ConnectionAttempts und untersuchen. DatabaseConnections Weitere Informationen finden Sie unter Metriken auf Instance-Ebene für Amazon Aurora.

  • Wenn eine Reader-Instance selten oder nie unterbrochen wird, überprüfen Sie ihre Failover-Priorität. Wenn das Lesegerät für die Skalierung von Lesevorgängen und nicht als Standby-Lesegerät im Falle eines Failovers verwendet wird, legen Sie für ihn eine Priorität im Bereich von 2 bis 15 fest.

  • Wenn die Writer-Instanz selten oder nie pausiert, überprüfen Sie Ihre Nutzung der Reader-Instanzen. Der Writer kann nur pausieren, wenn der gesamte Cluster inaktiv ist. Das liegt daran, dass eine Verbindung zu einer beliebigen Reader-Instanz dazu führt, dass der Writer den Vorgang fortsetzt.

  • Wenn Ihre Anwendung bei Verbindungsanfragen während der Zeit Timeouts erhält Aurora Serverless v2 Instanzen werden wieder aufgenommen, sollten Sie erwägen, das Timeout-Intervall zu verlängern, das von Ihrem Anwendungscode oder dem zugrunde liegenden Datenbank-Framework verwendet wird. Längere Verbindungs-Timeouts reduzieren die Wahrscheinlichkeit fehlgeschlagener Verbindungen während Aurora Serverless v2 Instanzen werden wieder aufgenommen. 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 Intervall für die automatische Pause zu verlängern, damit Anwendungen nicht so oft auf angehaltene Instanzen stoßen.

    Wenn für Ihre Anwendung kein logisches Gleichgewicht zwischen dem Verhalten der automatischen Pause 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 Ihr Aurora Serverless v2 Instances werden pausiert. Beachten Sie, dass es bestimmte Faktoren gibt, die es unmöglich machen, präzise Vorhersagen zu treffen.

    • Instanzen können regelmäßig wieder aufgenommen werden, um Wartungsarbeiten, kleinere Versionsupgrades durchzuführen oder Änderungen an Parametergruppen vorzunehmen.

    • Bei Multi-AZ-Clustern gibt es Situationen, in denen die Wiederaufnahme einer Instance dazu führt, dass auch andere Instances wieder aufgenommen werden. Die Wiederaufnahme eines Lesers führt immer dazu, dass der Autor den Vorgang fortsetzt. Wenn der Writer wieder aufgenommen wird, werden alle Lesegeräte mit der Failover-Priorität 0 und 1 immer wieder fortgesetzt.

    Wir empfehlen, die tatsächliche Dauer der Pause über einen Zeitraum von mehreren Tagen zu messen und dabei eine realistische Arbeitslast zu ermitteln. Verwenden Sie dann diese Messungen, um eine Ausgangsbasis festzulegen, für welchen Zeitraum Sie davon ausgehen können, dass eine Instance angehalten wird.

  • Möglicherweise stellen Sie fest, dass interne Operationen wie My SQL Purge, My SQL Event Scheduler, SQL Postgre-Autovacuum oder SQL Postgre-Jobs, die über die pg_cron Erweiterung geplant wurden, nicht ausgeführt werden oder nicht abgeschlossen werden. Die Instanz 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 Timeouts für die automatische Pause im Gange sind, werden Wartungsaufgaben wie My SQL Purge und Postgre SQL Autovacuum abgebrochen. Geplante Jobs aus dem My SQL Event Scheduler oder der SQL pg_cron Postgre-Erweiterung werden ebenfalls storniert, wenn sie in Bearbeitung sind, wenn Aurora den Pausenvorgang einleitet.

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

Ü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