Verwaltung von Aurora Serverless v2 DB-Clustern

Mit Aurora Serverless v2 sind Ihre Cluster mit bereitgestellten Clustern austauschbar. Die Aurora Serverless v2-Eigenschaften gelten für eine oder mehrere DB-Instances innerhalb eines Clusters. Daher sind die Verfahren zum Erstellen von Clustern, zum Ändern von Clustern, zum Erstellen und Wiederherstellen von Snapshots usw. im Grunde die gleichen wie bei anderen Arten von Aurora-Clustern. Allgemeine Verfahren zum Verwalten von Aurora-Clustern und DB-Instances finden Sie unter Verwalten eines Amazon Aurora-DB-Clusters.

In den folgenden Themen erfahren Sie mehr über Verwaltungsaspekte für Cluster, die Aurora Serverless v2 DB-Instances enthalten.

Festlegen des Aurora Serverless v2-Kapazitätsbereichs für einen Cluster

Wenn Sie die Konfigurationsparameter oder andere Einstellungen für Cluster mit Aurora Serverless v2-DB-Instances oder die DB-Instances selbst ändern möchten, folgen Sie denselben allgemeinen Verfahren wie für bereitgestellte Cluster. Details hierzu finden Sie unter Ändern eines Amazon Aurora-DB-Clusters.

Die wichtigste Einstellung, die für Aurora Serverless v2 einzigartig ist, ist der Kapazitätsbereich. Nachdem Sie die minimalen und maximalen Aurora-Kapazitätseinheitenwerte (ACU) für einen Aurora-Cluster festgelegt haben, müssen Sie die Kapazität der Aurora Serverless v2 DB-Instances im Cluster nicht aktiv anpassen. Aurora übernimmt diesen Schritt nicht. Diese Einstellung wird auf Cluster-Ebene verwaltet. Für jede Aurora Serverless v2 DB-Instance im Cluster gelten dieselben Mindest- und ACU Höchstwerte.

Sie können die folgenden spezifischen Werte festlegen:

• Minimum ACUs — Die Aurora Serverless v2 DB-Instance kann die Kapazität auf diese Anzahl von reduzierenACUs.

• Maximum ACUs — Die Aurora Serverless v2 DB-Instance kann die Kapazität bis zu dieser Anzahl von erhöhenACUs.

Anmerkung

Wenn Sie den Kapazitätsbereich für einen DB-Cluster von Aurora Serverless v2 ändern, erfolgt die Änderung sofort, unabhängig davon, ob Sie sie sofort oder während des nächsten geplanten Wartungsfensters anwenden möchten.

Weitere Informationen zu den Auswirkungen des Kapazitätsbereichs und zur Überwachung und Feinabstimmung finden Sie unter Wichtige CloudWatch Amazon-Metriken für Aurora Serverless v2 und Performance und Skalierung für Aurora Serverless v2. Ihr Ziel ist es, sicherzustellen, dass die maximale Kapazität für den Cluster hoch genug ist, um Spitzen bei der Workload zu bewältigen, und die miminale Kapazität niedrig genug ist, um die Kosten zu minimieren, wenn der Cluster nicht aktiv ist.

Angenommen, Sie stellen anhand Ihrer Überwachung fest, dass der ACU Bereich für den Cluster höher, niedriger, breiter oder schmaler sein sollte. Sie können die Kapazität eines Aurora-Clusters auf einen bestimmten Bereich von ACUs mit dem AWS Management Console AWS CLI, dem oder dem Amazon festlegen RDSAPI. Dieser Kapazitätsbereich gilt für jede Aurora Serverless v2-DB-Instance im Cluster.

Nehmen wir zum Beispiel an, dass Ihr Cluster einen Kapazitätsbereich von 1—16 hat ACUs und zwei Aurora Serverless v2 DB-Instances enthält. Dann verbraucht der Cluster als Ganzes irgendwo zwischen 2 ACUs (im Leerlauf) und 32 ACUs (bei voller Auslastung). Wenn Sie den Kapazitätsbereich von 8 auf 20,5 ändern, verbraucht der Cluster jetzt 16ACUs, wenn er inaktiv ist, und bis zu 41ACUs, ACUs wenn er voll ausgelastet ist.

Aurora setzt bestimmte Parameter für Aurora Serverless v2 DB-Instances automatisch auf Werte, die vom ACU Maximalwert im Kapazitätsbereich abhängen. Eine Liste dieser Parameter finden Sie unter Maximale Anzahl der Verbindungen für Aurora Serverless v2. Bei statischen Parametern, die von dieser Berechnungsart abhängen, wird der Wert beim Neustart der DB-Instance erneut ausgewertet. So können Sie den Wert solcher Parameter aktualisieren, indem Sie die DB-Instance neu starten, nachdem Sie den Kapazitätsbereich geändert haben. Wenn Sie wissen möchten, ob Sie Ihre DB-Instance neu starten müssen, um Parameteränderungen zu übernehmen, überprüfen Sie das ParameterApplyStatus-Attribut der DB-Instance. Der Wert pending-reboot gibt an, dass ein Neustart Änderungen auf einige Parameterwerte anwendet.

Konsole

Sie können den Kapazitätsbereich eines Clusters, der Aurora Serverless v2-DB-Instances enthält, über die AWS Management Console festlegen.

