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.

Verwalten 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 DB-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 die Überlegungen im Hinblick auf die Verwaltung von Clustern, 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 Werte für die minimale und maximale Aurora-Kapazitätseinheit (ACU) für einen Aurora-Cluster festgelegt haben, müssen Sie die Kapazität der Aurora Serverless v2-DB-Instances im Cluster 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 die gleichen minimalen und maximalen ACU-Werte.

Sie können die folgenden spezifischen Werte festlegen:

Der verfügbare Kapazitätsbereich für Aurora Serverless v2 ist sowohl von der DB-Engine-Version als auch von der Plattformversion abhängig. Neuere DB-Engine-Versionen ermöglichen eine maximale Kapazität von 256 ACUs, eine Mindestkapazität von 0 ACUs oder beides. Die Kapazitätsbereiche für verschiedene DB-Engine-Versionen finden Sie unter Kapazität von Aurora Serverless v2.

Informationen zur Funktion zum automatischen Anhalten und Fortsetzen, die durch Festlegen der Mindestkapazität auf 0 ACUs aktiviert wird, finden Sie unter Skalierung auf 0 ACUs mit automatischem Anhalten und Fortsetzen für Aurora Serverless v2.

Weitere Informationen dazu, wie Sie sicherstellen können, dass Ihre Aurora Serverless v2-DB-Cluster auf bis zu 256 ACUs skaliert werden können, finden Sie unter Aktualisieren des Aurora Serverless v2-DB-Clusters, um eine Skalierung auf 256 ACUs zu ermöglichen.

In Aurora Serverless v2 können Sie die aktuelle Kapazität nicht direkt festlegen, ohne den Kapazitätsbereich zu ändern, da die Kapazität dynamisch an die Workload innerhalb des angegebenen Bereichs angepasst wird. Sie können jedoch die Kapazität auf eine der folgenden Arten indirekt beeinflussen:

Weitere Informationen zu den Auswirkungen des Kapazitätsbereichs und zur Überwachung und Feinabstimmung finden Sie unter Wichtige Amazon-CloudWatch-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 bestimmen basierend auf Ihrer Überwachung, 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 mit der AWS-Managementkonsole, der AWS CLI oder der Amazon RDS API auf einen bestimmten Bereich von ACUs festlegen. Dieser Kapazitätsbereich gilt für jede Aurora Serverless v2-DB-Instance im Cluster.

Angenommen, Ihr Cluster hat einen Kapazitätsbereich von 1 bis 16 ACUs und enthält zwei Aurora Serverless v2-DB-Instances. Dann verbraucht der Cluster insgesamt zwischen 2 ACUs (bei Inaktivität) und 32 ACUs (bei Vollauslastung). Wenn Sie den Kapazitätsbereich von 8 in 40,5 ACUs ändern, verbraucht der gesamte Cluster jetzt 16 ACUs bei Inaktivität und bei voller Auslastung bis zu 81 ACUs.

Aurora legt automatisch bestimmte Parameter für Aurora Serverless v2-DB-Instances auf Werte fest, die vom maximalen ACU-Wert 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.

Aktualisieren des Aurora Serverless v2-DB-Clusters, um eine Skalierung auf 256 ACUs zu ermöglichen

In einigen Fällen erhalten Sie eine Fehlermeldung, wenn Sie versuchen, Ihren Aurora Serverless v2-DB-Cluster auf Kapazitäten von mehr als 128 ACUs zu skalieren. In der Fehlermeldung erfahren Sie, welche Instances mit dem neuen Skalierungsbereich nicht kompatibel sind. Dies unterstreicht die wichtige Beziehung zwischen Ihrem Kapazitätsbereich, der DB-Engine-Version und der Plattformversion.

Es gibt zwei mögliche Ursachen dafür, dass eine Skalierung auf mehr als 128 ACUs nicht möglich ist:

Ü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. 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 minimalen Kapazität von 0,5 Aurora-Kapazitätseinheiten (ACU) und einer maximalen Kapazität von 16 ACUs.

$ 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. 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 dem minimalen und dem maximalen ACU-Wert skaliert werden.

Wenn im Cluster bereits andere Aurora Serverless v2-Instances vorhanden sind, zeigt das Dialogfeld Reader hinzufügen den aktuellen Kapazitätsbereich für den Cluster an. In diesem Fall können Sie die Kapazität nicht ändern. Die folgende Abbildung zeigt den Bericht über die Kapazität des aktuellen Clusters.

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 Instance konvertieren, wenn sie eine größere Kapazität benötigt, als 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.

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.

Anhalten von Aurora Serverless v2-DB-Instances

Sie können Aurora-Cluster so konfigurieren, dass ihre Aurora Serverless v2-DB-Instances automatisch angehalten und fortgesetzt werden. Weitere Informationen finden Sie unter Skalierung auf 0 ACUs mit automatischem Anhalten und Fortsetzen für Aurora Serverless v2.

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-Managementkonsole geben Sie diese Einstellung mit der Option Failover priority (Failover-Priorität) unter Additional configuration (Zusätzliche Konfiguration) auf den Seiten Create database (Datenbank erstellen), Modify Instance (Instance ändern) und Add reader (Reader hinzufügen) 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 minimalen Aurora-Kapazitätseinheitwert (ACU) herunterskaliert werden, der im Kapazitätsbereich des Clusters angegeben ist.

Das folgende AWS CLI-Beispiel für Linux zeigt, wie Sie die Hochstufungsstufen aller DB-Instances in Ihrem Cluster untersuchen. 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-Beispiel für Linux zeigt, wie Sie die Hochstufungsstufe einer bestimmten DB-Instance in Ihrem Cluster ändern. 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 von TLS/SSL mit Aurora Serverless v2

Aurora Serverless v2 kann das TLS-/SSL-Protokoll (Transport Layer Security/Secure Sockets Layer) verwenden, um die Kommunikation zwischen Clients und den Aurora Serverless v2-DB-Instances zu verschlüsseln. Die TLS-/SSL-Versionen 1.0, 1.1 und 1.2 werden unterstützt. Allgemeine Informationen zur Verwendung von TLS/SSL mit Aurora finden Sie unter TLS-Verbindungen mit DB-Clustern von Aurora MySQL.

Weitere Informationen zum Verbinden mit der Aurora MySQL-Datenbank über den MySQL-Client finden Sie unter Verbinden mit einer DB-Instance, auf der die MySQL-Datenbank-Engine ausgeführt wird.

Aurora Serverless v2 unterstützt alle für den MySQL-Client (mysql) und PostgreSQL-Client (psql) verfügbaren TLS-/SSL-Modi, einschließlich der in der folgenden Tabelle aufgeführten.

Aurora Serverless v2 nutzt Platzhalter-Zertifikate. Wenn Sie bei Verwendung von TLS/SSL die Option "CA überprüfen" oder "CA und CA-Hostnamen überprüfen" angeben, 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 folgendermaßen vor, um diesen Vorgang mit dem PostgreSQL-Client auszuführen.

Für Linux, macOS oder Unix:

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

Weitere Informationen zum Arbeiten mit der Aurora PostgreSQL-Datenbank unter Verwendung des Postgres-Clients finden Sie unter Herstellen einer Verbindung zu einer DB-Instance, in der die PostgreSQL-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 Verschlüsselungssammlungen angeben, die Sie zum Sichern von TLS/SSL-Verbindungen zu Ihrer Datenbank des Clients zulassen möchten. 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 v2-DB-Cluster, die auf Aurora MySQL basieren, unterstützen dieselben Verschlüsselungssammlungen wie von Aurora MySQL bereitgestellte DB-Cluster. Weitere Informationen über diese Verschlüsselungssammlungen finden Sie unter Konfigurieren von Cipher-Suites für Verbindungen mit Aurora-MySQL-DB-Clustern.

