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 Aurora Serverless v2 DB-Cluster

Mit Aurora Serverless v2, Ihre Cluster sind mit bereitgestellten Clustern austauschbar. Das Tool 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 Verwaltungsaspekte für Cluster, die Folgendes enthalten Aurora Serverless v2 DB-Instances.

Einstellung der Aurora Serverless v2 Kapazitätsbereich für einen Cluster

Um Konfigurationsparameter oder andere Einstellungen für Cluster zu ändern, die Aurora Serverless v2 DB-Instances oder die DB-Instances selbst folgen den gleichen allgemeinen Verfahren wie für bereitgestellte Cluster. Details hierzu finden Sie unter Ändern eines Amazon Aurora-DB-Clusters.

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

Sie können die folgenden spezifischen Werte festlegen:

Neuere DB-Engine-Versionen ermöglichen eine maximale Kapazität von 256ACUs. Die Kapazitätsbereiche für verschiedene DB-Engine-Versionen finden Sie unterAurora Serverless v2 Kapazität.

Weitere Informationen dazu, wie Sie sicherstellen können, dass Aurora Serverless v2 DB-Cluster können auf bis zu 256 skaliert werdenACUs, sieheAktualisieren Sie Ihre Aurora Serverless v2 DB-Cluster, um die Skalierung auf 256 zu ermöglichen ACUs.

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 Leistung 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 enger 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 jeden 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. 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 legt automatisch bestimmte Parameter fest für Aurora Serverless v2 DB-Instances auf Werte, die vom ACU Maximalwert im Kapazitätsbereich abhängen. Eine Liste dieser Parameter finden Sie unter Maximale Anzahl an 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 Sie Ihre Aurora Serverless v2 DB-Cluster, um die Skalierung auf 256 zu ermöglichen ACUs

In einigen Fällen, wenn Sie versuchen, Ihre zu skalieren Aurora Serverless v2 Bei einem DB-Cluster auf Kapazitäten von mehr als 128 ACUs erhalten Sie eine Fehlermeldung. In der Fehlermeldung erfahren Sie, welche Instances mit dem neuen Skalierungsbereich nicht kompatibel sind.

Die Unfähigkeit, auf mehr als 128 zu skalieren, ACUs kann aus einem von zwei Gründen auftreten:

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

Das Verfahren zur Überprüfung des Kapazitätsbereichs für Ihr Aurora Serverless v2 Für den Cluster müssen Sie zuerst einen Kapazitätsbereich festlegen. Wenn Sie dies noch nicht getan haben, gehen Sie wie unter Einstellung der Aurora Serverless v2 Kapazitätsbereich für einen Cluster beschrieben vor.

Der Kapazitätsbereich, den Sie auf Clusterebene 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 anzeigen Aurora Serverless v2 DB-Instance im Cluster. 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 Einstellung der Aurora Serverless v2 Kapazitätsbereich für einen Cluster.

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

Sie können den Kapazitätsbereich überprüfen, für den konfiguriert ist Aurora Serverless v2 DB-Instances in einem Cluster, indem Sie das ServerlessV2ScalingConfiguration Attribut für den Cluster untersuchen. 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 reader

Um ein hinzuzufügen Aurora Serverless v2 Für die Reader-DB-Instance zu Ihrem Cluster verwenden Sie dasselbe allgemeine Verfahren wie unterHinzufü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 ist Aurora Serverless v2 Bei der DB-Instance im Cluster 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 jede andere Aurora Serverless v2 DB-Instances, die Sie dem Cluster hinzufügen. Jeder Aurora Serverless v2 Die DB-Instance kann zwischen den Minimal- und ACU Maximalwerten skalieren.

Wenn Sie bereits welche hinzugefügt haben Aurora Serverless v2 DB-Instances zum Cluster, Hinzufügen weiterer Aurora Serverless v2 Die Reader-DB-Instance zeigt Ihnen den aktuellen Kapazitätsbereich. 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 Einstellung der Aurora Serverless v2 Kapazitätsbereich für einen Cluster bechrieben.

Bei Clustern, die mehr als eine Reader-DB-Instance enthalten, die Failover-Priorität der einzelnen Aurora Serverless v2 Die Reader-DB-Instance spielt eine wichtige Rolle dabei, wie diese DB-Instance nach oben und unten skaliert wird. 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 Auswahl der Promotion-Stufe für ein Aurora Serverless v2 reader.

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

Konvertierung eines bereitgestellten Writer- oder Lesegeräts in Aurora Serverless v2

Sie können eine bereitgestellte DB-Instance konvertieren, um Aurora Serverless v2. Folgen Sie dazu dem Verfahren 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. Zum Beispiel Aurora Serverless v2 DB-Instances erfordern, dass auf dem Cluster bestimmte Engine-Mindestversionen ausgeführt werden.

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

Wenn die DB-Instance, die Sie konvertieren, die erste ist Aurora Serverless v2 DB-Instance im Cluster: Sie wählen den Kapazitätsbereich für den Cluster im Rahmen des Modific-Vorgangs aus. Dieser Kapazitätsbereich gilt für jeden 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 Aurora Serverless v2 Kapazität.

Wenn der Cluster bereits eine oder mehrere enthält Aurora Serverless v2 Bei DB-Instances sehen Sie den vorhandenen Kapazitätsbereich während des Modifizierungsvorgangs. 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 hinzugefügt haben Aurora Serverless v2 Gehen Sie für DB-Instances wie unter beschrieben vorEinstellung der Aurora Serverless v2 Kapazitätsbereich für einen Cluster.

Konvertiere eine Aurora Serverless v2 Writer oder Reader in ein bereitgestelltes