Wenn Sie die Konsole verwenden, legen Sie den Kapazitätsbereich für den Cluster zu dem Zeitpunkt fest, zu dem Sie dem Cluster die erste Aurora Serverless v2-DB-Instance hinzufügen. Diesen Schritt können Sie ausführen, wenn Sie beim Erstellen des Clusters die DB-Instance-Klasse Serverless v2 für die Writer-DB-Instance auswählen. Sie können diesen Schritt auch ausführen, wenn Sie beim Hinzufügen einer Aurora Serverless v2-Reader-DB-Instance zum Cluster die DB-Instance-Klasse Serverless auswählen. Möglich ist dieser Schritt auch, wenn Sie eine vorhandene bereitgestellte DB-Instance im Cluster in die DB-Instance-Klasse Serverless konvertieren. Die Vollversionen dieser Verfahren finden Sie unter Eine Aurora Serverless v2 Writer-DB-Instance erstellenHinzufügen eines Aurora Serverless v2-Readers, undKonvertieren eines bereitgestellten Writers oder Readers in Aurora Serverless v2.

Der jeweilige Kapazitätsbereich, den Sie auf Cluster-Ebene festlegen, gilt für alle Aurora Serverless v2-DB-Instances in Ihrem Cluster. Die folgende Abbildung zeigt einen Cluster mit mehreren Aurora Serverless v2-Reader-DB-Instances. Jedes hat einen identischen Kapazitätsbereich von 2—64ACUs.

So ändern Sie den Kapazitätsbereich eines Aurora Serverless v2-Clusters

1. Öffnen Sie die RDS Amazon-Konsole unter https://console.aws.amazon.com/rds/.

2. Wählen Sie im Navigationsbereich Datenbanken aus.

3. Wählen Sie den Cluster, der Ihre Aurora Serverless v2-DB-Instances enthält, aus der Liste aus. Der Cluster muss bereits mindestens eine Aurora Serverless v2-DB-Instance enthalten. Andernfalls zeigt Aurora den Abschnitt Capacity range (Kapazitätsbereich) nicht an.

4. Wählen Sie für Actions (Aktionen) die Option Modify (Ändern) aus.

5. Wählen Sie im Abschnitt Capacity range (Kapazitätsbereich) Folgendes aus:

   1. Geben Sie einen Wert für Minimum einACUs. Die Konsole zeigt den zulässigen Wertebereich an. Sie können eine Mindestkapazität zwischen 0,5 und 128 wählenACUs. Sie können eine maximale Kapazität von 1 bis 128 wählenACUs. Sie können die Kapazitätswerte in Schritten von 0,5 ACU anpassen.

   2. Geben Sie einen Wert für Maximum ACUs ein. Dieser Wert muss größer oder gleich Minimum seinACUs. Die Konsole zeigt den zulässigen Wertebereich an. Die folgende Abbildung zeigt diese Auswahl.

      

6. Klicken Sie auf Weiter. Die Seite Summary of modifications (Zusammenfassung der Änderungen) wird angezeigt.

7. Wählen Sie Apply immediately (Sofort anwenden) aus.

   Die Kapazitätsänderung erfolgt sofort, unabhängig davon, ob Sie sie sofort oder während des nächsten geplanten Wartungsfensters anwenden möchten.

8. Wählen Sie Modify cluster (Cluster ändern), um die Zusammenfassung der Änderungen zu akzeptieren. Sie können auch Back (Zurück) wählen, um Ihre Änderungen zu bearbeiten, oder Cancel (Abbrechen), um Ihre Änderungen zu verwerfen.

AWS CLI

Um die Kapazität eines Clusters festzulegen, in dem Sie Aurora Serverless v2 DB-Instances mithilfe von verwenden möchten AWS CLI, führen Sie den modify-db-cluster AWS CLI Befehl aus. Legen Sie die Option --serverless-v2-scaling-configuration fest. Der Cluster enthält möglicherweise bereits eine oder mehrere Aurora Serverless v2-DB-Instances oder Sie können die DB-Instances später hinzufügen. Gültige Werte für die Felder MinCapacity und MaxCapacity sind unter anderem folgende:

• 0.5, 1, 1.5, 2 usw. in Schritten von 0,5 bis maximal 128.

In diesem Beispiel legen Sie den ACU Bereich eines Aurora-DB-Clusters mit dem Namen sample-cluster auf ein Minimum von 48.5 und ein Maximum von 64 fest.

aws rds modify-db-cluster --db-cluster-identifier sample-cluster \
--serverless-v2-scaling-configuration MinCapacity=48.5,MaxCapacity=64

Die Kapazitätsänderung erfolgt sofort, unabhängig davon, ob Sie sie sofort oder während des nächsten geplanten Wartungsfensters anwenden möchten.

Danach können Sie dem Cluster Aurora Serverless v2 DB-Instances hinzufügen und jede neue DB-Instance kann zwischen 48,5 und 64 ACUs skaliert werden. Der neue Kapazitätsbereich gilt auch für alle Aurora Serverless v2-DB-Instances, die sich bereits im Cluster befanden. Die DB-Instances skalieren bei Bedarf hoch oder herunter, um in den neuen Kapazitätsbereich zu gelangen.

Weitere Beispiele für die Einstellung des Kapazitätsbereichs mithilfe von finden Sie CLI unterAuswählen des Aurora Serverless v2-Kapazitätsbereichs für einen Aurora-Cluster.