Aurora Serverless v2-DB-Cluster, die auf Aurora MySQL basieren, unterstützen dieselben Verschlüsselungssammlungen wie von Aurora PostgreSQL bereitgestellte DB-Cluster. Weitere Informationen über diese Verschlüsselungssammlungen finden Sie unter Konfigurieren von Chiffrier-Suiten für Verbindungen mit Aurora-PostgreSQL-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 DB-Clusters von Amazon Aurora. 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. Außerdem können Sie die minimalen und maximalen Aurora-Kapazitätseinheiten (ACUs) anzeigen, die die Aurora Serverless v2-DB-Instance verwenden kann. Jede ACU ist eine Kombination aus Rechenkapazität (CPU) und Arbeitsspeicherkapazitä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-Managementkonsole sind Aurora Serverless v2-DB-Instances in der Spalte Size (Größe) der Seite Database (Datenbanken) gekennzeichnet. 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. Es wird beispielsweise Serverless v2 (4–64 ACUs) oder Serverless v2 (1–40 ACUs) angezeigt.

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 Instance type (Instance-Typ) Serverless v2, der Wert Minimum capacity (Minimale Kapazität) beträgt 2 ACUs (4 GiB) und der Wert Maximum capacity (Maximale Kapazität) ist auf 64 ACUs (128 GiB) festgelegt.

Sie können die Kapazität jeder einzelnen Aurora Serverless v2-DB-Instance im Zeitverlauf überwachen. Auf diese Weise können Sie die minimalen, maximalen und durchschnittlichen ACUs überprüfen, die von jeder DB-Instance verbraucht werden. Sie können auch überprüfen, wie nahe die DB-Instance an ihre minimale oder maximale Kapazität gekommen ist. Wenn Sie solche Details in der AWS-Managementkonsole anzeigen möchten, untersuchen Sie die Grafiken der Amazon-CloudWatch-Metriken auf dem Tab Monitoring (Überwachung) für die DB-Instance. Weitere Informationen über die angezeigten Metriken und ihre Interpretation finden Sie unter Wichtige Amazon-CloudWatch-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 MySQL können Sie die folgenden Protokolle aktivieren.

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

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

Protokollieren mit Amazon CloudWatch

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

Mit Amazon CloudWatch können Sie Protokolldaten analysieren, Alarme erstellen und Metriken anzeigen lassen. Standardmäßig werden Fehlerprotokolle für Aurora Serverless v2 aktiviert und automatisch auf CloudWatch hochgeladen. Sie können auch andere Protokolle von Aurora Serverless v2-DB-Instances auf CloudWatch hochladen.

In diesem Fall wählen Sie aus, welches dieser Protokolle auf CloudWatch hochgeladen werden soll, indem Sie die Einstellungen Log exports (Protokollexporte) in der AWS-Managementkonsole oder die Option --enable-cloudwatch-logs-exports in der AWS CLI verwenden.

Sie können auswählen, welches Ihrer Aurora Serverless v2-Protokolle auf CloudWatch hochgeladen werden soll. 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.

Anzeigen von Aurora Serverless v2-Protokollen in Amazon CloudWatch

Nachdem Sie das Verfahren unter Protokollieren 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 von CloudWatch mit Aurora-MySQL- und Aurora-PostgreSQL-Protokollen finden Sie unter Überwachung von Protokollereignissen in Amazon CloudWatch und Veröffentlichen von Aurora-PostgreSQL-Protokollen in Amazon CloudWatch Logs.

Überwachen der Kapazität mit Amazon CloudWatch

Mit Aurora Serverless v2 können Sie CloudWatch verwenden, um die Kapazität und Auslastung aller Aurora Serverless v2-DB-Instances in Ihrem Cluster zu ü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 Amazon-CloudWatch-Metriken für Aurora Serverless v2.