Sie können eine konvertieren Aurora Serverless v2 DB-Instance in eine bereitgestellte DB-Instance. 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önnten eine konvertieren Aurora Serverless v2 DB-Instance wird bereitgestellt, wenn sie eine größere Kapazität benötigt, als sie mit den maximalen Aurora-Kapazitätseinheiten (ACUs) einer Aurora Serverless v2 DB-Instance. Beispielsweise haben die größten DB-Instance-Klassen db.r5 und db.r6g eine größere Speicherkapazität als Aurora Serverless v2 Die DB-Instance kann auf skaliert werden.

Wenn Sie die Writer-DB-Instance Ihres Clusters von konvertieren Aurora Serverless v2 In bereitgestellt können Sie das Verfahren in umgekehrter Wechsel von einem bereitgestellten Cluster zu Aurora Serverless v2 Reihenfolge ausführen. Wechseln Sie zu einer der Reader-DB-Instances im Cluster von Aurora Serverless v2 zu bereitgestellt. 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 werden aus dem Cluster entfernt. Wenn Sie den Kapazitätsbereich ändern möchten, können Sie den Cluster ändern, wie in Einstellung der Aurora Serverless v2 Kapazitätsbereich für einen Cluster erläutert.

Auswahl der Promotion-Stufe für ein Aurora Serverless v2 reader

Für Cluster mit mehreren Aurora Serverless v2 DB-Instances oder eine Mischung aus bereitgestellten und Aurora Serverless v2 Achten Sie bei DB-Instances auf die jeweilige Einstellung für die jeweilige Promotion-Stufe Aurora Serverless v2 DB-Instance. Diese Einstellung steuert mehr Verhalten 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 Datenbank erstellen, Instanz ändern und Leser 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. Wählen Sie in der &Snowconsole; Ihren Auftrag aus der Tabelle. Aurora Serverless v2 Bei Reader-DB-Instances bestimmt die Tier-Nummer auch, ob die DB-Instance entsprechend der Kapazität der Writer-DB-Instance skaliert oder unabhängig von ihrer eigenen Arbeitslast skaliert wird. Aurora Serverless v2 Leser-DB-Instances der Stufe 0 oder 1 verfügen über eine Mindestkapazität, 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 es sich bei der Writer-DB-Instance um eine bereitgestellte DB-Instance handelt, schätzt Aurora das Äquivalent Aurora Serverless v2 Kapazität. Es verwendet diese Schätzung als Mindestkapazität für Aurora Serverless v2 Leser-DB-Instance.

Aurora Serverless v2 Reader-DB-Instances der Stufen 2—15 haben nicht die gleiche Beschränkung in Bezug auf ihre Mindestkapazitä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 v2 kann das Transport Layer Security/Secure Sockets Layer (TLS/SSL) -Protokoll verwenden, um die Kommunikation zwischen Clients und Ihrem Aurora Serverless v2 DB-Instances. 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 v2 unterstü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.

Aurora Serverless v2 verwendet Platzhalterzertifikate. 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.

Wählen Sie in der &Snowconsole; Ihren Auftrag aus der Tabelle. Linux, macOS, oder Unix:

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 Cipher Suites für Verbindungen zu Aurora Serverless v2 DB-Cluster

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 SSL Client-/Verbindungen zu Ihrer Datenbank zu sichern. 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 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 v2 DB-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.

Wird angezeigt Aurora Serverless v2 Autoren und Leser

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

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

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

Auf der Registerkarte „Konfiguration“ finden Sie jeweils dieselben Informationen 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 jedes einzelnen überwachen Aurora Serverless v2 DB-Instance im Laufe der Zeit. 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.

Weitere Informationen finden Sie unter Verwenden von Advanced Auditing mit einem Amazon Aurora My SQL DB-Cluster.

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

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 werden Fehlerprotokolle für Aurora Serverless v2 sind aktiviert und werden automatisch hochgeladen CloudWatch. Sie können auch andere Logs hochladen von Aurora Serverless v2 DB-Instances zu CloudWatch.

Dann wählen Sie aus, in welche dieser Protokolle hochgeladen werden sollen 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, welches Ihrer Aurora Serverless v2 Logs, in die hochgeladen werden soll CloudWatch. Weitere Informationen finden Sie unter Verwenden von Advanced Auditing mit einem Amazon Aurora My SQL 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. Wir empfehlen, dass Sie Ihre benutzerdefinierte DB-Cluster-Parametergruppe erstellen, bevor Sie Ihre Aurora Serverless v2 DB-Cluster, sodass Sie ihn auswählen können, wenn Sie eine Datenbank auf der Konsole erstellen.

Wird angezeigt Aurora Serverless v2 loggt sich bei Amazon ein 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 undAurora SQL Postgre-Protokolle in Amazon CloudWatch Logs veröffentlichen.

Kapazität mit Amazon überwachen CloudWatch

Mit Aurora Serverless v2, können Sie verwenden, CloudWatch um die Kapazität und Auslastung aller Aurora Serverless v2 DB-Instances in Ihrem Cluster. Sie können Metriken auf Instanzebene einsehen, um die Kapazität der einzelnen Instanzen zu überprüfen Aurora Serverless v2 Die DB-Instance beim Hoch- und Herunterskalieren. 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. Einzelheiten zu den kapazitätsbezogenen Kennzahlen, die gelten für Aurora Serverless v2, finden Sie unter Wichtige CloudWatch Amazon-Metriken für Aurora Serverless v2.

Wir empfehlen Ihnen, ein CloudWatch Dashboard einzurichten, um Ihre Aurora Serverless v2 DB-Cluster-Kapazität unter Verwendung der kapazitätsbezogenen Metriken. 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.