Um die Skalierungskonfiguration eines Aurora Serverless DB-Clusters mithilfe von zu ändern AWS CLI, führen Sie den modify-db-cluster AWS CLI Befehl aus. Geben Sie die Option --serverless-v2-scaling-configuration an, um die minimale und die maximale Kapazität zu konfigurieren. Zu den gültigen Kapazitätswerten gehören die folgenden:

• Aurora MySQL: 0.51,1.5,2, usw., in Schritten von 0,5 ACUs bis zu einem Maximum von128.

• Aurora PostgreSQL: 0.51,1.5,2, usw., in Schritten von 0,5 ACUs bis zu einem Maximum von. 128

Im folgenden Beispiel ändern Sie die Skalierungskonfiguration einer Aurora Serverless v2-DB-Instance mit dem Namen sample-instance, die Teil eines Clusters namens sample-cluster ist.

FürLinux, odermacOS: Unix

aws rds modify-db-cluster --db-cluster-identifier sample-cluster \
--serverless-v2-scaling-configuration MinCapacity=8,MaxCapacity=64

Windows:

aws rds modify-db-cluster --db-cluster-identifier sample-cluster ^
--serverless-v2-scaling-configuration MinCapacity=8,MaxCapacity=64

RDS API

Sie können die Kapazität einer Aurora-DB-Instance mit der odifyDBClusterAPIM-Operation festlegen. Geben Sie den Parameter ServerlessV2ScalingConfiguration an. Gültige Werte für die Felder MinCapacity und MaxCapacity sind unter anderem folgende:

• 0.5, 1, 1.5, 2 usw. in Schritten von 0,5 bis maximal 128.

Sie können die Skalierungskonfiguration eines Clusters mit Aurora Serverless v2 DB-Instances mit der odifyDBClusterAPIM-Operation ändern. Geben Sie den Parameter ServerlessV2ScalingConfiguration an, um die minimale und die maximale Kapazität zu konfigurieren. Zu den gültigen Kapazitätswerten gehören die folgenden:

• Aurora MySQL: 0.51,1.5,2, usw., in Schritten von 0,5 ACUs bis zu einem Maximum von128.

• Aurora PostgreSQL: 0.51,1.5,2, usw., in Schritten von 0,5 ACUs bis zu einem Maximum von. 128

Die Kapazitätsänderung erfolgt sofort, unabhängig davon, ob Sie sie sofort oder während des nächsten geplanten Wartungsfensters anwenden möchten.

Überprüfen des Kapazitätsbereichs für Aurora Serverless v2

Das Verfahren zur Überprüfung des Kapazitätsbereichs für Ihren Aurora Serverless v2-Cluster erfordert, dass Sie zuerst einen Kapazitätsbereich festlegen. Wenn Sie dies noch nicht getan haben, gehen Sie wie unter Festlegen des Aurora Serverless v2-Kapazitätsbereichs für einen Cluster beschrieben vor.

Der jeweilige Kapazitätsbereich, den Sie auf Cluster-Ebene festlegen, gilt für alle Aurora Serverless v2-DB-Instances in Ihrem Cluster. Die folgende Abbildung zeigt einen Cluster mit mehreren Aurora Serverless v2-DB-Instances. Jede Instance hat einen identischen Kapazitätsbereich.

Sie können auch die Detailseite für alle Aurora Serverless v2-DB-Instances im Cluster anzeigen. Der Kapazitätsbereich der DB-Instances wird auf dem Tab Configuration (Konfiguration) angezeigt.

Sie können den aktuellen Kapazitätsbereich für den Cluster auch auf der Seite Modify (Ändern) für den Cluster sehen. Die folgende Abbildung veranschaulicht die Vorgehensweise. An diesem Punkt können Sie den Kapazitätsbereich ändern. Alle Möglichkeiten, wie Sie den Kapazitätsbereich einstellen oder ändern können, finden Sie unter Festlegen des Aurora Serverless v2-Kapazitätsbereichs für einen Cluster.

Überprüfen des aktuellen Kapazitätsbereichs für einen Aurora-Cluster

Sie können den Kapazitätsbereich überprüfen, der für Aurora Serverless v2-DB-Instances in einem Cluster konfiguriert ist, indem Sie sich das ServerlessV2ScalingConfiguration-Attribut für den Cluster ansehen. Das folgende AWS CLI Beispiel zeigt einen Cluster mit einer Mindestkapazität von 0,5 Aurora-Kapazitätseinheiten (ACUs) und einer maximalen Kapazität von ACUs 16.

$ aws rds describe-db-clusters --db-cluster-identifier serverless-v2-64-acu-cluster \
  --query 'DBClusters[*].[ServerlessV2ScalingConfiguration]'
[
    [
        {
            "MinCapacity": 0.5,
            "MaxCapacity": 16.0
        }
    ]
]

Hinzufügen eines Aurora Serverless v2-Readers

Wenn Sie Ihrem Cluster eine Aurora Serverless v2-Reader-DB-Instance hinzufügen möchten, folgen Sie dem gleichen allgemeinen Verfahren wie in Hinzufügen von Aurora-Replicas zu einem DB-Cluster. Wählen Sie die Instance-Klasse Serverless v2 für die neue DB-Instance aus.

Wenn die Reader-DB-Instance die erste Aurora Serverless v2-DB-Instance im Cluster ist, wählen Sie auch den Kapazitätsbereich aus. Die folgende Abbildung zeigt die Steuerelemente, mit denen Sie die minimalen und maximalen Aurora-Kapazitätseinheiten (ACUs) angeben. Diese Einstellung gilt für diese Reader-DB-Instance und für alle weiteren Aurora Serverless v2-DB-Instances, die Sie dem Cluster hinzufügen. Jede Aurora Serverless v2 DB-Instance kann zwischen den Minimal- und ACU Maximalwerten skalieren.

Wenn Sie dem Cluster bereits Aurora Serverless v2-DB-Instances hinzugefügt haben, wird Ihnen beim Hinzufügen weiterer Aurora Serverless v2-Reader-DB-Instances der aktuelle Kapazitätsbereich angezeigt. Die folgende Abbildung zeigt diese schreibgeschützten Steuerelemente.

Wenn Sie den Kapazitätsbereich für den Cluster ändern möchten, gehen Sie vor, wie in Festlegen des Aurora Serverless v2-Kapazitätsbereichs für einen Cluster bechrieben.

Bei Clustern, die mehr als eine Reader-DB-Instance enthalten, spielt die Failover-Priorität jeder Aurora Serverless v2-Reader-DB-Instance eine wichtige Rolle dabei, wie diese DB-Instance hoch- oder herunterskaliert. Sie können die Priorität nicht angeben, wenn Sie den Cluster erstellen. Denken Sie an diese Eigenschaft, wenn Sie Ihrem Cluster einen zweiten Reader oder eine weitere DB-Instance hinzufügen. Weitere Informationen finden Sie unter Auswählen der Hochstufungsstufe für einen Aurora Serverless v2-Reader.

Weitere Möglichkeiten zum Anzeigen des aktuellen Kapazitätsbereichs für einen Cluster finden Sie unter Überprüfen des Kapazitätsbereichs für Aurora Serverless v2.

Konvertieren eines bereitgestellten Writers oder Readers in Aurora Serverless v2

Sie können eine bereitgestellte DB-Instance konvertieren, um Aurora Serverless v2 zu verwenden. Befolgen Sie dazu die Anleitung unter Ändern einer DB-Instance in einem DB-Cluster. Der Cluster muss die Anforderungen in Anforderungen und Einschränkungen für Aurora Serverless v2 erfüllen. Aurora Serverless v2-DB-Instances erfordern beispielsweise, dass der Cluster bestimmte Mindest-Engine-Versionen ausführt.

Angenommen, Sie konvertieren einen laufenden bereitgestellten Cluster, um Aurora Serverless v2 zu nutzen. In diesem Fall können Sie Ausfallzeiten minimieren, indem Sie im ersten Schritt des Umstellungsprozesses eine DB-Instance in Aurora Serverless v2 konvertieren. Das vollständige Verfahren finden Sie unter Umstellung von einem bereitgestellten Cluster zu Aurora Serverless v2.

Wenn die DB-Instance, die Sie konvertieren, die erste Aurora Serverless v2-DB-Instance im Cluster ist, wählen Sie den Kapazitätsbereich für den Cluster im Rahmen der Operation Modify (Ändern) aus. Dieser Kapazitätsbereich gilt für jede Aurora Serverless v2-DB-Instance, die Sie dem Cluster hinzufügen. Die folgende Abbildung zeigt die Seite, auf der Sie die minimalen und maximalen Aurora-Kapazitätseinheiten (ACUs) angeben.

Weitere Informationen zur Bedeutung des Kapazitätsbereichs finden Sie unter Kapazität von Aurora Serverless v2.

Wenn der Cluster bereits eine oder mehrere Aurora Serverless v2-DB-Instances enthält, sehen Sie den vorhandenen Kapazitätsbereich, wenn Sie die Operation Modify (Ändern) verwenden. Die folgende Abbildung zeigt ein Beispiel für dieses Informationsfeld.

Wenn Sie den Kapazitätsbereich für den Cluster ändern möchten, nachdem Sie weitere Aurora Serverless v2-DB-Instances hinzugefügt haben, gehen Sie vor, wie in Festlegen des Aurora Serverless v2-Kapazitätsbereichs für einen Cluster bechrieben.

Konvertieren eines Aurora Serverless v2-Writers oder -Readers in bereitgestellt

Sie können eine Aurora Serverless v2-DB-Instance in eine bereitgestellte DB-Instance konvertieren. Befolgen Sie dazu die Anleitung unter Ändern einer DB-Instance in einem DB-Cluster. Wählen Sie eine andere DB-Instance-Klasse als Serverless aus.

Sie können eine Aurora Serverless v2 DB-Instance in eine bereitgestellte umwandeln, wenn sie eine größere Kapazität benötigt, als sie mit den maximalen Aurora-Kapazitätseinheiten (ACUs) einer Aurora Serverless v2 DB-Instance verfügbar ist. Zum Beispiel haben die größten DB-Instance-Klassen db.r5 und db.r6g eine größere Speicherkapazität als die Kapazität, auf die eine Aurora Serverless v2-DB-Instance skalieren kann.

Tipp

Einige der älteren DB-Instance-Klassen wie db.r3 und db.t2 sind für die Aurora-Versionen, die Sie mit Aurora Serverless v2 verwenden, nicht verfügbar. Informationen dazu, wie Sie feststellen können, welche DB-Instance-Klassen beim Konvertieren einer Aurora Serverless v2-DB-Instance in eine bereitgestellte Instance verwendet werden können, finden Sie unter Unterstützte DB-Engines für DB-Instance-Klassen.

Wenn Sie die Writer-DB-Instance Ihres Clusters von Aurora Serverless v2 in eine bereitgestellte Instance konvertieren, können Sie die Vorgehensweise unter Umstellung von einem bereitgestellten Cluster zu Aurora Serverless v2 verwenden. Stellen Sie eine der Reader-DB-Instances im Cluster von Aurora Serverless v2 auf eine bereitgestellte Instance um. Führen Sie ein Failover durch, damit diese bereitgestellte DB-Instance zur Writer-Instance wird.

Jeder Kapazitätsbereich, den Sie zuvor für den Cluster angegeben haben, bleibt bestehen, auch wenn alle Aurora Serverless v2-DB-Instances aus dem Cluster entfernt werden. Wenn Sie den Kapazitätsbereich ändern möchten, können Sie den Cluster ändern, wie in Festlegen des Aurora Serverless v2-Kapazitätsbereichs für einen Cluster erläutert.

Auswählen der Hochstufungsstufe für einen Aurora Serverless v2-Reader

Bei Clustern mit mehreren Aurora Serverless v2-DB-Instances oder mit einer Mischung aus bereitgestellten und Aurora Serverless v2-DB-Instances achten Sie auf die Einstellung der Hochstufungsstufe für jede einzelne Aurora Serverless v2-DB-Instance. Diese Einstellung steuert mehr Verhaltensweisen für Aurora Serverless v2-DB-Instances als für bereitgestellte DB-Instances.

In der AWS Management Console geben Sie diese Einstellung mithilfe der Failover-Prioritätsauswahl unter Zusätzliche Konfiguration für die Seiten Create database, Modify instance und Add reader an. Sie sehen diese Eigenschaft für vorhandene DB-Instances in der optionalen Spalte Priority tier(Prioritätsstufe) auf der Seite Databases (Datenbanken). Diese Eigenschaft können Sie auch der Detailseite für einen DB-Cluster oder eine DB-Instance entnehmen.

Bei bereitgestellten DB-Instances bestimmt die Auswahl der Stufe 0 bis 15 nur die Reihenfolge, in der Aurora entscheidet, welche Reader-DB-Instance während eines Failover-Vorgangs zum Writer hochgestuft werden soll. Für Aurora Serverless v2-Reader-DB-Instances bestimmt die Stufennummer auch, ob die DB-Instance auf die Kapazität der Writer-DB-Instance hochskaliert oder unabhängig und basierend auf ihrer eigenen Workload skaliert wird. Aurora Serverless v2-Reader-DB-Instances in Stufe 0 oder 1 werden auf einer minimalen Kapazität gehalten, die mindestens so hoch ist wie die der Writer-DB-Instance. Auf diese Weise sind sie im Falle eines Failovers zur Übernahme von der Writer-DB-Instance bereit. Wenn die Writer-DB-Instance eine bereitgestellte DB-Instance ist, schätzt Aurora die entsprechende Aurora Serverless v2-Kapazität. Sie verwendet diese Schätzung als Mindestkapazität für die Aurora Serverless v2-Reader-DB-Instance.

Aurora Serverless v2-Reader-DB-Instances der Stufen 2 bis 15 haben nicht die gleiche Einschränkung ihrer minimalen Kapazität. Wenn sie inaktiv sind, können sie auf den Mindestwert der Aurora-Kapazitätseinheit (ACU) herunterskaliert werden, der im Kapazitätsbereich des Clusters angegeben ist.

Das folgende AWS CLI Linux-Beispiel zeigt, wie Sie die Promotion-Stufen aller DB-Instances in Ihrem Cluster untersuchen können. Das letzte Feld enthält den Wert True für die Writer-DB-Instance und False für alle Reader-DB-Instances.

$ aws rds describe-db-clusters --db-cluster-identifier promotion-tier-demo \
  --query 'DBClusters[*].DBClusterMembers[*].[PromotionTier,DBInstanceIdentifier,IsClusterWriter]' \
  --output text

1   instance-192  True
1   tier-01-4840  False
10  tier-10-7425  False
15  tier-15-6694  False

Das folgende AWS CLI Linux-Beispiel zeigt, wie Sie die Upgrade-Stufe einer bestimmten DB-Instance in Ihrem Cluster ändern können. Mit den Befehlen wird zuerst die DB-Instance geändert und eine neue Hochstufungsstufe festgelegt. Dann wird gewartet, bis die DB-Instance wieder verfügbar ist, und die neue Hochstufungsstufe für die DB-Instance bestätigt.

$ aws rds modify-db-instance --db-instance-identifier instance-192 --promotion-tier 0
$ aws rds wait db-instance-available --db-instance-identifier instance-192
$ aws rds describe-db-instances --db-instance-identifier instance-192 \
  --query '*[].[PromotionTier]' --output text
0

Weitere Hilfestellung zum Angeben von Hochstufungsstufen für verschiedene Anwendungsfälle finden Sie unter Aurora Serverless v2-Skalierung.

Verwenden vonTLS/SSLmit Aurora Serverless v2

Aurora Serverless v2kann das Transport Layer Security/Secure Sockets Layer (TLS/SSL) -Protokoll verwenden, um die Kommunikation zwischen Clients und Ihren Aurora Serverless v2 DB-Instances zu verschlüsseln. Es unterstützt die SSL VersionenTLS//1.0, 1.1 und 1.2. Allgemeine Informationen zur Verwendung vonTLS/SSLmit Aurora finden Sie unterTLSVerbindungen zu Aurora My SQL DB-Clustern.

Weitere Informationen zum Herstellen einer Verbindung mit Aurora My SQL Database mit dem My SQL Client finden Sie unter Verbindung zu einer DB-Instance herstellen, auf der die My SQL Database-Engine ausgeführt wird.

Aurora Serverless v2unterstützt alle TLS SSL /-Modi, die für den My SQL Client (mysql) und den SQL Postgre-Client (psql) verfügbar sind, einschließlich der in der folgenden Tabelle aufgeführten.

Beschreibung des Modus „TLS/SSL“	mysql-	psql
Connect, ohneTLS/zu verwendenSSL.	DISABLED	disable
Versuchen Sie SSL zunächst, die Verbindung mitTLS/herzustellen, greifen Sie aber SSL gegebenenfalls auf non- zurück.	PREFERRED	bevorzugen (Standard)
Erzwingen Sie die Verwendung vonTLS/SSL.	REQUIRED	require
Erzwingen SieTLS/SSLund überprüfen Sie die Zertifizierungsstelle (CA).	VERIFY_CA	verify-ca
Erzwingen SieTLS/SSL, überprüfen Sie die CA und verifizieren Sie den CA-Hostnamen.	VERIFY_IDENTITY	verify-full

Aurora Serverless v2 nutzt Platzhalter-Zertifikate. Wenn Sie die Option „Verify CA“ oder „Verify CA and CA Hostname“ angeben, wenn SieTLS/verwendenSSL, laden Sie zuerst den Amazon Root CA 1 Trust Store von Amazon Trust Services herunter. Danach können Sie diese PEM -formatierte Datei in Ihrem Client-Befehl identifizieren. Gehen Sie wie folgt vor, um dies mit dem SQL Postgre-Client zu tun.

Für LinuxmacOS, oderUnix:

psql 'host=endpoint user=user sslmode=require sslrootcert=amazon-root-CA-1.pem dbname=db-name'

Weitere Informationen zur Arbeit mit der Aurora SQL Postgres-Datenbank mithilfe des Postgres-Clients finden Sie unter Verbindung zu einer DB-Instance herstellen, auf der die SQL Postgre-Datenbank-Engine ausgeführt wird.

Weitere Informationen zum Verbinden mit Aurora-DB-Clustern im Allgemeinen finden Sie unter Herstellen einer Verbindung mit einem Amazon Aurora-DB-Cluster.

Unterstützte Verschlüsselungssammlungen für Verbindungen mit Aurora Serverless v2-DB-Clustern

Durch die Verwendung von konfigurierbaren Chiffrier-Suiten können Sie mehr Kontrolle über die Sicherheit Ihrer Datenbankverbindungen haben. Sie können eine Liste von Cipher Suites angeben, denen Sie erlauben möchten, TLS Client-/Verbindungen zu Ihrer Datenbank zu sichern. SSL Mit konfigurierbaren Chiffrier-Suiten können Sie die Verbindungsverschlüsselung steuern, die Ihr Datenbankserver akzeptiert. Dadurch wird die Verwendung von Verschlüsselungsverfahren verhindert, die nicht sicher sind oder nicht mehr verwendet werden.

Aurora Serverless v2DB-Cluster, die auf Aurora My basieren, SQL unterstützen dieselben Cipher Suites wie die von Aurora My SQL bereitgestellten DB-Cluster. Weitere Informationen über diese Verschlüsselungssammlungen finden Sie unter Konfiguration von Cipher Suites für Verbindungen zu Aurora My SQL DB-Clustern.

Aurora Serverless v2DB-Cluster, die auf Aurora Postgre basieren, SQL unterstützen dieselben Cipher Suites wie von Aurora Postgre SQL bereitgestellte DB-Cluster. Weitere Informationen über diese Verschlüsselungssammlungen finden Sie unter Konfiguration von Cipher Suites für Verbindungen zu Aurora SQL Postgre-DB-Clustern.

Anzeigen von Aurora Serverless v2-Writern und -Readern

Sie können sich die Details von Aurora Serverless v2-DB-Instances auf die gleiche Weise anzeigen lassen wie für bereitgestellte DB-Instances. Befolgen Sie hierzu das allgemeine Verfahren unter Anzeigen eines Amazon Aurora-DB-Clusters. Ein Cluster könnte alle Aurora Serverless v2-DB-Instances, alle bereitgestellten DB-Instances oder jeweils einige davon enthalten.

Nachdem Sie eine oder mehrere Aurora Serverless v2-DB-Instances erstellt haben, können Sie anzeigen, welche DB-Instances den Typ Serverless (Serverlos) und welche den Typ Instance haben. Sie können auch die minimalen und maximalen Aurora-Kapazitätseinheiten (ACUs) anzeigen, die die Aurora Serverless v2 DB-Instance verwenden kann. Jede ACU ist eine Kombination aus Verarbeitungs- (CPU) und Speicherkapazität (RAM). Dieser Kapazitätsbereich gilt für jede Aurora Serverless v2-DB-Instance im Cluster. Informationen zum Verfahren zur Überprüfung des Kapazitätsbereichs eines Clusters oder einer Aurora Serverless v2-DB-Instance im Cluster finden Sie unter Überprüfen des Kapazitätsbereichs für Aurora Serverless v2.

In der AWS Management Console sind Aurora Serverless v2 DB-Instances in der Spalte Größe auf der Datenbankseite markiert. Bei bereitgestellten DB-Instances wird der Name einer DB-Instance-Klasse wie r6g.xlarge angezeigt. Die Aurora Serverless-DB-Instances zeigen Serverless (Serverlos) für die DB-Instance-Klasse sowie die minimale und maximale Kapazität der DB-Instance an. Beispielsweise könnten Sie Serverless v2 (4—64ACUs) oder Serverless v2 (1—40) sehen. ACUs

Die gleichen Informationen finden Sie auf dem Tab Configuration (Konfiguration) für jede Aurora Serverless v2-DB-Instance in der Konsole. Sie sehen beispielsweise einen Abschnitt Instance type (Instance-Typ) wie den folgenden. Hier ist der Wert für den Instanztyp Serverless v2, der Wert für die Mindestkapazität 2 ACUs (4 GiB) und der Wert für die maximale Kapazität 64 ACUs (128 GiB).

Sie können die Kapazität jeder einzelnen Aurora Serverless v2-DB-Instance im Zeitverlauf überwachen. Auf diese Weise können Sie den Mindest-, Höchst- und ACUs Durchschnittsverbrauch jeder DB-Instance überprüfen. Sie können auch überprüfen, wie nahe die DB-Instance an ihre minimale oder maximale Kapazität gekommen ist. Um solche Details in der zu sehen AWS Management Console, sehen Sie sich die Diagramme der CloudWatch Amazon-Metriken auf der Registerkarte Überwachung für die DB-Instance an. Weitere Informationen über die angezeigten Metriken und ihre Interpretation finden Sie unter Wichtige CloudWatch Amazon-Metriken für Aurora Serverless v2.

Protokollierung für Aurora Serverless v2

Wenn Sie die Datenbankprotokollierung aktivieren möchten, geben Sie die Protokolle an, die mithilfe von Konfigurationsparametern in Ihrer benutzerdefinierten Parametergruppe aktiviert werden sollen.

Für Aurora My SQL können Sie die folgenden Protokolle aktivieren.

Aurora My SQL	Beschreibung
general_log	Erstellt das allgemeine Protokoll. Stellen Sie zum Einschalten auf 1. Die Standardeinstellung ist aus (0).
log_queries_not_using_indexes	Protokolliert alle Abfragen im Slow-Query-Protokoll, das keinen Index verwendet. Die Standardeinstellung ist aus (0). Stellen Sie auf 1 ein, um dieses Protokoll zu aktivieren.
long_query_time	Verhindert, dass Fast-Running-Queries im langsamen Slow-Query-Protokoll protokolliert werden. Kann auf einen Gleitkommawert zwischen 0 und 31536000 gesetzt werden. Die Standardeinstellung ist 0 (nicht aktiv).
server_audit_events	Die Liste der Ereignisse, die in den Protokollen erfasst werden sollen. Unterstützte Werte sind CONNECT, QUERY, QUERY_DCL, QUERY_DDL, QUERY_DML und TABLE.
server_audit_logging	Setzen Sie den Parameter auf 1, um die Serverprüfungsprotokollierung zu aktivieren. Wenn Sie diese Option aktivieren, können Sie die Prüfereignisse angeben, an die gesendet CloudWatch werden soll, indem Sie sie im server_audit_events Parameter auflisten.
slow_query_log	Erstellt ein Slow-Query-Protokoll. Auf 1 setzen, um das Slow-Query-Protokoll zu aktivieren. Die Standardeinstellung ist aus (0).

Weitere Informationen finden Sie unter Verwenden von Advanced Auditing in einem Amazon Aurora MySQL DB-Cluster.

Für Aurora Postgre SQL können Sie die folgenden Protokolle auf Ihren Aurora Serverless v2 DB-Instances aktivieren.

Aurora Postgret SQL	Beschreibung
log_connections	Protokolliert jede erfolgreiche Verbindung.
log_disconnections	Protokolliert das Ende einer Sitzung einschließlich der Dauer.
log_lock_waits	Der Standardwert ist 0 (aus). Stellen Sie auf 1 ein, um die Wartezeiten für die Sperrung zu protokollieren.
log_min_duration_statement	Die Mindestdauer (in Millisekunden), die eine Anweisung vor der Protokollierung ausgeführt wird.
log_min_messages	Legt die Nachrichtenebenen fest, die protokolliert werden. Unterstützte Werte sind , , , , , , , , , , und debug5, debug4, debug3, debug2, debug1, info, notice, warning, error, log, fatal, panic. Zum Protokollieren von Leistungsdaten im postgres-Protokoll, setzen Sie den Wert auf debug1 .
log_temp_files	Protokolliert die Verwendung von temporären Dateien, die über den angegebenen Kilobyte (kB) liegen.
log_statement	Steuert die spezifischen SQL Anweisungen, die protokolliert werden. Unterstützte Werte sind none, ddl, mod und all. Der Standardwert ist none.

Themen

• Protokollierung mit Amazon CloudWatch
• Aurora Serverless v2Logs in Amazon anzeigen CloudWatch
• Kapazität mit Amazon überwachen CloudWatch

Protokollierung mit Amazon CloudWatch

Nachdem Sie das Verfahren unter verwendet haben, Protokollierung für Aurora Serverless v2 um auszuwählen, welche Datenbankprotokolle aktiviert werden sollen, können Sie auswählen, welche Protokolle auf Amazon hochgeladen („veröffentlicht“) werden sollen CloudWatch.

Sie können Amazon verwenden CloudWatch , um Protokolldaten zu analysieren, Alarme zu erstellen und Metriken anzuzeigen. Standardmäßig sind Fehlerprotokolle für aktiviert und Aurora Serverless v2 werden automatisch in hochgeladen CloudWatch. Sie können auch andere Protokolle von Aurora Serverless v2 DB-Instances in hochladen CloudWatch.

Dann wählen Sie aus, in welche dieser Protokolle Sie hochladen möchten CloudWatch, indem Sie die Einstellungen für Protokollexporte in AWS Management Console oder die --enable-cloudwatch-logs-exports Option in der verwenden AWS CLI.

Sie können wählen, in welche Ihrer Aurora Serverless v2 Protokolle Sie hochladen möchten CloudWatch. Weitere Informationen finden Sie unter Verwenden von Advanced Auditing in einem Amazon Aurora MySQL DB-Cluster.

Wie bei jedem Typ von Aurora-DB-Cluster können Sie die standardmäßige DB-Cluster-Parametergruppe nicht ändern. Erstellen Sie stattdessen Ihre eigene DB-Cluster-Parametergruppe basierend auf einem Standardparameter für Ihren DB-Cluster und Engine-Typ. Sie sollten Ihre benutzerdefinierte DB-Cluster-Parametergruppe erstellen, bevor Sie Ihren Aurora Serverless v2-DB-Cluster erstellen, damit Sie diese auswählen können, wann Sie eine Datenbank in der Konsole erstellen.

Anmerkung

Bei Aurora Serverless v2 können Sie sowohl DB-Cluster- als auch DB-Parametergruppen erstellen. Im Gegensatz dazu können Sie bei Aurora Serverless v1 nur DB-Cluster-Parametergruppen erstellen.

Aurora Serverless v2Logs in Amazon anzeigen CloudWatch

Nachdem Sie das Verfahren unter Protokollierung mit Amazon CloudWatch verwendet haben, um auszuwählen, welche Datenbankprotokolle aktiviert werden sollen, können Sie den Inhalt der Protokolle anzeigen.

Weitere Informationen zur Verwendung CloudWatch mit Aurora My SQL - und Aurora SQL Postgre-Protokollen finden Sie unter Überwachen von Protokollereignissen in Amazon CloudWatch undVeröffentlichen von Aurora-PostgreSQL-Protokollen in Amazon CloudWatch Logs.

So zeigen Sie Protokolle für Ihren Aurora Serverless v2-DB-Cluster an:

1. Öffnen Sie die CloudWatch Konsole unter. https://console.aws.amazon.com/cloudwatch/

2. Wähle deine AWS-Region.

3. Wählen Sie Protokollgruppen.

4. Wählen Sie Ihr DB-Cluster-Protokoll für Aurora Serverless v2 in der Liste aus. Bei Protokollen ist das Benennungsmuster wie folgt.

   /aws/rds/cluster/cluster-name/log_type

Anmerkung

Für Aurora My SQL —kompatible Aurora Serverless v2 DB-Cluster enthält das Fehlerprotokoll Ereignisse zur Skalierung des Pufferpools, auch wenn keine Fehler vorliegen.

Kapazität mit Amazon überwachen CloudWatch

Mit Aurora Serverless v2 CloudWatch können Sie die Kapazität und Auslastung aller Aurora Serverless v2 DB-Instances in Ihrem Cluster überwachen. Sie können Metriken auf Instance-Ebene anzeigen, um die Kapazität jeder einzelnen Aurora Serverless v2-DB-Instance beim Hoch- und Herunterskalieren zu überprüfen. Sie können die kapazitätsbezogenen Metriken auch mit anderen Metriken vergleichen, um zu sehen, wie sich Änderungen an Workloads auf den Ressourcenverbrauch auswirken. Sie können beispielsweise ServerlessDatabaseCapacity mit DatabaseUsedMemory, DatabaseConnections und DMLThroughput vergleichen, um einzuschätzen, wie Ihr DB-Cluster während des Betriebs reagiert. Weitere Informationen zu den kapazitätsbezogenen Metriken, die für Aurora Serverless v2 gelten, finden Sie unter Wichtige CloudWatch Amazon-Metriken für Aurora Serverless v2.

So überwachen Sie die Kapazität Ihres Aurora Serverless v2-DB-Clusters:

1. Öffnen Sie die CloudWatch Konsole unter https://console.aws.amazon.com/cloudwatch/.

2. Wählen Sie Metrics (Metriken) aus. Alle verfügbaren Metriken werden in der Konsole als Karten angezeigt, gruppiert nach Servicename.

3. Wähle RDS.

4. (Optional) Verwenden Sie das Feld Suchen (Search), um die Metriken zu finden, die für Aurora Serverless v2 besonders wichtig sind: ServerlessDatabaseCapacity, ACUUtilization, CPUUtilization und FreeableMemory.

Wir empfehlen Ihnen, ein CloudWatch Dashboard einzurichten, um Ihre Aurora Serverless v2 DB-Cluster-Kapazität anhand der kapazitätsbezogenen Metriken zu überwachen. Wie das geht, erfahren Sie unter Dashboards erstellen mit. CloudWatch

Weitere Informationen zur Verwendung von Amazon CloudWatch mit Amazon Aurora finden Sie unterVeröffentlichen von Amazon Aurora MySQL-Protokollen in Amazon CloudWatch Logs.