Wir empfehlen Ihnen, ein CloudWatch-Dashboard einzurichten, um die Kapazität Ihres Aurora Serverless v2-DB-Clusters mit dieser kapazitätsbezogenen Metrik zu überwachen. Informationen dazu finden Sie unter Erstellen von Dashboards mit CloudWatch.

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

Überwachen von Aurora Serverless v2-Aktivitäten zum Anhalten und Fortsetzen

Aurora schreibt eine separate Protokolldatei für Aurora Serverless v2-DB-Instances mit aktivierter Auto-Pause-Funktion. Aurora schreibt für jedes 10-Minuten-Intervall, in dem die Instance nicht angehalten wurde, in das Protokoll. Aurora speichert bis zu sieben dieser Protokolle, die täglich rotiert werden. Die aktuelle Protokolldatei hat den Namen instance.log und ältere Protokolle werden nach dem Muster instance.YYYY-MM-DD.N.log benannt.

Dieses Protokoll ist für Aurora Serverless v2-DB-Instances standardmäßig aktiviert, bei denen die Auto-Pause-Funktion aktiviert ist. Sie können den Inhalt dieses Protokolls in der AWS-Managementkonsole oder mithilfe der AWS CLI oder RDSP-API anzeigen. Derzeit ist es nicht möglich, dieses Protokoll in CloudWatch hochzuladen.

Die unter DB-Instance-Ereignisse aufgeführten Ereignisse bieten einen allgemeinen Überblick über die Aktivitäten zum Anhalten und Fortsetzen, u. a. folgende:

instance.log bietet detailliertere Informationen zu den Gründen, warum eine Aurora Serverless v2-Instance angehalten oder nicht angehalten werden kann.

Das Protokoll könnte darauf hinweisen, dass eine Instance aus verschiedenen Gründen fortgesetzt wurde:

Wenn Aurora keine Bedingungen feststellt, die verhindern würden, dass die Instance nach Ablauf des Auto-Pause-Intervalls angehalten wird, wird regelmäßig eine Informationsmeldung in das Protokoll geschrieben. Bei Clustern mit nur einer DB-Instance enthält das Protokoll die folgende Meldung:

[INFO] No auto-pause blockers registered since time

Bei Clustern mit mehreren DB-Instances unterscheidet sich die Meldung geringfügig. Das liegt daran, dass ein Writer aufgrund von Aktivitäten auf einer der Reader-Instances möglicherweise nicht angehalten werden kann. Wenn die Aktivität auf dem Reader beendet wird, bevor das Auto-Pause-Intervall auf dem Writer abläuft, kann der Writer zur erwarteten Zeit angehalten werden.

[INFO] No auto-pause blockers registered since time.
Database might be required to maintain compute capacity for high availability.

Wenn eine Operation zum Anhalten gestartet wird, aber eine neue Datenbankverbindungsanforderung eingeht, bevor die Instance das Anhalten beendet hat, enthält das Protokoll die folgende Meldung:

[INFO] Unable to pause database due to a new database activity

Wenn Aurora Bedingungen feststellt, die definitiv verhindern, dass die Instance angehalten werden kann, enthält das Protokoll die folgende Meldung mit einer Auflistung aller dieser Bedingungen:

[INFO] Auto-pause blockers registered since time: list_of_conditions

Auf diese Weise verhindert Aurora nicht, dass Sie Replikation, Null-ETL-Integration, Aurora Global Database usw. in Kombination mit der Auto-Pause-Funktion aktivieren. Das Protokoll informiert Sie darüber, wenn die Verwendung solcher Funktionen möglicherweise verhindert, dass die Auto-Pause-Funktion wirksam wird.

Aus den folgenden Gründen kann eine Aurora Serverless v2-Instance das Timeout-Intervall für das automatische Anhalten überschreiten, aber daran gehindert werden, anzuhalten: