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.
# Verwenden von Amazon Aurora Serverless v1
**Wichtig**
AWS hat [den end-of-life Termin bekannt gegeben fürAurora Serverless v1: 31. März 2025](https://repost.aws/questions/QUhcMVoChXRm2HLi8F-yih1g/announcement-support-for-aurora-s/announcement-support-for-aurora-serverless-v1-ending-soon). Alle Aurora Serverless v1-Cluster, die bis zum 31. März 2025 nicht migriert wurden, werden während des Wartungsfensters zu Aurora Serverless v2 migriert. Wenn das Upgrade fehlschlägt, konvertiert Amazon Aurora den Serverless-v1-Cluster während des Wartungsfensters in einen bereitgestellten Cluster mit der entsprechenden Engine-Version. Falls zutreffend, registriert Amazon Aurora den konvertierten bereitgestellten Cluster bei Amazon RDS Extended Support. Weitere Informationen finden Sie unter [Amazon RDS Extended Support mit Amazon Aurora](extended-support.md).
Amazon Aurora Serverless v1 (Amazon Aurora Serverless Version 1) ist eine bedarfsabhängige Konfiguration der automatischen Skalierung für Amazon Aurora. Ein *Aurora Serverless v1-DB-Cluster* ist ein DB-Cluster, der die Rechenkapazität abhängig von den Anforderungen Ihrer Anwendung skaliert. Im Gegensatz dazu wird bei von Aurora *bereitgestellten DB-Clustern* die Kapazität manuell verwaltet. Aurora Serverless v1 bietet eine relativ einfache, kostengünstige Option für selten oder vorübergehend auftretende oder unvorhersehbare Workloads. Dies ist kosteneffektiv, weil es basierend auf den Anforderungen Ihrer Anwendung automatisch gestartet und die Rechenkapazität skaliert wird, sodass sie mit der Nutzung durch Ihre Anwendung übereinstimmt, und heruntergefahren wird, wenn es nicht verwendet wird.
Weitere Informationen zu den Preisen finden Sie unter [Serverless-Preise](https://aws.amazon.com/rds/aurora/pricing/) unter **MySQL-kompatible Edition** oder **PostgreSQL-kompatible Edition** auf der Seite Amazon Aurora pricing.
Aurora Serverless v1-Cluster verfügen über die gleiche Art von verteiltem und hochverfügbarem Speicher-Volumen mit hoher Kapazität, das von bereitgestellten DB-Clustern verwendet wird.
Bei einem Aurora Serverless v1-Cluster ist das Cluster-Volume immer verschlüsselt. Sie können den Verschlüsselungsschlüssel auswählen, aber Sie können die Verschlüsselung nicht deaktivieren. Das bedeutet, dass Sie für Aurora Serverless v1 die gleichen Vorgänge ausführen können wie für verschlüsselte Snapshots. Weitere Informationen finden Sie unter [Aurora Serverless v1 und Snapshots](aurora-serverless-v1.how-it-works.md#aurora-serverless.snapshots).
**Topics**
+ [Verfügbarkeit von Regionen und Versionen für Aurora Serverless v1](#aurora-serverless-v1-Availability)
+ [Vorteile von Aurora Serverless v1](#aurora-serverless-v1.advantages)
+ [Anwendungsfälle für Aurora Serverless v1](#aurora-serverless-v1.use-cases)
+ [Einschränkungen von Aurora Serverless v1](#aurora-serverless.limitations)
+ [Anforderungen an die Konfiguration von Aurora Serverless v1](#aurora-serverless-v1.requirements)
+ [Verwenden mit TLS/SSL Aurora Serverless v1](#aurora-serverless.tls)
+ [Funktionsweise von Aurora Serverless v1](aurora-serverless-v1.how-it-works.md)
+ [Erstellen eines Aurora Serverless v1-DB Clusters](aurora-serverless.create.md)
+ [Wiederherstellen eines Aurora Serverless v1-DB-Clusters](aurora-serverless.restorefromsnapshot.md)
+ [Ändern eines Aurora Serverless v1-DB-Clusters](aurora-serverless.modifying.md)
+ [Manuelles Skalieren der Kapazität des Aurora Serverless v1-DB-Clusters](aurora-serverless.setting-capacity.md)
+ [Anzeigen von Aurora Serverless v1-DB-Clustern](aurora-serverless.viewing.md)
+ [Löschen eines Aurora Serverless v1-DB-Clusters](aurora-serverless.delete.md)
+ [Aurora Serverless v1- und Aurora-Datenbank-Engine-Versionen](aurora-serverless.relnotes.md)
## Verfügbarkeit von Regionen und Versionen für Aurora Serverless v1
Die Verfügbarkeit von Funktionen und der Support variieren zwischen bestimmten Versionen der einzelnen Aurora-Datenbank-Engines und in allen AWS-Regionen. Weitere Informationen zur Verfügbarkeit von Versionen und Regionen im Zusammenhang mit Aurora und Aurora Serverless v1 finden Sie unter [Aurora Serverless v1](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV1.md).
## Vorteile von Aurora Serverless v1
Aurora Serverless v1 bietet folgende Vorteile:
+ **Einfacher als bereitgestellt** – Aurora Serverless v1 eliminiert einen Großteil der Komplexität bei der Verwaltung von DB-Instances und -Kapazität.
+ **Skalierbar** – Aurora Serverless v1 skaliert Rechen- und Speicherkapazität nahtlos nach Bedarf, ohne dass die Client-Verbindungen gestört werden.
+ **Kosteneffektiv** – Wenn Sie Aurora Serverless v1 verwenden, zahlen Sie nur für die Datenbankressourcen, die Sie verbrauchen – auf Sekundenbasis.
+ **Hochverfügbarer Speicher** – Aurora Serverless v1 verwendet dasselbe fehlertolerante verteilte Speichersystem mit sechsfacher Replikation wie Aurora, um vor Datenverlust zu schützen.
## Anwendungsfälle für Aurora Serverless v1
Aurora Serverless v1 ist auf die folgenden Anwendungsfälle ausgelegt:
+ **Selten verwendete Anwendungen** – Sie haben eine Anwendung, die mehrmals pro Tag oder Woche nur für ein paar Minuten verwendet wird, wie beispielsweise eine Blog-Website mit geringem Volumen. Mit Aurora Serverless v1 zahlen Sie nur für die Datenbankressourcen, die Sie verbrauchen – auf Sekundenbasis.
+ **Neue Anwendungen** – Sie stellen eine neue Anwendung bereit und sind sich nicht sicher, welche Instance-Größe Sie benötigen. Mit Aurora Serverless v1 können Sie einen Datenbankendpunkt erstellen und es der Datenbank überlassen, automatisch gemäß den Kapazitätsanforderungen Ihrer Anwendung zu skalieren.
+ **Variable Workloads** – Sie führen eine nur wenig benutzte Anwendung aus, mit Spitzen von 30 Minuten bis zu mehreren Stunden ein paarmal pro Tag oder mehrere Male pro Jahr. Beispiele sind Anwendungen für die Personalabteilung oder für die Erstellung von Budgets oder Betriebsberichten. Mit Aurora Serverless v1 müssen Sie nicht mehr Spitzen- oder durchschnittliche Kapazitäten bereitstellen.
+ **Unvorhersehbare Workloads** – Sie führen tägliche Workloads mit plötzlichen und unvorhersehbaren Aktivitätszuwächsen aus. Ein Beispiel dafür ist eine Verkehrs-Website, für die Aktivitätsspitzen entstehen, wenn es zu regnen beginnt. Mit Aurora Serverless v1 wird Ihre Datenbank automatisch auf die Kapazität skaliert, mit der die Spitzenlast Ihrer Anwendung erfüllt werden kann, und wieder herunterskaliert, wenn die Aktivitätsspitze vorbei ist.
+ **Entwicklungs- und Testdatenbanken** – Ihre Entwickler verwenden Datenbanken während der Arbeitszeit, benötigen sie jedoch nachts oder am Wochenende nicht. Mit Aurora Serverless v1 wird Ihre Datenbank automatisch heruntergefahren, wenn sie nicht verwendet wird.
+ **Anwendungen für mehrere Mandanten** – Mit Aurora Serverless v1 müssen Sie die Datenbankkapazität nicht für jede Anwendung in Ihrer Flotte einzeln verwalten. Aurora Serverless v1 verwaltet die individuelle Datenbankkapazität für Sie.
## Einschränkungen von Aurora Serverless v1
Die folgenden Einschränkungen gelten für Aurora Serverless v1:
+
**Wichtig**
AWS hat [den end-of-life Termin bekannt gegeben fürAurora Serverless v1: 31. März](https://repost.aws/questions/QUhcMVoChXRm2HLi8F-yih1g/announcement-support-for-aurora-s/announcement-support-for-aurora-serverless-v1-ending-soon) 2025. Alle Aurora Serverless v1-Cluster, die bis zum 31. März 2025 nicht migriert wurden, werden während des Wartungsfensters zu Aurora Serverless v2 migriert. Wenn das Upgrade fehlschlägt, konvertiert Amazon Aurora den Serverless-v1-Cluster während des Wartungsfensters in einen bereitgestellten Cluster mit der entsprechenden Engine-Version. Falls zutreffend, registriert Amazon Aurora den konvertierten bereitgestellten Cluster bei Amazon RDS Extended Support. Weitere Informationen finden Sie unter [Amazon RDS Extended Support mit Amazon Aurora](extended-support.md).
+ Aurora Serverless v1 unterstützt die folgenden -Funktionen nicht:
+ Globale Aurora-Datenbanken
+ Aurora-Replikate
+ AWS Identity and Access Management (IAM) Datenbankauthentifizierung
+ Rückverfolgung in Aurora
+ Datenbankaktivitätsstreams
+ Kerberos-Authentifizierung
+ Performance Insights
+ RDS-Proxy
+ Logs anzeigen im AWS-Managementkonsole
+ Verbindungen zu einem Aurora Serverless v1-DB-Cluster werden automatisch geschlossen, wenn sie länger als einen Tag offen gehalten werden.
+ Alle Aurora Serverless v1-DB-Cluster haben die folgenden Einschränkungen:
+ Sie können keine Aurora Serverless v1-Snapshots in Amazon-S3-Buckets exportieren.
+ Sie können Data Capture (CDC) nicht mit Aurora Serverless v1 DB-Clustern verwenden AWS Database Migration Service und ändern. Nur bereitgestellte Aurora-DB-Cluster unterstützen CDC AWS DMS als Quelle.
+ Sie können Daten nicht als Textdateien in Amazon S3 speichern oder Daten aus Textdateien aus S3 in Aurora Serverless v1 laden.
+ Sie können eine IAM-Rolle nicht einem Aurora Serverless v1-DB-Cluster anfügen. Sie können jedoch Daten aus Amazon S3 in Aurora Serverless v1 laden, indem Sie die `aws_s3`-Erweiterung mit der Funktion `aws_s3.table_import_from_s3` und dem Parameter `credentials` verwenden. Weitere Informationen finden Sie unter [Importieren von Amazon S3 in einen Aurora-PostgreSQL-DB-Cluster](USER_PostgreSQL.S3Import.md).
+ Wenn Sie den Query Editor verwenden, wird ein Secrets-Manager-Secret für die DB-Anmeldeinformationen für den Zugriff auf die Datenbank erstellt. Wenn Sie die Anmeldeinformationen aus dem Query Editor löschen, wird das zugehörige Secret auch aus Secrets Manager gelöscht. Sie können dieses Secret nach dem Löschen nicht wiederherstellen.
+ Aurora-MySQL-basierte DB-Cluster, auf denen Aurora Serverless v1 ausgeführt wird, unterstützen Folgendes nicht:
+ Aufrufen von AWS Lambda Funktionen innerhalb Ihres Aurora MySQL-DB-Clusters. AWS Lambda Funktionen können jedoch Aufrufe an Ihren Aurora Serverless v1 DB-Cluster senden.
+ Wiederherstellen eines Snapshots aus einer DB-Instance, die nicht Aurora MySQL oder RDS für MySQL ist
+ Replizieren von Daten mit auf binären Protokollen basierender Replikation. Diese Einschränkung gilt unabhängig davon, ob Ihr Aurora-MySQL-basierter DB-Cluster Aurora Serverless v1 die Quelle oder das Ziel der Replikation ist. Um Daten aus einer MySQL-DB-Instance außerhalb von Aurora, z. B. aus einer in Amazon EC2 ausgeführten Instance, in einen Aurora Serverless v1-DB-Cluster zu replizieren, sollten Sie die Verwendung von AWS Database Migration Service erwägen. Weitere Informationen finden Sie im [AWS Database Migration Service -Benutzerhandbuch](https://docs.aws.amazon.com/dms/latest/userguide/).
+ Erstellen von Benutzern mit hostbasiertem Zugriff (`'username'@'IP_address'`). Das liegt daran, dass Aurora Serverless v1 eine Router-Flotte zwischen dem Client und dem Datenbankhost für eine nahtlose Skalierung verwendet. Die IP-Adresse, die der Aurora Serverless-DB-Cluster sieht, ist die des Router-Hosts und nicht die Ihres Clients. Weitere Informationen finden Sie unter [Aurora Serverless v1-Architektur](aurora-serverless-v1.how-it-works.md#aurora-serverless.architecture).
Verwenden Sie stattdessen den Platzhalter (`'username'@'%'`).
+ Aurora-PostgreSQL-basierte DB-Cluster, auf denen Aurora Serverless v1 ausgeführt wird, haben die folgenden Einschränkungen:
+ Aurora-PostgreSQL-Abfrageplan-Verwaltung (`apg_plan_management`-Erweiterung) wird nicht unterstützt.
+ Die in Amazon RDS PostgreSQL und Aurora PostgreSQL verfügbare logische Replikationsfunktion wird nicht unterstützt.
+ Ausgehende Kommunikation, z. B. Kommunikation, die von Amazon RDS für PostgreSQL-Erweiterungen ermöglicht wird, wird nicht unterstützt. Beispielsweise können Sie mit der Erweiterung `postgres_fdw/dblink` nicht auf externe Daten zugreifen. Weitere Informationen zu RDS PostgreSQL-Erweiterungen finden Sie unter [PostgreSQL in Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html#PostgreSQL.Concepts.General.FeatureSupport.Extensions.101x) im *RDS-Benutzerhandbuch*.
+ Derzeit werden bestimmte SQL-Abfragen und -Befehle nicht empfohlen. Dazu gehören empfohlene Sperren auf Sitzungsebene, temporäre Beziehungen, asynchrone Benachrichtigungen (`LISTEN`) und Cursors with Hold (`DECLARE name ... CURSOR WITH HOLD FOR query`). `NOTIFY`-Befehle verhindern außerdem eine Skalierung und werden nicht empfohlen.
Weitere Informationen finden Sie unter [Automatische Skalierung für Aurora Serverless v1](aurora-serverless-v1.how-it-works.md#aurora-serverless.how-it-works.auto-scaling).
+ Sie können das bevorzugte automatisierte Backup-Fenster für einen Aurora Serverless v1-DB-Cluster nicht festlegen.
+ Sie können das Wartungsfenster für einen DB-Cluster von Aurora Serverless v1 einstellen. Weitere Informationen finden Sie unter [Anpassen des bevorzugten DB-Cluster-Wartungsfensters](USER_UpgradeDBInstance.Maintenance.md#AdjustingTheMaintenanceWindow.Aurora).
## Anforderungen an die Konfiguration von Aurora Serverless v1
Beachten Sie beim Erstellen eines Aurora Serverless v1-DB-Clusters die folgenden Anforderungen:
+ Verwenden Sie diese spezifischen Portnummern für jede DB-Engine:
+ Aurora MySQL – `3306`
+ Aurora PostgreSQL – `5432`
+ Erstellen Sie Ihr Aurora Serverless v1-DB-Cluster in einer Virtual Private Cloud (VPC), basierend auf dem Amazon-VPC-Service. Wenn Sie einen Aurora Serverless v1-DB-Cluster in Ihrer VPC erstellen, verbrauchen Sie zwei (2) der fünfzig (50) Interface- und Gateway Load Balancer-Endpunkte, die Ihrer VPC zugewiesen sind. Diese Endpunkte werden automatisch für Sie erstellt. Um Ihr Kontingent zu erhöhen, können Sie Kontakt aufnehmen Support. Weitere Informationen finden Sie unter [Amazon VPC-Kontingente](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html#vpc-limits-endpoints).
+ Sie können einem Aurora Serverless v1-DB-Cluster keine öffentliche IP-Adresse geben. Sie können nur von einer VPC aus auf einen Aurora Serverless v1-DB-Cluster zugreifen.
+ Erstellen Sie Subnetze in verschiedenen Availability Zones für die DB-Subnetzgruppe, die Sie für Ihren Aurora Serverless v1-DB-Cluster verwenden. Anders ausgedrückt: In einer Availability Zone kann sich nur ein Subnetz befinden.
+ Änderungen an einer Subnetzgruppe, die von einem Aurora Serverless v1-DB-Cluster verwendet wird, werden nicht auf den Cluster angewendet.
+ Sie können von aus auf einen Aurora Serverless v1 DB-Cluster zugreifen AWS Lambda. Hierfür müssen Sie Ihre Lambda-Funktion so konfigurieren, dass sie in derselben VPC ausgeführt wird wie Ihr Aurora Serverless v1-DB-Cluster. Weitere Informationen zur Arbeit mit AWS Lambda finden Sie unter [Konfiguration einer Lambda-Funktion für den Zugriff auf Ressourcen in einer Amazon VPC](https://docs.aws.amazon.com/lambda/latest/dg/vpc.html) im *AWS Lambda Entwicklerhandbuch*.
## Verwenden mit TLS/SSL Aurora Serverless v1
Aurora Serverless v1Verwendet standardmäßig das TLS/SSL-Protokoll (Transport Layer Security/Secure Sockets Layer), um die Kommunikation zwischen Clients und Ihrem Aurora Serverless v1 DB-Cluster zu verschlüsseln. Es unterstützt die TLS/SSL Versionen 1.0, 1.1 und 1.2. Sie müssen Ihren Aurora Serverless v1-DB-Cluster nicht für die Verwendung von TLS/SSL konfigurieren.
Es gelten jedoch die folgenden Einschränkungen:
+ TLS/SSL Unterstützung für Aurora Serverless v1 DB-Cluster ist derzeit in China (Peking) nicht verfügbar AWS-Region.
+ Wenn Sie Datenbankbenutzer für einen Aurora-MySQL-basierten Aurora Serverless v1-DB-Cluster erstellen, verwenden Sie nicht die `REQUIRE`-Klausel für SSL-Berechtigungen. Diese verhindert, dass Benutzer eine Verbindung mit der Aurora-DB-Instance herstellen können.
+ Sowohl für MySQL Client- als auch für PostgreSQL Client-Dienstprogramme haben Sitzungsvariablen, die Sie möglicherweise in anderen Umgebungen verwenden, keine Auswirkung, wenn Sie TLS/SSL zwischen Client und verwenden. Aurora Serverless v1
+ Beim MySQL-Client müssen Sie beim Verbinden mit dem `VERIFY_IDENTITY`-Modus von TLS/SSL derzeit den MySQL 8.0-kompatiblen `mysql`-Befehl verwenden. Weitere Informationen finden Sie unter [Verbinden mit einer DB-Instance, auf der die MySQL-Datenbank-Engine ausgeführt wird](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ConnectToInstance.html).
Je nach Client, den Sie für die Verbindung mit dem Aurora Serverless v1 DB-Cluster verwenden, müssen Sie möglicherweise nicht angeben, ob eine verschlüsselte Verbindung hergestellt werden TLS/SSL soll. Um beispielsweise den PostgreSQL-Client zum Verbinden mit einem Aurora Serverless v1-DB-Cluster zu verwenden, auf dem die Aurora-PostgreSQL-kompatible Edition ausgeführt wird, verbinden Sie sich wie gewohnt.
```
psql -h endpoint -U user
```
Nachdem Sie Ihr Passwort eingegeben haben, zeigt Ihnen der PostgreSQL-Client die Verbindungsdetails, einschließlich TLS/SSL Version und Chiffre.
```
psql (12.5 (Ubuntu 12.5-0ubuntu0.20.04.1), server 10.12)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.
```
**Wichtig**
Aurora Serverless v1verwendet die Transport Layer Security/Secure Sockets Layer (TLS/SSL) protocol to encrypt connections by default unless SSL/TLS is disabled by the client application. The TLS/SSLVerbindung endet bei der Routerflotte). Die Kommunikation zwischen der Router-Flotte und Ihrem Aurora Serverless v1-DB-Cluster erfolgt innerhalb der internen Netzwerkgrenze des Services.
Sie können den Status der Client-Verbindung überprüfen, um zu überprüfen, ob die Verbindung zu TLS/SSL verschlüsselt Aurora Serverless v1 ist. Das PostgreSQL `pg_stat_ssl` und die `pg_stat_activity` Tabellen und ihre `ssl_is_used` Funktion zeigen nicht den TLS/SSL Status für die Kommunikation zwischen der Client-Anwendung und. Aurora Serverless v1 Ebenso kann der TLS/SSL Status nicht aus der `status` MySQL-Anweisung abgeleitet werden.
Die Aurora-Clusterparameter `force_ssl` für PostgreSQL und `require_secure_transport` für MySQL wurden für Aurora Serverless v1 früher nicht unterstützt. Diese Parameter sind jetzt für Aurora Serverless v1 verfügbar. Rufen Sie den [DescribeEngineDefaultClusterParameters](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeEngineDefaultClusterParameters.html)API-Vorgang auf, um eine vollständige Liste der von Aurora Serverless v1 unterstützten Parameter zu erhalten. Weitere Informationen zu Parametergruppen und Aurora Serverless v1 finden Sie unter [Parametergruppen für Aurora Serverless v1](aurora-serverless-v1.how-it-works.md#aurora-serverless.parameter-groups).
Um den MySQL-Client zu verwenden, um eine Verbindung zu einem Aurora Serverless v1 DB-Cluster herzustellen, auf dem Aurora MySQL-Compatible Edition ausgeführt wird, geben Sie TLS/SSL in Ihrer Anfrage an. Das folgende Beispiel umfasst den [Amazon Root CA 1 Trust Store](https://www.amazontrust.com/repository/AmazonRootCA1.pem), der von Amazon Trust Services heruntergeladen wurde und für diese Verbindung erforderlich ist.
```
mysql -h endpoint -P 3306 -u user -p --ssl-ca=amazon-root-CA-1.pem --ssl-mode=REQUIRED
```
Geben Sie bei der Aufforderung Ihr Passwort ein. Kurz darauf öffnet sich der MySQL-Monitor. Sie können sich mit dem `status`-Befehl vergewissern, dass die Sitzung verschlüsselt ist.
```
mysql> status
--------------
mysql Ver 14.14 Distrib 5.5.62, for Linux (x86_64) using readline 5.1
Connection id: 19
Current database:
Current user: ***@*******
SSL: Cipher in use is ECDHE-RSA-AES256-SHA
...
```
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](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ConnectToInstance.html).
Aurora Serverless v1unterstützt alle TLS/SSL Modi, die für den MySQL-Client (`mysql`) und den PostgreSQL-Client (`psql`) verfügbar sind, einschließlich der in der folgenden Tabelle aufgeführten.
| Beschreibung des Modus TLS/SSL | mysql- | psql |
| --- | --- | --- |
| Verbinden ohne Verwendung von TLS/SSL | DISABLED | disable |
| Versuchen Sie TLS/SSL zunächst, die Verbindung über SSL herzustellen, greifen Sie aber gegebenenfalls auf eine Verbindung ohne SSL zurück. | PREFERRED | bevorzugen (Standard) |
| Verwendung von TLS/SSL erzwingen | REQUIRED | require |
| Erzwingen TLS/SSL und verifizieren Sie die CA. | VERIFY\$1CA | verify-ca |
| TLS/SSL erzwingen, CA überprüfen und CA-Hostnamen überprüfen | VERIFY\$1IDENTITY | verify-full |
Aurora Serverless v1 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](https://www.amazontrust.com/repository/AmazonRootCA1.pem) von Amazon Trust Services herunter. Danach können Sie diese PEM-formatierte Datei in Ihrem Client-Befehl identifizieren. Beim PostgreSQL-Client gehen Sie so vor:
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](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ConnectToPostgreSQLInstance.html).
Weitere Informationen zum Verbinden mit Aurora-DB-Clustern im Allgemeinen finden Sie unter [Herstellen einer Verbindung mit einem Amazon Aurora-DB-Cluster](Aurora.Connecting.md).
### Unterstützte Verschlüsselungssammlungen für Verbindungen mit Aurora Serverless v1-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/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 v1-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](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL.ConfiguringCipherSuites).
Aurora Serverless v1-DB-Cluster, die auf Aurora PostgreSQL basieren, unterstützen keine Chiffrier-Suiten.
# Funktionsweise von Aurora Serverless v1
**Wichtig**
AWS hat [den end-of-life Termin bekannt gegeben fürAurora Serverless v1: 31. März 2025](https://repost.aws/questions/QUhcMVoChXRm2HLi8F-yih1g/announcement-support-for-aurora-s/announcement-support-for-aurora-serverless-v1-ending-soon). Alle Aurora Serverless v1-Cluster, die bis zum 31. März 2025 nicht migriert wurden, werden während des Wartungsfensters zu Aurora Serverless v2 migriert. Wenn das Upgrade fehlschlägt, konvertiert Amazon Aurora den Serverless-v1-Cluster während des Wartungsfensters in einen bereitgestellten Cluster mit der entsprechenden Engine-Version. Falls zutreffend, registriert Amazon Aurora den konvertierten bereitgestellten Cluster bei Amazon RDS Extended Support. Weitere Informationen finden Sie unter [Amazon RDS Extended Support mit Amazon Aurora](extended-support.md).
Im Folgenden erfahren Sie, wie Aurora Serverless v1 funktioniert.
**Topics**
+ [Aurora Serverless v1-Architektur](#aurora-serverless.architecture)
+ [Automatische Skalierung für Aurora Serverless v1](#aurora-serverless.how-it-works.auto-scaling)
+ [Timeout-Aktion für Kapazitätsänderungen](#aurora-serverless.how-it-works.timeout-action)
+ [Pausieren und Fortsetzen für Aurora Serverless v1](#aurora-serverless.how-it-works.pause-resume)
+ [Bestimmen der maximalen Anzahl von Datenbankverbindungen für Aurora Serverless v1](#aurora-serverless.max-connections)
+ [Parametergruppen für Aurora Serverless v1](#aurora-serverless.parameter-groups)
+ [Protokollierung für Aurora Serverless v1](#aurora-serverless.logging)
+ [Aurora Serverless v1 und Wartung](#aurora-serverless.maintenance)
+ [Aurora Serverless v1 und Failover](#aurora-serverless.failover)
+ [Aurora Serverless v1 und Snapshots](#aurora-serverless.snapshots)
## Aurora Serverless v1-Architektur
Die folgende Abbildung zeigt einen Überblick über die Aurora Serverless v1-Architektur.
![\[Aurora Serverless v1-Architektur\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-serverless-arch.png)
Anstatt Datenbankserver bereitzustellen und zu verwalten, geben Sie Aurora-Kapazitätseinheiten (ACUs) an. Jede ACU ist eine Kombination aus etwa 2 Gigabyte (GB) Arbeitsspeicher, entsprechender CPU und Netzwerkleistung. Der Datenbankspeicher wird automatisch von 10 Gibibyte (GiB) auf 128 tebibytes (TiB) skaliert, genau wie Speicher in einem standardmäßigen Aurora-DB-Cluster.
Sie können die minimale und maximale ACU angeben. Die *Mindestkapazitätseinheit von Aurora* ist die kleinste ACU, auf die das DB-Cluster herabskaliert werden kann. Die *maximale Kapazitätseinheit von Aurora* ist die größte ACU, auf die das DB-Cluster hinaufskaliert werden kann. Basierend auf Ihren Einstellungen erstellt Aurora Serverless v1 automatisch Skalierungsregeln in Bezug auf Schwellenwerte für CPU-Auslastung, Verbindungen und verfügbaren Arbeitsspeicher.
Aurora Serverless v1verwaltet den warmen Ressourcenpool, um die Skalierungszeit AWS-Region zu minimieren. Wenn Aurora Serverless v1 dem Aurora-DB-Cluster neue Ressourcen hinzufügt, verwendet es die Routerflotte, um aktive Client-Verbindungen auf die neuen Ressourcen umzustellen. Zu einem bestimmten Zeitpunkt werden Ihnen nur diejenigen in Rechnung gestellt ACUs , die aktiv in Ihrem Aurora-DB-Cluster verwendet werden.
## Automatische Skalierung für Aurora Serverless v1
Die Ihrem Aurora Serverless v1-DB-Cluster zugewiesene Kapazität wird basierend auf der von Ihrer Client-Anwendung generierten Last nahtlos auf- und abwärts skaliert. Hier ist die Last die CPU-Auslastung und die Anzahl der Verbindungen. Wenn die Kapazität durch eine dieser beiden Faktoren eingeschränkt wird, wird Aurora Serverless v1 skaliert. Aurora Serverless v1 skaliert auch, wenn Leistungsprobleme erkannt werden, die dadurch gelöst werden können.
Sie können Skalierungsereignisse für Ihren Aurora Serverless v1 Cluster im einsehen AWS-Managementkonsole. Während der automatischen Skalierung setzt Aurora Serverless v1 die `EngineUptime`-Metrik zurück. Der Wert des zurückgesetzten Metrikwertes bedeutet weder, dass die nahtlose Skalierung Probleme hatte, noch, dass Aurora Serverless v1 Verbindungen unterbrochen hat. Er ist einfach der Ausgangspunkt für die Betriebszeit bei der neuen Kapazität. Weitere Informationen über Metriken finden Sie unter [Überwachung von Metriken in einem Amazon-Aurora-Cluster](MonitoringAurora.md).
Wenn Ihr Aurora Serverless v1 DB-Cluster keine aktiven Verbindungen hat, kann er auf eine Kapazität von Null herunterskaliert werden (0 ACUs). Weitere Informationen hierzu finden Sie unter [Pausieren und Fortsetzen für Aurora Serverless v1](#aurora-serverless.how-it-works.pause-resume).
Wenn er einen Skalierungsvorgang durchführen muss, versucht Aurora Serverless v1 zuerst einen *Skalierungspunkt* zu identifizieren, ein Moment, in dem keine Anfragen bearbeitet werden. Aurora Serverless v1 kann aus folgenden Gründen möglicherweise keinen Skalierungspunkt finden:
+ Lang laufende Anfragen
+ Transaktionen in Bearbeitung
+ Temporäre Tabellen oder Tabellensperren
Um die Erfolgsrate Ihres Aurora Serverless v1-DB-Clusters bei der Suche nach einem Skalierungspunkt zu erhöhen, empfehlen wir, lang andauernde Abfragen und lang andauernde Transaktionen zu vermeiden. Weitere Informationen zu Operationen zum Blockieren von Skalierungen und wie Sie diese vermeiden können, finden Sie unter [Bewährte Methoden für die Arbeit mit Aurora Serverless v1](https://aws.amazon.com/blogs/database/best-practices-for-working-with-amazon-aurora-serverless/).
Standardmäßig versucht Aurora Serverless v1, einen Skalierungspunkt für 5 Minuten (300 Sekunden) zu finden. Sie können bei der Erstellung oder Änderung des Clusters eine andere Zeitspanne festlegen. Die Timeout-Zeit kann zwischen 60 Sekunden und 10 Minuten (600 Sekunden) liegen. Wenn Aurora Serverless v1 innerhalb des angegebenen Zeitraums keinen Skalierungspunkt finden kann, wird der Autoskalierungsvorgang abgebrochen.
Standardmäßig, wenn automatischen Skalierung vor dem Timeout keinen Skalierungspunkt findet, hält Aurora Serverless v1 den Cluster auf der aktuellen Kapazität. Sie können dieses Standardverhalten bei der Erstellung oder Änderung Ihres Aurora Serverless v1 DB-Clusters ändern, indem Sie die Option **Kapazitätsänderung erzwingen** auswählen. Weitere Informationen finden Sie unter [Timeout-Aktion für Kapazitätsänderungen](#aurora-serverless.how-it-works.timeout-action).
## Timeout-Aktion für Kapazitätsänderungen
Wenn die automatische Skalierung abbricht, ohne einen Skalierungspunkt zu finden, behält Aurora standardmäßig die aktuelle Kapazität bei. Sie können festlegen, dass Aurora die Änderung erzwingt, indem Sie die Option **Force the capacity change** (Kapazitätsänderung erzwingen) aktivieren. Diese Option ist im Abschnitt **Autoscaling timeout and action** (Autoscaling-Timeout und -Aktion) auf der Seite **Create database** (Datenbank erstellen) verfügbar, wenn Sie den Cluster erstellen.
Standardmäßig ist die Option **Force the capacity change** (Kapazitätsänderung erzwingen) deaktiviert. Lassen Sie diese Option deaktiviert, damit die Kapazität Ihres Aurora Serverless v1-DB-Clusters unverändert bleibt, wenn der Skalierungsvorgang ausläuft, ohne einen Skalierungspunkt zu finden.
Wenn Sie diese Option aktivieren, erwzingt Ihr Aurora Serverless v1-DB-Cluster die Kapazitätsänderung auch ohne Skalierungspunkt. Bevor Sie diese Option auswählen, sollten Sie sich der Konsequenzen dieser Auswahl bewusst sein:
+ Alle In-Process-Transaktionen werden unterbrochen, und die folgende Fehlermeldung wird angezeigt.
Aurora MySQL Version 2 — FEHLER 1105 (HY000): Die letzte Transaktion wurde aufgrund von Seamless Scaling abgebrochen. Bitte versuchen Sie es erneut.
Sie können die Transaktion erneut übermitteln, sobald Ihr Aurora Serverless v1-DB-Cluster verfügbar ist.
+ Verbindungen zu temporären Tabellen und Sperren werden gelöscht.
Wir empfehlen, dass Sie die Option **Force the capacity change** (Kapazitätsänderung erzwingen) nur dann auswählen, wenn Ihre Anwendung nach unterbrochenen Verbindungen oder unvollständigen Transaktionen wiederhergestellt werden kann.
Die Entscheidungen, die Sie AWS-Managementkonsole bei der Erstellung eines Aurora Serverless v1 DB-Clusters treffen, werden im `ScalingConfigurationInfo` Objekt, in den Eigenschaften `SecondsBeforeTimeout` und `TimeoutAction` gespeichert. Der Wert der `TimeoutAction`-Eigenschaft wird bei der Erstellung Ihres Clusters auf einen der folgenden Werte festgelegt:
+ `RollbackCapacityChange` – Dieser Wert wird festgelegt, wenn Sie die Option **Roll back the capacity change** (Rückgängig machen der Kapazitätsänderung) auswählen. Dies ist das Standardverhalten.
+ `ForceApplyCapacityChange` – Dieser Wert wird festgelegt, wenn Sie die Option **Force the capacity change** (Force the capacity change) auswählen.
Sie können den Wert dieser Eigenschaft in einem vorhandenen Aurora Serverless v1 DB-Cluster mithilfe des folgenden [describe-db-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html) AWS CLI Befehls abrufen.
Für Linux, macOS oder Unix:
```
aws rds describe-db-clusters --region region \
--db-cluster-identifier your-cluster-name \
--query '*[].{ScalingConfigurationInfo:ScalingConfigurationInfo}'
```
Für Windows:
```
aws rds describe-db-clusters --region region ^
--db-cluster-identifier your-cluster-name ^
--query "*[].{ScalingConfigurationInfo:ScalingConfigurationInfo}"
```
Das folgende Beispiel zeigt die Abfrage und die Antwort für einen Aurora Serverless v1 DB-Cluster mit der Bezeichnung `west-coast-sles` in der Region US-West (Nordkalifornien).
```
$ aws rds describe-db-clusters --region us-west-1 --db-cluster-identifier west-coast-sles
--query '*[].{ScalingConfigurationInfo:ScalingConfigurationInfo}'
[
{
"ScalingConfigurationInfo": {
"MinCapacity": 1,
"MaxCapacity": 64,
"AutoPause": false,
"SecondsBeforeTimeout": 300,
"SecondsUntilAutoPause": 300,
"TimeoutAction": "RollbackCapacityChange"
}
}
]
```
Wie die Antwort zeigt, verwendet dieser Aurora Serverless v1-DB-Cluster die Standardeinstellung.
Weitere Informationen finden Sie unter [Erstellen eines Aurora Serverless v1-DB Clusters](aurora-serverless.create.md). Nach Erstellung Ihres Aurora Serverless v1, können Sie die Timeout-Aktion und andere Kapazitätseinstellungen jederzeit ändern. Um zu erfahren wie, siehe [Ändern eines Aurora Serverless v1-DB-Clusters](aurora-serverless.modifying.md).
## Pausieren und Fortsetzen für Aurora Serverless v1
Sie können festlegen, Ihren Aurora Serverless v1-DB-Cluster nach einer bestimmten Zeit ohne Aktivität zu pausieren. Sie geben die Zeitspanne ohne Aktivität an, bevor der DB-Cluster angehalten wird. Wenn Sie diese Option auswählen, beträgt die standardmäßige Inaktivitätszeit fünf Minuten. Sie können diesen Wert jedoch ändern. Dies ist eine optionale Einstellung.
Wenn der DB-Cluster pausiert wird, findet keine Rechen- oder Speicheraktivität statt, und es wird Ihnen nur die Speicherung in Rechnung gestellt. Wenn beim Anhalten eines Aurora Serverless v1 DB-Clusters Datenbankverbindungen angefordert werden, nimmt der DB-Cluster die Verbindungsanforderungen automatisch wieder auf und bedient sie.
Wenn der DB-Cluster die Aktivität fortsetzt, hat er die gleiche Kapazität wie beim Anhalten des Clusters durch Aurora. Die Anzahl ACUs hängt davon ab, wie stark Aurora den Cluster nach oben oder unten skaliert hat, bevor er angehalten wurde.
**Anmerkung**
Wenn ein DB-Cluster für mehr als sieben Tage pausiert wird, könnte der DB-Cluster mit einem Snapshot gesichert werden. In diesem Fall stellt Aurora den DB-Cluster aus dem Snapshot wieder her, wenn eine Verbindungsanforderung vorliegt.
## Bestimmen der maximalen Anzahl von Datenbankverbindungen für Aurora Serverless v1
Im Folgenden sind einige Beispiele für einen DB-Cluster von Aurora Serverless v1 aufgeführt, der mit MySQL 5.7 kompatibel ist. Sie können einen MySQL-Client oder den Abfrage-Editor verwenden, wenn Sie den Zugriff darauf konfiguriert haben. Weitere Informationen finden Sie unter [Ausführen von Abfragen im Abfrage-Editor](query-editor.md#query-editor.running).
**So ermitteln Sie die maximale Anzahl von Datenbankverbindungen**
1. Ermitteln Sie den Kapazitätsbereich für Ihren DB-Cluster von Aurora Serverless v1 mithilfe der AWS CLI.
```
aws rds describe-db-clusters \
--db-cluster-identifier my-serverless-57-cluster \
--query 'DBClusters[*].ScalingConfigurationInfo|[0]'
```
Das Ergebnis zeigt, dass sein Kapazitätsbereich 1—4 beträgt. ACUs
```
{
"MinCapacity": 1,
"AutoPause": true,
"MaxCapacity": 4,
"TimeoutAction": "RollbackCapacityChange",
"SecondsUntilAutoPause": 3600
}
```
1. Führen Sie die folgende SQL-Abfrage aus, um die maximale Anzahl von Verbindungen zu ermitteln.
```
select @@max_connections;
```
Das angezeigte Ergebnis gilt für die Mindestkapazität des Clusters, 1 ACU.
```
@@max_connections
90
```
1. Skalieren Sie den Cluster auf ACUs 8—32.
Weitere Informationen zur Skalierung finden Sie unter [Ändern eines Aurora Serverless v1-DB-Clusters](aurora-serverless.modifying.md).
1. Bestätigen Sie den Kapazitätsbereich.
```
{
"MinCapacity": 8,
"AutoPause": true,
"MaxCapacity": 32,
"TimeoutAction": "RollbackCapacityChange",
"SecondsUntilAutoPause": 3600
}
```
1. Suchen Sie die maximale Anzahl von Verbindungen.
```
select @@max_connections;
```
Das angezeigte Ergebnis bezieht sich auf die Mindestkapazität des Clusters, 8. ACUs
```
@@max_connections
1000
```
1. Skalieren Sie den Cluster auf den maximal möglichen Wert (256—256) ACUs.
1. Bestätigen Sie den Kapazitätsbereich.
```
{
"MinCapacity": 256,
"AutoPause": true,
"MaxCapacity": 256,
"TimeoutAction": "RollbackCapacityChange",
"SecondsUntilAutoPause": 3600
}
```
1. Suchen Sie die maximale Anzahl von Verbindungen.
```
select @@max_connections;
```
Das angezeigte Ergebnis bezieht sich auf 256. ACUs
```
@@max_connections
6000
```
**Anmerkung**
Der `max_connections` Wert skaliert nicht linear mit der Anzahl von ACUs.
1. Skalieren Sie den Cluster wieder auf ACUs 1—4 herunter.
```
{
"MinCapacity": 1,
"AutoPause": true,
"MaxCapacity": 4,
"TimeoutAction": "RollbackCapacityChange",
"SecondsUntilAutoPause": 3600
}
```
Diesmal ist der `max_connections` Wert für 4. ACUs
```
@@max_connections
270
```
1. Lassen Sie den Cluster auf 2 herunterskalieren ACUs.
```
@@max_connections
180
```
Wenn Sie den Cluster so konfiguriert haben, dass er nach einer bestimmten Zeit im Leerlauf angehalten wird, wird er auf 0 herunterskaliert ACUs. Allerdings fällt `max_connections` nicht unter den Wert für 1 ACU.
```
@@max_connections
90
```
## Parametergruppen für Aurora Serverless v1
Wenn Sie Ihren Aurora Serverless v1-DB-Cluster erstellen, wählen Sie eine bestimmte Aurora-DB-Engine und eine zugehörige DB-Cluster-Parametergruppe. Im Gegensatz zu bereitgestellten Aurora-DB-Clustern verfügt ein Aurora Serverless v1 DB-Cluster über eine einzige read/write DB-Instance, die nur mit einer DB-Cluster-Parametergruppe konfiguriert ist — sie hat keine separate DB-Parametergruppe. Während der automatischen Skalierung, muss Aurora Serverless v1 in der Lage sein, Parameter zu ändern, damit der Cluster optimal für die erhöhte oder verringerte Kapazität funktioniert. Das heißt, dass bei einem Aurora Serverless v1-DB-Cluster, einige der Änderungen, die Sie an Parametern für einen bestimmten DB-Engine-Typ vornehmen, möglicherweise nicht gelten.
Zum Beispiel kann ein Aurora-PostgreSQL–basierter Aurora Serverless v1-DB-Cluster `apg_plan_mgmt.capture_plan_baselines` und andere Parameter nicht verwenden, die auf bereitgestellten Aurora PostgreSQL-DB-Clustern für die Verwaltung von Abfrageplänen verwendet werden könnten.
Sie können eine Liste der Standardwerte für die Standardparametergruppen für die verschiedenen Aurora-DB-Engines abrufen, indem Sie den CLI-Befehl [describe-engine-default-cluster-parameters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-engine-default-cluster-parameters.html) verwenden und die abfragen. AWS-Region Die folgenden Werte können Sie für die `--db-parameter-group-family`-Option verwenden.
| | |
| --- |--- |
| Aurora-MySQL-Version 2 | `aurora-mysql5.7` |
| Aurora-PostgreSQL-Version 11 | `aurora-postgresql11` |
| Aurora PostgreSQL Version 13 | `aurora-postgresql13` |
Wir empfehlen, dass Sie Ihre AWS CLI mit Ihrer AWS Zugriffsschlüssel-ID und Ihrem AWS geheimen Zugriffsschlüssel konfigurieren und dass Sie Ihre Befehle AWS-Region vor der Verwendung AWS CLI festlegen. Wenn Sie die Region Ihrer CLI-Konfiguration angeben, müssen Sie die `--region`-Parameter beim Ausführen von Befehlen nicht eingeben. Weitere Informationen zur [Konfiguration AWS CLI finden Sie im *AWS Command Line Interface Benutzerhandbuch* unter Grundlagen](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) der Konfiguration.
Im folgenden Beispiel wird eine Liste von Parametern aus der Standard-DB-Cluster-Gruppe für Aurora-MySQL-Version 2 gezeigt.
Für Linux, macOS oder Unix:
```
aws rds describe-engine-default-cluster-parameters \
--db-parameter-group-family aurora-mysql5.7 --query \
'EngineDefaults.Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | [?contains(SupportedEngineModes, `serverless`) == `true`] | [*].{param:ParameterName}' \
--output text
```
Für Windows:
```
aws rds describe-engine-default-cluster-parameters ^
--db-parameter-group-family aurora-mysql5.7 --query ^
"EngineDefaults.Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | [?contains(SupportedEngineModes, 'serverless') == `true`] | [*].{param:ParameterName}" ^
--output text
```
### Änderung von Parameterwerten für Aurora Serverless v1
Wie in [Parametergruppen für Amazon Aurora](USER_WorkingWithParamGroups.md) erläutert, können Sie Werte in einer Standardparametergruppe unabhängig von ihrem Typ (DB-Cluster-Parametergruppe, DB-Parametergruppe) nicht direkt ändern. Stattdessen erstellen Sie eine benutzerdefinierte Parametergruppe basierend auf der standardmäßigen DB-Cluster-Parametergruppe für Ihre Aurora-DB-Engine und ändern die Einstellungen nach Bedarf für diese Parametergruppe. Beispielsweise möchten Sie möglicherweise einige Einstellungen für Ihren Aurora Serverless v1 DB-Cluster ändern, um [Abfragen zu protokollieren oder DB-Engine-spezifische Protokolle auf Amazon hochzuladen](#aurora-serverless.logging) CloudWatch.
**So erstellen Sie eine benutzerdefinierte DB-Cluster-Parametergruppe**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie dann die Amazon RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie **Parameter groups (Parametergruppen)**.
1. Wählen Sie **Parametergruppe erstellen** aus, um den Parametergruppe-Detailbereich zu öffnen.
1. Wählen Sie die entsprechende Standard-DB-Cluster-Gruppe für die DB-Engine aus, die Sie für Ihren Aurora Serverless v1-DB-Cluster verwenden möchten. Wählen Sie dabei unbedingt die folgenden Optionen aus:
1. Wählen Sie unter **Parametergruppenfamilie** die entsprechende Familie für die von Ihnen gewählte DB-Engine aus. Achten Sie darauf, dass Ihre Auswahl das Präfix `aurora-` im Namen enthält.
1. Wählen Sie für **Typ** die Option **DB-Cluster-Parametergruppe**.
1. Geben Sie für **Gruppenname** und **Beschreibung** aussagekräftige Namen für Sie oder andere ein, die möglicherweise mit Ihrem Aurora Serverless v1-DB-Cluster und dessen Parametern arbeiten müssen.
1. Wählen Sie **Erstellen** aus.
Ihre benutzerdefinierte DB-Cluster-Parametergruppe wird der Liste der Parametergruppen hinzugefügt, die in Ihrer AWS-Region verfügbar sind. Sie können Ihre benutzerdefinierte DB-Cluster-Parametergruppe verwenden, wenn Sie neue Aurora Serverless v1-DB-Cluster erstellen. Sie können auch einen vorhandenen Aurora Serverless v1-DB-Cluster anpassen, sodass ser Ihre benutzerdefinierte DB-Cluster-Parametergruppe verwendet. Nachdem Ihr Aurora Serverless v1 DB-Cluster anfängt, Ihre benutzerdefinierte DB-Cluster-Parametergruppe zu verwenden, können Sie Werte für dynamische Parameter entweder mit AWS-Managementkonsole oder mit ändern AWS CLI.
Sie können die Konsole auch verwenden, um einen side-by-side Vergleich der Werte in Ihrer benutzerdefinierten DB-Cluster-Parametergruppe mit der Standard-DB-Cluster-Parametergruppe anzuzeigen, wie im folgenden Screenshot gezeigt.
![\[In Logs für Aurora MySQL- und Aurora Aurora Serverless v1 PostgreSQL-DB-Cluster veröffentlichte CloudWatch Protokolle\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-serverless-custom-db-cluster-param-cf-default.png)
Wenn Sie Parameterwerte in einem aktiven DB-Cluster ändern, startet Aurora Serverless v1 eine nahtlose Skalierung, um die Parameteränderungen anzuwenden. Wenn Ihr Aurora Serverless v1-DB-Cluster sich in einem pausierten Zustand befindet, wird er fortgesetzt und beginnt mit der Skalierung, damit er die Änderung vornehmen kann. Der Skalierungsvorgang für eine Parametergruppe ändert immer [Erzwingen einer Kapazitätsänderung](#aurora-serverless.how-it-works.timeout-action). Beachten Sie daher, dass das Ändern von Parametern zu unterbrochenen Verbindungen führen kann, wenn während der Skalierungsperiode kein Skalierungspunkt gefunden werden kann.
## Protokollierung für Aurora Serverless v1
Standardmäßig sind Fehlerprotokolle für aktiviert und Aurora Serverless v1 werden automatisch zu Amazon hochgeladen CloudWatch. Sie können Ihren Aurora Serverless v1 DB-Cluster auch veranlassen, Aurora-Datenbank-Engine-spezifische Protokolle hochzuladen. CloudWatch Aktivieren Sie dazu die Konfigurationsparameter in Ihrer benutzerdefinierten DB-Cluster-Parametergruppe. Ihr Aurora Serverless v1 DB-Cluster lädt dann alle verfügbaren Protokolle auf Amazon CloudWatch hoch. An dieser Stelle können Sie Protokolldaten analysieren CloudWatch , Alarme erstellen und Metriken anzeigen.
Für Aurora MySQL zeigt die folgende Tabelle die Protokolle, die Sie aktivieren können. Wenn sie aktiviert sind, werden sie automatisch von Ihrem Aurora Serverless v1 DB-Cluster zu Amazon hochgeladen CloudWatch.
| Aurora-MySQL-Protokoll | Description |
| --- | --- |
| `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 schnell ablaufende Abfragen im Protokoll für langsame Abfragen protokolliert werden. Kann auf einen Gleitkommawert zwischen 0 und 31 536 000 festgelegt 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](AuroraMySQL.Auditing.md).
Für Aurora PostgreSQL zeigt die folgende Tabelle die Protokolle, die Sie aktivieren können. Wenn sie aktiviert sind, werden sie CloudWatch zusammen mit den regulären Fehlerprotokollen automatisch von Ihrem Aurora Serverless v1 DB-Cluster zu Amazon hochgeladen.
| Aurora-PostgreSQL-Protokoll | Description |
| --- | --- |
| `log_connections` | Standardmäßig aktiviert und kann nicht geändert werden. Protokolliert Details für alle neuen Client-Verbindungen. |
| `log_disconnections` | Standardmäßig aktiviert und kann nicht geändert werden. Protokolliert alle Client-Verbindungstrennungen. |
| `log_hostname` | Standardmäßig deaktiviert und kann nicht geändert werden. Hostnamen werden nicht protokolliert. |
| `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`. |
Nachdem Sie die Logs für Aurora MySQL oder Aurora PostgreSQL für Ihren Aurora Serverless v1 DB-Cluster aktiviert haben, können Sie die Logs einsehen. CloudWatch
### Aurora Serverless v1Logs mit Amazon anzeigen CloudWatch
Aurora Serverless v1lädt automatisch CloudWatch alle Logs, die in Ihrer benutzerdefinierten DB-Cluster-Parametergruppe aktiviert sind, auf Amazon hoch („veröffentlicht“). Sie müssen die Protokolltypen nicht auswählen oder angeben. Das Hochladen von Protokollen beginnt, sobald Sie den Protokollkonfigurationsparameter aktivieren. Wenn Sie den Protokoll-Parameter später deaktivieren, werden weitere Uploads angehalten. Alle Protokolle, die bereits veröffentlicht wurden, CloudWatch bleiben jedoch bestehen, bis Sie sie löschen.
Weitere Informationen zur Verwendung CloudWatch mit Aurora MySQL-Protokollen finden Sie unter[Überwachung von Protokollereignissen in Amazon CloudWatch](AuroraMySQL.Integrating.CloudWatch.md#AuroraMySQL.Integrating.CloudWatch.Monitor).
Weitere Hinweise zu CloudWatch und Aurora PostgreSQL finden Sie unter. [Veröffentlichen von Aurora-PostgreSQL-Protokollen in Amazon CloudWatch Logs](AuroraPostgreSQL.CloudWatch.md)
**So zeigen Sie Protokolle für Ihren Aurora Serverless v1-DB-Cluster an:**
1. Öffnen Sie die CloudWatch Konsole unter. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)
1. Wähle deine AWS-Region.
1. Wählen Sie **Protokollgruppen**.
1. Wählen Sie Ihr DB-Cluster-Protokoll für Aurora Serverless v1 in der Liste aus. Bei Fehlerprotokollen ist das Benennungsmuster wie folgt:
```
/aws/rds/cluster/cluster-name/error
```
Im folgenden Screenshot finden Sie beispielsweise Verzeichnisse für Protokolle, die für einen Aurora PostgreSQL Aurora Serverless v1-DB-Cluster namens `western-sles` veröffentlicht wurden. Sie können auch mehrere Verzeichnisse für Aurora MySQL Aurora Serverless v1-DB-Cluster `west-coast-sles` finden. Wählen Sie das gewünschte Protokoll aus, um sich den Inhalt anzusehen.
![\[In Logs für Aurora MySQL- und Aurora Aurora Serverless v1 PostgreSQL-DB-Cluster veröffentlichte CloudWatch Protokolle\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-serverless-logs-in-cloudwatch.png)
## Aurora Serverless v1 und Wartung
Die Wartung des Aurora Serverless v1 DB-Clusters, z. B. die Anwendung der neuesten Funktionen, Fixes und Sicherheitsupdates, wird automatisch für Sie durchgeführt. Aurora Serverless v1hat ein Wartungsfenster, das Sie unter **Wartung und Backups** für Ihren Aurora Serverless v1 DB-Cluster einsehen können. AWS-Managementkonsole Sie finden dort das Datum und die Uhrzeit für die mögliche Durchführung der Wartung, und ob eine Wartung für Ihren Aurora Serverless v1-DB-Cluster aussteht, wie in der folgenden Abbildung dargestellt.
![\[Wartungsfenster für einen Beispiel-Aurora Serverless v1-DB-Cluster, keine ausstehende Wartung\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-serverless-maintenance-window.png)
Sie können das Wartungsfenster festlegen, wenn Sie den Aurora Serverless v1-DB-Cluster erstellen, und Sie können das Fenster später ändern. Weitere Informationen finden Sie unter [Anpassen des bevorzugten DB-Cluster-Wartungsfensters](USER_UpgradeDBInstance.Maintenance.md#AdjustingTheMaintenanceWindow.Aurora).
Wartungsfenster werden für geplante Hauptversions-Upgrades verwendet. Nebenversions-Upgrades und Patches werden sofort während der Skalierung angewendet. Die Skalierung erfolgt entsprechend Ihrer Einstellung für `TimeoutAction`:
+ `ForceApplyCapacityChange`: Die Änderung wird sofort angewendet.
+ `RollbackCapacityChange`: Aurora erzwingt die Aktualisierung des Clusters 3 Tage nach dem ersten Patchversuch.
Wie bei jeder Änderung, die ohne einen geeigneten Skalierungspunkt erzwungen wird, kann Ihr Workload dadurch unterbrochen werden.
Wann immer möglich, führt Aurora Serverless v1 die Wartung unterbrechungsfrei durch. Wenn eine Wartung erforderlich ist, skaliert Ihr Aurora Serverless v1-DB-Cluster seine Kapazität, damit die erforderlichen Vorgänge durchgeführt werden können. Vor dem Skalieren sucht Aurora Serverless v1 nach einem Skalierungspunkt. Dies geschieht bei Bedarf bis zu drei Tage lang.
Am Ende jedes Tages, an dem Aurora Serverless v1 keinen Skalierungspunkt finden kann, erstellt es ein Cluster-Ereignis. Dieses Ereignis informiert Sie über die ausstehende Wartung und die Notwendigkeit einer Skalierung für die Durchführung der Wartung. Die Benachrichtigung enthält auch das Datum, an dem Aurora Serverless v1 die Skalierung des DB-Clusters erzwingen kann.
Weitere Informationen finden Sie unter [Timeout-Aktion für Kapazitätsänderungen](#aurora-serverless.how-it-works.timeout-action).
## Aurora Serverless v1 und Failover
Wenn die DB-Instance für einen Aurora Serverless v1-DB-Cluster nicht mehr verfügbar ist oder die Availability Zone (AZ), in der sie sich befindet, ausfällt, erstellt Aurora die DB-Instance in einer anderen AZ neu. Allerdings ist der Aurora Serverless v1-Cluster kein Multi-AZ-Cluster. Das liegt daran, dass er aus einer einzigen DB-Instance in einer einzigen AZ besteht. Dieser Failover-Mechanismus benötigt mehr Zeit als bei einem Aurora-Cluster mit bereitgestellten oder Aurora Serverless v2-Instances. Die Aurora Serverless v1 Failover-Zeit ist nicht definiert, da sie von der Nachfrage und der Kapazitätsverfügbarkeit in anderen AZs Bereichen abhängt. AWS-Region
Da Aurora Rechenkapazität und Speicher voneinander trennt, verteilt sich das Speichervolumen für den Cluster auf mehrere AZs. Ihre Daten bleiben auch bei Ausfällen der DB-Instance oder der zugehörigen AZ verfügbar.
## Aurora Serverless v1 und Snapshots
Das Cluster-Volume für einen Aurora Serverless v1-Cluster ist immer verschlüsselt. Sie können den Verschlüsselungsschlüssel auswählen, aber Sie können die Verschlüsselung nicht deaktivieren. Zum Kopieren oder Freigeben eines Snapshots eines Aurora Serverless v1-Clusters verschlüsseln Sie den Snapshot mit Ihrem eigenen AWS KMS key. Weitere Informationen finden Sie unter [Kopieren eines DB-Cluster-Snapshots](aurora-copy-snapshot.md). Weitere Informationen zur Verschlüsselung und zu Amazon Aurora finden Sie unter [Verschlüsseln eines Amazon-Aurora-DB-Clusters](Overview.Encryption.md#Overview.Encryption.Enabling).
# Erstellen eines Aurora Serverless v1-DB Clusters
**Wichtig**
AWS hat [das Ende der Nutzungsdauer für Aurora Serverless v1 bekannt gegeben: 31. März 2025](https://repost.aws/questions/QUhcMVoChXRm2HLi8F-yih1g/announcement-support-for-aurora-s/announcement-support-for-aurora-serverless-v1-ending-soon). Alle Aurora Serverless v1-Cluster, die bis zum 31. März 2025 nicht migriert wurden, werden während des Wartungsfensters zu Aurora Serverless v2 migriert. Wenn das Upgrade fehlschlägt, konvertiert Amazon Aurora den Serverless-v1-Cluster während des Wartungsfensters in einen bereitgestellten Cluster mit der entsprechenden Engine-Version. Falls zutreffend, registriert Amazon Aurora den konvertierten bereitgestellten Cluster bei Amazon RDS Extended Support. Weitere Informationen finden Sie unter [Amazon RDS Extended Support mit Amazon Aurora](extended-support.md).
Mit dem folgenden Verfahren wird ein Aurora Serverless v1-Cluster ohne eines Ihrer Schemaobjekte oder Daten erstellt. Wenn Sie einen Aurora Serverless v1-Cluster erstellen möchten, der ein Duplikat eines vorhandenen bereitgestellten oder Aurora Serverless v1-Clusters ist, können Sie stattdessen eine Snapshot-Wiederherstellung oder einen Klonvorgang durchführen. Entsprechende Details finden Sie unter [Wiederherstellen aus einem DB-Cluster-Snapshot](aurora-restore-snapshot.md) und [Klonen eines Volumes für einen Amazon-Aurora-DB-Cluster](Aurora.Managing.Clone.md). Sie können einen vorhandenen bereitgestellten Cluster nicht in Aurora Serverless v1 konvertieren. Sie können einen vorhandenen Aurora Serverless v1-Cluster auch nicht wieder in einen bereitgestellten Cluster konvertieren.
Wenn Sie einen Aurora Serverless v1-DB-Cluster erstellen, können Sie die Mindest- und Höchstkapazität für den Cluster festlegen. Eine Kapazitätseinheit entspricht einer bestimmten Rechen- und Arbeitsspeicherkonfiguration. Aurora Serverless v1 erstellt Skalierungsregeln in Bezug auf Schwellenwerte für die CPU-Auslastung, Verbindungen und den verfügbaren Arbeitsspeicher. Außerdem erfolgt eine nahtlose Skalierung auf einen Bereich von Kapazitätseinheiten, wie für Ihre Anwendungen erforderlich. Weitere Informationen finden Sie unter [Aurora Serverless v1-Architektur](aurora-serverless-v1.how-it-works.md#aurora-serverless.architecture).
Sie können die folgenden spezifischen Werte für Ihren Aurora Serverless v1-DB-Cluster festlegen:
+ **Minimale Aurora Capacity Unit** – Aurora Serverless v1 kann die Kapazität bis zu dieser Kapazitätseinheit reduzieren.
+ **Maximale Aurora Capacity Unit** – Aurora Serverless v1 kann die Kapazität bis zu dieser Kapazitätseinheit erhöhen.
Sie können auch die folgenden optionalen Skalierungskonfigurationsoptionen auswählen:
+ **Bei Zeitüberschreitung Skalierung der Kapazität auf die angegebenen Werte durchsetzen** – Sie können diese Einstellung auswählen, wenn Sie möchten, dass Aurora Serverless v1 die Skalierung für Aurora Serverless v1 durchsetzt, auch wenn kein Skalierungspunkt gefunden wird, bevor die Zeitüberschreitung eintritt. Wenn Sie möchten, dass Aurora Serverless v1 Kapazitätsänderungen abbricht, wenn es keinen Skalierungspunkt findet, wählen Sie diese Einstellung nicht. Weitere Informationen finden Sie unter [Timeout-Aktion für Kapazitätsänderungen](aurora-serverless-v1.how-it-works.md#aurora-serverless.how-it-works.timeout-action).
+ **Rechenkapazität nach aufeinanderfolgenden Minuten von Inaktivität anhalten** – Sie können diese Einstellung auswählen, wenn Sie möchten, dass Aurora Serverless v1 auf Null skaliert wird, wenn es für einen von Ihnen angegebenen Zeitraum keine Aktivität auf dem DB-Cluster gibt. Wenn diese Einstellung aktiviert ist, setzt der Aurora Serverless v1-DB-Cluster die Verarbeitung automatisch fort und wird auf die notwendige Kapazität skaliert, um den Workload zu verarbeiten, wenn der Datenbankdatenverkehr fortgesetzt wird. Weitere Informationen hierzu finden Sie unter [Pausieren und Fortsetzen für Aurora Serverless v1](aurora-serverless-v1.how-it-works.md#aurora-serverless.how-it-works.pause-resume).
Bevor Sie einen Aurora Serverless v1-DB-Cluster erstellen können, benötigen Sie ein AWS-Konto. Sie müssen darüber hinaus die Einrichtungsaufgaben für die Arbeit mit Amazon Aurora abgeschlossen haben. Weitere Informationen finden Sie unter [Einrichten Ihrer Umgebung für Amazon Aurora](CHAP_SettingUp_Aurora.md). Sie müssen auch andere vorab erforderliche Schritte zum Erstellen eines Aurora-DB-Clusters ausführen. Weitere Informationen hierzu finden Sie unter [Erstellen eines Amazon Aurora-DB Clusters](Aurora.CreateInstance.md).
Aurora Serverless v1 ist in bestimmten AWS-Regionen und nur für bestimmte Aurora-MySQL- und Aurora-PostgreSQL-Versionen verfügbar. Weitere Informationen finden Sie unter [Aurora Serverless v1](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV1.md).
**Anmerkung**
Das Cluster-Volume für einen Aurora Serverless v1-Cluster ist immer verschlüsselt. Wenn Sie Ihren Aurora Serverless v1-DB-Cluster erstellen, können Sie die Verschlüsselung nicht deaktivieren, aber Sie können Ihren eigenen Verschlüsselungsschlüssel verwenden. Bei Aurora Serverless v2 können Sie auswählen, ob das Cluster-Volume verschlüsselt werden soll.
Sie können einen Aurora Serverless v1-DB-Cluster über die AWS CLI oder die RDS-API erstellen.
**Anmerkung**
Wenn beim Versuch, den Cluster zu erstellen, die folgende Fehlermeldung angezeigt wird, benötigt Ihr Konto zusätzliche Berechtigungen.
`Unable to create the resource. Verify that you have permission to create service linked role. Otherwise wait and try again later.`
Weitere Informationen finden Sie unter [Verwenden von serviceverknüpften Rollen für Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md).
Sie können keine direkte Verbindung zur DB-Instance in Ihrem Aurora Serverless v1-DB-Cluster herstellen. Um eine Verbindung zum Aurora Serverless v1-DB-Cluster herzustellen, verwenden Sie den Datenbankendpunkt. Sie finden den Endpunkt für Ihren Aurora Serverless v1-DB-Cluster auf der Registerkarte **Connectivity & security** (Konnektivität und Sicherheit) für Ihren Cluster in der AWS-Managementkonsole. Weitere Informationen finden Sie unter [Herstellen einer Verbindung mit einem Amazon Aurora-DB-Cluster](Aurora.Connecting.md).
## AWS CLI
Um einen neuen Aurora Serverless v1-DB-Cluster über die AWS CLI zu erstellen, führen Sie den Befehl [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) aus und geben `serverless` für die Option `--engine-mode` an.
Optional können Sie die Option `--scaling-configuration` angeben, um die minimale Kapazität, die maximale Kapazität und die automatische Pause zu konfigurieren, wenn es keine Verbindungen gibt.
Die folgenden Befehlsbeispiele erstellen einen neuen Serverless DB-Cluster, indem Sie die `--engine-mode`-Option auf `serverless` festlegen. Die Beispiele definieren auch Werte für die `--scaling-configuration`-Option.
### Beispiel für Aurora MySQL
Mit den folgenden Befehlen werden neue Aurora MySQL-kompatible Serverless-DB-Cluster erstellt. Gültige Kapazitätswerte für Aurora MySQL sind `1`, `2`, `4`, `8`, `16`, `32`, `64`, `128` und `256`.
Linux, macOS oder Unix:
```
aws rds create-db-cluster --db-cluster-identifier sample-cluster \
--engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.4 \
--engine-mode serverless \
--scaling-configuration MinCapacity=4,MaxCapacity=32,SecondsUntilAutoPause=1000,AutoPause=true \
--master-username username --master-user-password password
```
Für Windows:
```
aws rds create-db-cluster --db-cluster-identifier sample-cluster ^
--engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.4 ^
--engine-mode serverless ^
--scaling-configuration MinCapacity=4,MaxCapacity=32,SecondsUntilAutoPause=1000,AutoPause=true ^
--master-username username --master-user-password password
```
### Beispiel für Aurora PostgreSQL
Mit dem folgenden Befehl wird ein neuer, mit PostgreSQL 13.9 kompatibler Serverless-DB-Cluster erstellt. Gültige Kapazitätswerte für Aurora PostgreSQL sind `2`, `4`, `8`, `16`, `32`, `64`, `192` und `384`.
Für Linux, macOS oder Unix:
```
aws rds create-db-cluster --db-cluster-identifier sample-cluster \
--engine aurora-postgresql --engine-version 13.9 \
--engine-mode serverless \
--scaling-configuration MinCapacity=8,MaxCapacity=64,SecondsUntilAutoPause=1000,AutoPause=true \
--master-username username --master-user-password password
```
Für Windows:
```
aws rds create-db-cluster --db-cluster-identifier sample-cluster ^
--engine aurora-postgresql --engine-version 13.9 ^
--engine-mode serverless ^
--scaling-configuration MinCapacity=8,MaxCapacity=64,SecondsUntilAutoPause=1000,AutoPause=true ^
--master-username username --master-user-password password
```
## RDS-API
Zum Erstellen eines neuen Aurora Serverless v1-DB-Clusters über die RDS-API führen Sie die [CreateDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html)-Operation durch und geben `serverless` als `EngineMode`-Parameter an.
Optional können Sie den Parameter `ScalingConfiguration` angeben, um die minimale Kapazität, die maximale Kapazität und die automatische Pause zu konfigurieren, wenn es keine Verbindungen gibt. Zu den gültigen Kapazitätswerten gehören die folgenden:
+ Aurora MySQL: `1`, `2`, `4`, `8`, `16`, `32`, `64`, `128` und `256`.
+ Aurora PostgreSQL: `2`, `4`, `8`, `16`, `32`, `64`, `192` und `384`.
# Wiederherstellen eines Aurora Serverless v1-DB-Clusters
**Wichtig**
AWS hat [das Ende der Nutzungsdauer für Aurora Serverless v1 bekannt gegeben: 31. März 2025](https://repost.aws/questions/QUhcMVoChXRm2HLi8F-yih1g/announcement-support-for-aurora-s/announcement-support-for-aurora-serverless-v1-ending-soon). Alle Aurora Serverless v1-Cluster, die bis zum 31. März 2025 nicht migriert wurden, werden während des Wartungsfensters zu Aurora Serverless v2 migriert. Wenn das Upgrade fehlschlägt, konvertiert Amazon Aurora den Serverless-v1-Cluster während des Wartungsfensters in einen bereitgestellten Cluster mit der entsprechenden Engine-Version. Falls zutreffend, registriert Amazon Aurora den konvertierten bereitgestellten Cluster bei Amazon RDS Extended Support. Weitere Informationen finden Sie unter [Amazon RDS Extended Support mit Amazon Aurora](extended-support.md).
Sie können einen Aurora Serverless v1-DB-Cluster konfigurieren, wenn Sie einen bereitgestellten DB-Cluster-Snapshot über die AWS CLI oder die RDS-API wiederherstellen.
Wenn Sie einen Snapshot in einem Aurora Serverless v1-DB-Cluster wiederherstellen, können Sie die folgenden Werte festlegen:
+ **Minimale Aurora Capacity Unit** – Aurora Serverless v1 kann die Kapazität bis zu dieser Kapazitätseinheit reduzieren.
+ **Maximale Aurora Capacity Unit** – Aurora Serverless v1 kann die Kapazität bis zu dieser Kapazitätseinheit erhöhen.
+ **Zeitüberschreitungsaktion** – Die Aktion, die ausgeführt werden soll, wenn für eine Kapazitätsänderung eine Zeitüberschreitung eintritt, da kein Skalierungspunkt gefunden werden kann.Aurora Serverless v1 Der -DB-Cluster kann die neuen Kapazitätseinstellungen für Ihren DB-Cluster durchsetzen, wenn Sie die Option **Bei Zeitüberschreitung Skalierung der Kapazität auf die angegebenen Werte durchsetzen** auswählen. Er kann auch einen Rollback für die Kapazitätsänderung ausführen, um sie zu stornieren, wenn Sie die Option nicht auswählen. Weitere Informationen finden Sie unter [Timeout-Aktion für Kapazitätsänderungen](aurora-serverless-v1.how-it-works.md#aurora-serverless.how-it-works.timeout-action).
+ **Pause after inactivity (Nach Inaktivität pausieren)**: Die Zeitdauer, die ohne Datenbankverkehr verstreichen muss, bis auf eine Verarbeitungskapazität von null skaliert wird. Wenn der Datenbankverkehr wieder aufgenommen wird, nimmt Aurora automatisch die Verarbeitungskapazität wieder auf und skaliert sie in Übereinstimmung mit dem Datenverkehr.
Allgemeine Informationen zum Wiederherstellen eines DB-Clusters aus einem Snapshot finden Sie unter [Wiederherstellen aus einem DB-Cluster-Snapshot](aurora-restore-snapshot.md).
## AWS CLI
Sie können einen Aurora Serverless-DB-Cluster konfigurieren, wenn Sie einen bereitgestellten DB-Cluster-Snapshot über die AWS-Managementkonsole, die AWS CLI oder die RDS-API wiederherstellen.
Wenn Sie einen Snapshot in einem Aurora Serverless-DB-Cluster wiederherstellen, können Sie die folgenden Werte festlegen:
+ **Minimale Aurora Capacity Unit** – Aurora Serverless kann die Kapazität bis zu dieser Kapazitätseinheit reduzieren.
+ **Maximale Aurora Capacity Unit** – Aurora Serverless kann die Kapazität bis zu dieser Kapazitätseinheit erhöhen.
+ **Zeitüberschreitungsaktion** – Die Aktion, die ausgeführt werden soll, wenn für eine Kapazitätsänderung eine Zeitüberschreitung eintritt, da kein Skalierungspunkt gefunden werden kann.Aurora Serverless v1 Der -DB-Cluster kann die neuen Kapazitätseinstellungen für Ihren DB-Cluster durchsetzen, wenn Sie die Option **Bei Zeitüberschreitung Skalierung der Kapazität auf die angegebenen Werte durchsetzen** auswählen. Er kann auch einen Rollback für die Kapazitätsänderung ausführen, um sie zu stornieren, wenn Sie die Option nicht auswählen. Weitere Informationen finden Sie unter [Timeout-Aktion für Kapazitätsänderungen](aurora-serverless-v1.how-it-works.md#aurora-serverless.how-it-works.timeout-action).
+ **Pause after inactivity (Nach Inaktivität pausieren)**: Die Zeitdauer, die ohne Datenbankverkehr verstreichen muss, bis auf eine Verarbeitungskapazität von null skaliert wird. Wenn der Datenbankverkehr wieder aufgenommen wird, nimmt Aurora automatisch die Verarbeitungskapazität wieder auf und skaliert sie in Übereinstimmung mit dem Datenverkehr.
**Anmerkung**
Die Version des DB-Cluster-Snapshots muss mit Aurora Serverless v1 kompatibel sein. Eine Liste der unterstützten Versionen finden Sie unter [Aurora Serverless v1](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV1.md).
Zum Wiederherstellen eines Snapshots in einem Aurora Serverless v1-Cluster mit MySQL 5.7-Kompatibilität fügen Sie die folgenden Parameter hinzu:
+ `--engine aurora-mysql`
+ `--engine-version 5.7`
Mit den Parametern `--engine` und `--engine-version` können Sie einen MySQL 5.7-kompatiblen Aurora Serverless v1-Cluster aus einem MySQL 5.6-kompatiblen Aurora- oder Aurora Serverless v1-Snapshot erstellen. Im folgenden Beispiel wird ein Snapshot aus einem MySQL 5.6-kompatiblen Cluster namens *mydbclustersnapshot* in einem MySQL 5.7-kompatiblen Aurora Serverless v1-Cluster namens *mynewdbcluster*wiederhergestellt.
Für Linux, macOS oder Unix:
```
aws rds restore-db-cluster-from-snapshot \
--db-cluster-identifier mynewdbcluster \
--snapshot-identifier mydbclustersnapshot \
--engine-mode serverless \
--engine aurora-mysql \
--engine-version 5.7
```
Für Windows:
```
aws rds restore-db-cluster-from-snapshot ^
--db-instance-identifier mynewdbcluster ^
--db-snapshot-identifier mydbclustersnapshot ^
--engine aurora-mysql ^
--engine-version 5.7
```
Optional können Sie die Option `--scaling-configuration` angeben, um die minimale Kapazität, die maximale Kapazität und die automatische Pause zu konfigurieren, wenn es keine Verbindungen gibt. Zu den gültigen Kapazitätswerten gehören die folgenden:
+ Aurora MySQL: `1`, `2`, `4`, `8`, `16`, `32`, `64`, `128` und `256`.
+ Aurora PostgreSQL: `2`, `4`, `8`, `16`, `32`, `64`, `192` und `384`.
Im folgenden Beispiel können Sie von einem zuvor erstellten DB-Cluster-Snapshot namens *mydbclustersnapshot* in einem neuen DB-Cluster namens *mynewdbcluster*wiederherstellen. Sie legen `--scaling-configuration` so fest, dass der neue Aurora Serverless v1-DB-Cluster bei Bedarf von 8 ACUs auf 64 ACUs (Aurora-Kapazitätseinheiten) skaliert werden kann, um die Workload zu verarbeiten. Nach Abschluss der Verarbeitung und nach 1000 Sekunden ohne zu unterstützende Verbindungen wird der Cluster heruntergefahren, bis die Verbindungsanforderung zum Neustart auffordert.
Für Linux, macOS oder Unix:
```
aws rds restore-db-cluster-from-snapshot \
--db-cluster-identifier mynewdbcluster \
--snapshot-identifier mydbclustersnapshot \
--engine-mode serverless --scaling-configuration MinCapacity=8,MaxCapacity=64,TimeoutAction='ForceApplyCapacityChange',SecondsUntilAutoPause=1000,AutoPause=true
```
Für Windows:
```
aws rds restore-db-cluster-from-snapshot ^
--db-instance-identifier mynewdbcluster ^
--db-snapshot-identifier mydbclustersnapshot ^
--engine-mode serverless --scaling-configuration MinCapacity=8,MaxCapacity=64,TimeoutAction='ForceApplyCapacityChange',SecondsUntilAutoPause=1000,AutoPause=true
```
## RDS-API
Um einen Aurora Serverless v1-DB-Cluster zu konfigurieren, wenn Sie eine Wiederherstellung von einem DB-Cluster über die RDS-API durchführen, führen Sie die Operation [RestoreDBClusterFromSnapshot](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterFromSnapshot.html) durch und geben `serverless` als `EngineMode`-Parameter an.
Optional können Sie den Parameter `ScalingConfiguration` angeben, um die minimale Kapazität, die maximale Kapazität und die automatische Pause zu konfigurieren, wenn es keine Verbindungen gibt. Zu den gültigen Kapazitätswerten gehören die folgenden:
+ Aurora MySQL: `1`, `2`, `4`, `8`, `16`, `32`, `64`, `128` und `256`.
+ Aurora PostgreSQL: `2`, `4`, `8`, `16`, `32`, `64`, `192` und `384`.
# Ändern eines Aurora Serverless v1-DB-Clusters
**Wichtig**
AWS hat [den end-of-life Termin bekannt gegeben fürAurora Serverless v1: 31. März 2025](https://repost.aws/questions/QUhcMVoChXRm2HLi8F-yih1g/announcement-support-for-aurora-s/announcement-support-for-aurora-serverless-v1-ending-soon). Alle Aurora Serverless v1-Cluster, die bis zum 31. März 2025 nicht migriert wurden, werden während des Wartungsfensters zu Aurora Serverless v2 migriert. Wenn das Upgrade fehlschlägt, konvertiert Amazon Aurora den Serverless-v1-Cluster während des Wartungsfensters in einen bereitgestellten Cluster mit der entsprechenden Engine-Version. Falls zutreffend, registriert Amazon Aurora den konvertierten bereitgestellten Cluster bei Amazon RDS Extended Support. Weitere Informationen finden Sie unter [Amazon RDS Extended Support mit Amazon Aurora](extended-support.md).
Nachdem Sie einen Aurora Serverless v1 DB-Cluster konfiguriert haben, können Sie bestimmte Eigenschaften mit der AWS-Managementkonsole AWS CLI, der oder der RDS-API ändern. Die meisten Eigenschaften, die Sie ändern können, sind die gleichen wie für andere Arten von Aurora-Clustern.
Die für Aurora Serverless v1 wichtigsten Änderungen sind folgende:
+ [Ändern der Skalierungskonfiguration](#aurora-serverless.modifying.scaling)
+ [Durchführen eines Upgrades der Hauptversion](#aurora-serverless.modifying.upgrade)
+ [Konvertieren von Aurora Serverless v1 in bereitgestellt](#aurora-serverless.modifying.convert)
## Ändern der Skalierungskonfiguration eines DB-Clusters von Aurora Serverless v1
Sie können die minimale und maximale Kapazität für den DB-Cluster festlegen. Jede Kapazitätseinheit entspricht einer bestimmten Rechen- und Arbeitsspeicherkonfiguration. Aurora Serverless erstellt automatisch Skalierungsregeln in Bezug auf Schwellenwerte für die CPU-Auslastung, Verbindungen und den verfügbaren Arbeitsspeicher. Sie können auch festlegen, ob Aurora Serverless die Datenbank anhalten soll, wenn es keine Aktivitäten gibt, und weiterlaufen lassen soll, wenn wieder Aktivitäten beginnen.
Sie können die folgenden spezifischen Werte für die Skalierungskonfiguration festlegen:
+ **Minimale Aurora Capacity Unit** – Aurora Serverless kann die Kapazität bis zu dieser Kapazitätseinheit reduzieren.
+ **Maximale Aurora Capacity Unit** – Aurora Serverless kann die Kapazität bis zu dieser Kapazitätseinheit erhöhen.
+ **Zeitüberschreitung und Aktion für automatische Skalierung **- Dieser Abschnitt gibt an, wie langeAurora Serverless wartet, um einen Skalierungspunkt zu finden, bevor die Zeitüberschreitung eintritt. Sie legt auch fest, was zu tun ist, wenn eine Kapazitätsänderung nicht mehr funktioniert, weil sie keinen Skalierungspunkt findet. Aurora kann die Kapazitätsänderung erzwingen, um die Kapazität so schnell wie möglich auf den angegebenen Wert zu setzen. Die Kapazitätsänderung kann auch zurückgesetzt und somit abgebrochen werden. Weitere Informationen finden Sie unter [Timeout-Aktion für Kapazitätsänderungen](aurora-serverless-v1.how-it-works.md#aurora-serverless.how-it-works.timeout-action).
+ **Pause nach Inaktivität** — Verwenden Sie die optionale Einstellung **Kapazität auf 0 skalieren, ACUs wenn der Cluster inaktiv ist**, um die Datenbank auf keine Verarbeitungskapazität zu skalieren, solange sie inaktiv ist. Wenn der Datenbankverkehr fortgesetzt wird, setzt Aurora die Verarbeitung automatisch fort und skaliert sie entsprechend dem Datenverkehr.
**Anmerkung**
Wenn Sie den Kapazitätsbereich für einen DB-Cluster von Aurora Serverless ändern, erfolgt die Änderung sofort, unabhängig davon, ob Sie sie sofort oder während des nächsten geplanten Wartungsfensters anwenden möchten.
### Konsole
Sie können die Skalierungskonfiguration eines Aurora-DB-Clusters über die AWS-Managementkonsoleändern.
**So ändern Sie einen Aurora Serverless v1-DB-Cluster:**
1. Öffnen Sie die Amazon RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie im Navigationsbereich **Databases (Datenbanken)** aus.
1. Wählen Sie den Aurora Serverless v1DB-Cluster, den Sie ändern möchten.
1. Wählen Sie für **Aktionen** die Option **Cluster ändern**.
1. Ändern Sie im Abschnitt **Capacity settings (Kapazitätseinstellungen)** die Skalierungskonfiguration.
1. Klicken Sie auf **Weiter**.
1. Überprüfen Sie Ihre Änderungen auf der Seite **DB-Cluster ändern** und wählen Sie aus, wann diese angewendet werden sollen.
1. Wählen Sie **Cluster bearbeiten** aus.
### AWS CLI
Um die Skalierungskonfiguration eines Aurora Serverless v1 DB-Clusters mithilfe von zu ändern AWS CLI, führen Sie den [modify-db-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/modify-db-cluster.html) AWS CLI Befehl aus. Geben Sie die Option `--scaling-configuration` an, um die minimale Kapazität, die maximale Kapazität und die automatische Pause zu konfigurieren, wenn es keine Verbindungen gibt. Zu den gültigen Kapazitätswerten gehören die folgenden:
+ Aurora MySQL: `1`, `2`, `4`, `8`, `16`, `32`, `64`, `128` und `256`.
+ Aurora PostgreSQL: `2`, `4`, `8`, `16`, `32`, `64`, `192` und `384`.
In diesem Beispiel ändern Sie die Skalierungskonfiguration eines Aurora Serverless v1 DB-Clusters mit dem Namen*sample-cluster*.
Für Linux, macOS oder Unix:
```
aws rds modify-db-cluster \
--db-cluster-identifier sample-cluster \
--scaling-configuration MinCapacity=8,MaxCapacity=64,SecondsUntilAutoPause=500,TimeoutAction='ForceApplyCapacityChange',AutoPause=true
```
Für Windows:
```
aws rds modify-db-cluster ^
--db-cluster-identifier sample-cluster ^
--scaling-configuration MinCapacity=8,MaxCapacity=64,SecondsUntilAutoPause=500,TimeoutAction='ForceApplyCapacityChange',AutoPause=true
```
### RDS-API
Sie können die Skalierungskonfiguration eines Aurora-DB-Clusters mit der Operation „DBClusterAPI [modifizieren](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html)“ ändern. Geben Sie den Parameter `ScalingConfiguration` an, um die minimale Kapazität, die maximale Kapazität und die automatische Pause zu konfigurieren, wenn es keine Verbindungen gibt. Zu den gültigen Kapazitätswerten gehören die folgenden:
+ Aurora MySQL: `1`, `2`, `4`, `8`, `16`, `32`, `64`, `128` und `256`.
+ Aurora PostgreSQL: `2`, `4`, `8`, `16`, `32`, `64`, `192` und `384`.
## Durchführen eines Upgrades der Hauptversion eines DB-Clusters von Aurora Serverless v1
**Wichtig**
AWS hat [den end-of-life Termin bekannt gegeben fürAurora Serverless v1: 31. März 2025](https://repost.aws/questions/QUhcMVoChXRm2HLi8F-yih1g/announcement-support-for-aurora-s/announcement-support-for-aurora-serverless-v1-ending-soon). Alle Aurora Serverless v1-Cluster, die bis zum 31. März 2025 nicht migriert wurden, werden während des Wartungsfensters zu Aurora Serverless v2 migriert. Wenn das Upgrade fehlschlägt, konvertiert Amazon Aurora den Serverless-v1-Cluster während des Wartungsfensters in einen bereitgestellten Cluster mit der entsprechenden Engine-Version. Falls zutreffend, registriert Amazon Aurora den konvertierten bereitgestellten Cluster bei Amazon RDS Extended Support. Weitere Informationen finden Sie unter [Amazon RDS Extended Support mit Amazon Aurora](extended-support.md).
Sie können die Hauptversion für einen Aurora Serverless v1-DB-Cluster, der mit PostgreSQL 11 kompatibel ist, auf eine entsprechende mit PostgreSQL 13 kompatible Version aktualisieren.
### Konsole
Sie können ein direktes Upgrade des DB-Clusters von Aurora Serverless v1 mit der AWS-Managementkonsole durchführen.
**So führen Sie ein Upgrade eines DB-Clusters von Aurora Serverless v1 durch**
1. Öffnen Sie die Amazon RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie im Navigationsbereich **Datenbanken** aus.
1. Wählen Sie den DB-Cluster von Aurora Serverless v1 aus, für den Sie ein Upgrade durchführen möchten.
1. Wählen Sie für **Aktionen** die Option **Cluster ändern**.
1. Wählen Sie für **Version** eine Versionsnummer von Aurora PostgreSQL Version 13.
Das folgende Beispiel zeigt ein direktes Upgrade von Aurora PostgreSQL 11.16 auf 13.9.
![\[Upgraden eines DB-Clusters von Aurora Serverless v1 mithilfe der Konsole\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/sv1-upgrade-apg11-to-13.png)
Wenn Sie ein Hauptversions-Upgrade durchführen, lassen Sie alle anderen Eigenschaften unverändert. Wenn Sie eine der anderen Eigenschaften ändern möchten, führen Sie einen anderen Vorgang **Ändern** nach Abschluss des Upgrades aus.
1. Klicken Sie auf **Weiter**.
1. Überprüfen Sie Ihre Änderungen auf der Seite **DB-Cluster ändern** und wählen Sie aus, wann diese angewendet werden sollen.
1. Wählen Sie **Cluster bearbeiten** aus.
### AWS CLI
Wenn Sie ein direktes Upgrade von einem mit PostgreSQL 11 kompatiblen DB-Cluster von Aurora Serverless v1 auf einen mit PostgreSQL 13 kompatiblen Cluster durchführen möchten, geben Sie den Parameter `--engine-version` mit einer Versionsnummer von Aurora PostgreSQL Version 13 an, die mit Aurora Serverless v1 kompatibel ist. Nehmen Sie außerdem den Parameter `--allow-major-version-upgrade` mit auf.
In diesem Beispiel ändern Sie die Hauptversion eines mit PostgreSQL 11 kompatiblen Aurora Serverless v1-DB-Clusters namens `sample-cluster`. Dadurch wird ein direktes Upgrade auf einen mit PostgreSQL 13 kompatiblen DB-Cluster von Aurora Serverless v1 durchgeführt.
```
aws rds modify-db-cluster \
--db-cluster-identifier sample-cluster \
--engine-version 13.serverless_12 \
--allow-major-version-upgrade
```
Für Windows:
```
aws rds modify-db-cluster ^
--db-cluster-identifier sample-cluster ^
--engine-version 13.serverless_12 ^
--allow-major-version-upgrade
```
### RDS-API
Wenn Sie ein direktes Upgrade von einem mit PostgreSQL 11 kompatiblen DB-Cluster von Aurora Serverless v1 auf einen mit PostgreSQL 13 kompatiblen Cluster durchführen möchten, geben Sie den Parameter `EngineVersion` mit einer Versionsnummer von Aurora PostgreSQL Version 13 an, die mit Aurora Serverless v1 kompatibel ist. Nehmen Sie außerdem den Parameter `AllowMajorVersionUpgrade` mit auf.
## Konvertieren eines DB-Clusters von Aurora Serverless v1 zu einem bereitgestellten Cluster
Sie können einen DB-Cluster von Aurora Serverless v1 zu einem bereitgestellten DB-Cluster konvertieren. Um die Konvertierung durchzuführen, verwenden Sie die AWS CLI oder die Amazon RDS-API, um die DB-Instance-Klasse in **Provisioned** zu ändern. Gehen Sie wie folgt vor, um Ihre DB-Instance-Klasse zu ändern.
Das folgende Beispiel zeigt, wie Sie mit der AWS CLI einen Aurora Serverless v1 DB-Cluster in einen bereitgestellten Cluster konvertieren.
### AWS CLI
Führen Sie den Befehl aus, um einen Aurora Serverless v1 DB-Cluster in einen bereitgestellten Cluster zu konvertieren. [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) AWS CLI
Die folgenden Parameter sind erforderlich:
+ `--db-cluster-identifier` – Der DB-Cluster von Aurora Serverless v1, den Sie in einen bereitgestellten Cluster konvertieren.
+ `--engine-mode` – Verwenden Sie den Wert `provisioned`.
+ `--allow-engine-mode-change`
+ `--db-cluster-instance-class` – Wählen Sie die DB-Instance-Klasse für den bereitgestellten DB-Cluster auf der Grundlage der Kapazität des DB-Clusters von Aurora Serverless v1.
In diesem Beispiel konvertieren Sie einen DB-Cluster von Aurora Serverless v1 mit dem Namen `sample-cluster` und verwenden die DB-Instance-Klasse `db.r5.xlarge`.
Für Linux, macOS oder Unix:
```
aws rds modify-db-cluster \
--db-cluster-identifier sample-cluster \
--engine-mode provisioned \
--allow-engine-mode-change \
--db-cluster-instance-class db.r5.xlarge
```
Für Windows:
```
aws rds modify-db-cluster ^
--db-cluster-identifier sample-cluster ^
--engine-mode provisioned ^
--allow-engine-mode-change ^
--db-cluster-instance-class db.r5.xlarge
```
Das folgende Beispiel zeigt, wie Sie mit der Amazon-RDS-API einen Aurora Serverless v1-DB-Cluster in einen bereitgestellten Cluster konvertieren.
### RDS-API
Verwenden Sie den Vorgang „DBClusterAPI [modifizieren](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html)“, um einen Aurora Serverless v1 DB-Cluster in einen bereitgestellten Cluster zu konvertieren.
Die folgenden Parameter sind erforderlich:
+ `DBClusterIdentifier` – Der DB-Cluster von Aurora Serverless v1, den Sie in einen bereitgestellten Cluster konvertieren.
+ `EngineMode` – Verwenden Sie den Wert `provisioned`.
+ `AllowEngineModeChange`
+ `DBClusterInstanceClass` – Wählen Sie die DB-Instance-Klasse für den bereitgestellten DB-Cluster auf der Grundlage der Kapazität des DB-Clusters von Aurora Serverless v1.
## Überlegungen bei der Konvertierung von einem Aurora Serverless v1-DB-Cluster zu einem bereitgestellten Cluster
Bei der Konvertierung von einem Aurora Serverless v1-DB-Cluster zu einem bereitgestellten Cluster sollten Sie Folgendes berücksichtigen:
+ Sie können diese Konvertierung im Rahmen des Upgrades Ihres DB-Clusters von Aurora Serverless v1 auf Aurora Serverless v2 verwenden. Weitere Informationen finden Sie unter [Aktualisieren eines Aurora Serverless v1-Clusters auf Aurora Serverless v2](aurora-serverless-v2.upgrade.md#aurora-serverless-v2.upgrade-from-serverless-v1-procedure).
+ Der Konvertierungsprozess erstellt eine Reader-DB-Instance im DB-Cluster, stuft die Reader-Instance zu einer Writer-Instance hoch und löscht dann die ursprüngliche Instance von Aurora Serverless v1. Wenn Sie den DB-Cluster konvertieren, können Sie keine anderen Änderungen gleichzeitig vornehmen, z. B. die DB-Engine-Version oder die DB-Cluster-Parametergruppe ändern. Der Konvertierungsvorgang wird sofort angewendet und kann nicht rückgängig gemacht werden.
+ Bei der Konvertierung wird ein Backup-DB-Cluster-Snapshot des DB-Clusters für den Fall erstellt, dass ein Fehler auftritt. Der Bezeichner des DB-Cluster-Snapshots hat das Format `pre-modify-engine-mode-DB_cluster_identifier-timestamp`.
+ Aurora verwendet die aktuelle Standard-DB-Engine-Nebenversion für den bereitgestellten DB-Cluster.
+ Wenn Sie keine DB-Instance-Klasse für Ihren konvertierten DB-Cluster angeben, empfiehlt Aurora eine Klasse auf Basis der maximalen Kapazität des ursprünglichen DB-Clusters von Aurora Serverless v1. Die empfohlenen Kapazitäts- und Instance-Klassenzuordnungen sind in der folgenden Tabelle aufgeführt.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/aurora-serverless.modifying.html)
**Anmerkung**
Abhängig von der ausgewählten DB-Instance-Klasse und Ihrer Datenbanknutzung fallen für einen bereitgestellten DB-Cluster im Vergleich zu Aurora Serverless v1 möglicherweise andere Kosten an.
Wenn Sie Ihren DB-Cluster von Aurora Serverless v1 in eine burstfähige DB-Instance-Klasse (db.t\$1) konvertieren, können zusätzliche Kosten für die Verwendung des DB-Clusters anfallen. Weitere Informationen finden Sie unter [DB-Instance-Klassenarten](Concepts.DBInstanceClass.Types.md).
# Manuelles Skalieren der Kapazität des Aurora Serverless v1-DB-Clusters
**Wichtig**
AWS hat [das Ende der Nutzungsdauer für Aurora Serverless v1 bekannt gegeben: 31. März 2025](https://repost.aws/questions/QUhcMVoChXRm2HLi8F-yih1g/announcement-support-for-aurora-s/announcement-support-for-aurora-serverless-v1-ending-soon). Alle Aurora Serverless v1-Cluster, die bis zum 31. März 2025 nicht migriert wurden, werden während des Wartungsfensters zu Aurora Serverless v2 migriert. Wenn das Upgrade fehlschlägt, konvertiert Amazon Aurora den Serverless-v1-Cluster während des Wartungsfensters in einen bereitgestellten Cluster mit der entsprechenden Engine-Version. Falls zutreffend, registriert Amazon Aurora den konvertierten bereitgestellten Cluster bei Amazon RDS Extended Support. Weitere Informationen finden Sie unter [Amazon RDS Extended Support mit Amazon Aurora](extended-support.md).
In der Regel werden Aurora Serverless v1-DB-Cluster basierend auf dem Workload nahtlos skaliert. Die Kapazität kann jedoch nicht immer schnell genug skaliert werden, um plötzliche Extreme wie einen exponentiellen Anstieg der Transaktionen zu meistern. In solchen Fällen können Sie den Skalierungsvorgang manuell initiieren, indem Sie einen neuen Kapazitätswert festlegen. Nachdem Sie die Kapazität explizit festgelegt haben, skaliert Aurora Serverless v1 den DB-Cluster automatisch. Der Vorgang basiert auf der Ruhepause für die Herunterskalierung.
Sie können die Kapazität eines Aurora Serverless v1-DB-Clusters über die AWS-Managementkonsole, die AWS CLI oder die RDS-API explizit auf einen bestimmten Wert festlegen.
## Konsole
Sie können die Kapazität eines Aurora-DB-Clusters über die AWS-Managementkonsole festlegen.
**So ändern Sie einen Aurora Serverless v1-DB-Cluster:**
1. Öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie im Navigationsbereich **Databases (Datenbanken)** aus.
1. Wählen Sie den Aurora Serverless v1-DB-Cluster aus, den Sie ändern möchten.
1. Wählen Sie für **Actions (Aktionen)** die Option **Set capacity (Kapazität festlegen)** aus.
1. Wählen Sie im Fenster **Datenbankkapazität skalieren** Folgendes aus:
1. Wählen Sie bei der Dropdown-Auswahl für **Scale DB-Cluster to (DB-Cluster skalieren auf)** die neue Kapazität aus, die Sie für Ihren DB-Cluster verwenden möchten.
1. Wählen Sie beim Kontrollkästchen **If a seamless scaling point cannot be found** (Wenn kein nahtloser Skalierungspunkt gefunden werden kann) das gewünschte Verhalten für die `TimeoutAction`-Einstellung des Aurora Serverless v1-DB-Clusters aus:
+ Deaktivieren Sie diese Option, wenn Sie möchten, dass die Kapazität unverändert bleibt, wenn Aurora Serverless v1 vor dem Timeout keinen Skalierungspunkt finden kann.
+ Aktivieren Sie diese Option, wenn Sie erzwingen möchten, dass der Aurora Serverless v1-DB-Cluster seine Kapazität ändert, auch wenn er vor dem Timeout keinen Skalierungspunkt finden kann. Diese Option kann dazu führen, dass Aurora Serverless v1 Verbindungen unterbricht, die verhindern, dass es einen Skalierungspunkt findet.
1. Geben Sie im Feld **seconds** (Sekunden) die Zeit ein, die der Aurora Serverless v1-DB-Cluster vor dem Timeout nach einem Skalierungspunkt suchen soll. Sie können einen Wert zwischen 10 Sekunden und 600 Sekunden (10 Minuten) angeben. Der Standardwert beträgt fünf Minuten (300 Sekunden). Im folgenden Beispiel wird erzwungen, dass der Aurora Serverless v1-DB-Cluster auf 2 ACUs herunterskaliert, auch wenn er innerhalb von fünf Minuten keinen Skalierungspunkt finden kann.
![\[Festlegen der Kapazität für einen Aurora Serverless v1-DB-Cluster über die Konsole\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-serverless-set-capacity.png)
1. Wählen Sie **Apply (Anwenden)** aus.
Weitere Informationen zu Skalierungspunkten, `TimeoutAction` und Ruhephasen finden Sie unter [Automatische Skalierung für Aurora Serverless v1](aurora-serverless-v1.how-it-works.md#aurora-serverless.how-it-works.auto-scaling).
## AWS CLI
Um die Kapazität eines Aurora Serverless v1-DB-Clusters über die AWS CLI festzulegen, führen Sie den AWS CLI-Befehl [modify-current-db-cluster-capacity](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-current-db-cluster-capacity.html) aus und geben die Option `--capacity` an. Zu den gültigen Kapazitätswerten gehören die folgenden:
+ Aurora MySQL: `1`, `2`, `4`, `8`, `16`, `32`, `64`, `128` und `256`.
+ Aurora PostgreSQL: `2`, `4`, `8`, `16`, `32`, `64`, `192` und `384`.
In diesem Beispiel legen Sie die Kapazität eines Aurora Serverless v1-DB-Clusters namens *sample-cluster* auf *64* fest.
```
aws rds modify-current-db-cluster-capacity --db-cluster-identifier sample-cluster --capacity 64
```
## RDS-API
Sie können die Kapazität eines Aurora-DB-Clusters über die API-Operation [ModifyCurrentDBClusterCapacity](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyCurrentDBClusterCapacity.html) festlegen. Geben Sie den Parameter `Capacity` an. Zu den gültigen Kapazitätswerten gehören die folgenden:
+ Aurora MySQL: `1`, `2`, `4`, `8`, `16`, `32`, `64`, `128` und `256`.
+ Aurora PostgreSQL: `2`, `4`, `8`, `16`, `32`, `64`, `192` und `384`.
# Anzeigen von Aurora Serverless v1-DB-Clustern
**Wichtig**
AWS hat [das Ende der Nutzungsdauer für Aurora Serverless v1 bekannt gegeben: 31. März 2025](https://repost.aws/questions/QUhcMVoChXRm2HLi8F-yih1g/announcement-support-for-aurora-s/announcement-support-for-aurora-serverless-v1-ending-soon). Alle Aurora Serverless v1-Cluster, die bis zum 31. März 2025 nicht migriert wurden, werden während des Wartungsfensters zu Aurora Serverless v2 migriert. Wenn das Upgrade fehlschlägt, konvertiert Amazon Aurora den Serverless-v1-Cluster während des Wartungsfensters in einen bereitgestellten Cluster mit der entsprechenden Engine-Version. Falls zutreffend, registriert Amazon Aurora den konvertierten bereitgestellten Cluster bei Amazon RDS Extended Support. Weitere Informationen finden Sie unter [Amazon RDS Extended Support mit Amazon Aurora](extended-support.md).
Nachdem Sie einen oder mehrere Aurora Serverless v1-DB-Cluster erstellt haben, können Sie anzeigen, welche DB-Cluster den Typ **Serverless** (Serverlos) und welche den Typ **Instance** haben. Sie können auch die aktuelle Anzahl von Aurora Capacity Units (ACUs) einsehen, die jeder Aurora Serverless v1-DB-Cluster verwendet. Jede ACU ist eine Kombination aus Rechenkapazität (CPU) und Arbeitsspeicherkapazität (RAM).
**So zeigen Sie Ihre Aurora Serverless v1-DB-Cluster an:**
1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie oben rechts in der AWS-Managementkonsole die AWS-Region aus, in der Sie die Aurora Serverless v1-DB-Cluster erstellt haben.
1. Wählen Sie im Navigationsbereich **Databases (Datenbanken)** aus.
Der DB-Cluster-Typ für die einzelnen DB-Cluster wird unter **Role (Rolle)** angezeigt. Bei den Aurora Serverless v1-DB-Clustern wird **Serverless** (Serverlos) als Typ angezeigt. Sie können die aktuelle Kapazität eines Aurora Serverless v1-DB-Clusters unter **Size (Größe)** anzeigen.
![\[Anzeigen von Aurora Serverless v1-DB-Clustern\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-serverless-viewing.png)
1. Wählen Sie den Namen eines Aurora Serverless v1-DB-Clusters aus, um dessen Details anzuzeigen.
Beachten Sie auf der Registerkarte **Connectivity & security** (Konnektivität und Sicherheit) den Datenbankendpunkt. Verwenden Sie diesen Endpunkt, um eine Verbindung zu Ihrem Aurora Serverless v1-DB-Cluster herzustellen.
![\[Anzeigen des Datenbankendpunkts für Aurora Serverless v1-DB-Cluster\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-serverless-endpoint.png)
Wählen Sie die Registerkarte **Configuration** (Konfiguration) aus, um die Kapazitätseinstellungen anzuzeigen.
![\[Anzeigen der Kapazitätseinstellungen für Aurora Serverless v1-DB-Cluster\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-serverless-capacity-settings.png)
Wenn das DB-Cluster nach unten oder oben skaliert, pausiert oder fortgesetzt wird, wird ein *Skalierungsereignis* generiert. Wählen Sie die Registerkarte **Logs & events (Protokolle und Ereignisse)** aus, um aktuelle Ereignisse zu sehen. Die folgende Abbildung zeigt Beispiele für diese Ereignisse.
![\[Anzeigen der Kapazitätseinstellungen für Aurora Serverless v1-DB-Cluster\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-serverless-scaling.png)
## Überwachen der Kapazität und Skalieren von Ereignissen für den Aurora Serverless v1-DB-Cluster
Sie können Ihren Aurora Serverless v1-DB-Cluster in CloudWatch anzeigen, um die dem DB-Cluster zugewiesene Kapazität anhand der Metrik `ServerlessDatabaseCapacity` zu überwachen. Zusätzlich können Sie alle Aurora CloudWatch-Standardmetriken überwachen, wie z. B. `CPUUtilization`, `DatabaseConnections`, `Queries` usw.
Sie können veranlassen, dass Aurora einige oder alle Datenbankprotokolle in CloudWatch veröffentlicht. Sie bestimmen, welche Protokolle veröffentlicht werden sollen, indem Sie in der mit dem [`general_log`-Cluster verknüpften DB-Cluster-Parametergruppe Konfigurationsparameter](aurora-serverless-v1.how-it-works.md#aurora-serverless.parameter-groups) wie `slow_query_log` und Aurora Serverless v1 aktivieren. Anders als bei bereitgestellten Clustern müssen Sie bei Aurora Serverless v1-Clustern in den DB-Cluster-Einstellungen nicht angeben, welche Protokolltypen in CloudWatch hochgeladen werden sollen. Aurora Serverless v1-Cluster laden automatisch alle verfügbaren Protokolle hoch. Wenn Sie einen Protokollkonfigurationsparameter deaktivieren, stoppt die Veröffentlichung des Protokolls in CloudWatch. Sie können die Protokolle auch in CloudWatch löschen, wenn sie nicht mehr benötigt werden.
Erste Schritte mit Amazon CloudWatch für Ihren Aurora Serverless v1-DB-Cluster finden Sie unter [Aurora Serverless v1Logs mit Amazon anzeigen CloudWatch](aurora-serverless-v1.how-it-works.md#aurora-serverless.logging.monitoring). Weitere Informationen zur Überwachung von Aurora-DB-Clustern über CloudWatch finden Sie unter [Überwachung von Protokollereignissen in Amazon CloudWatch](AuroraMySQL.Integrating.CloudWatch.md#AuroraMySQL.Integrating.CloudWatch.Monitor).
Zum Verbinden eines Aurora Serverless v1-DB-Clusters verwenden Sie den Datenbankendpunkt. Weitere Informationen finden Sie unter [Herstellen einer Verbindung mit einem Amazon Aurora-DB-Cluster](Aurora.Connecting.md).
**Anmerkung**
Sie können in Aurora Serverless v1-DB-Clustern keine direkte Verbindung zu bestimmten DB-Instances herstellen.
# Löschen eines Aurora Serverless v1-DB-Clusters
**Wichtig**
AWS hat [das Ende der Nutzungsdauer für Aurora Serverless v1 bekannt gegeben: 31. März 2025](https://repost.aws/questions/QUhcMVoChXRm2HLi8F-yih1g/announcement-support-for-aurora-s/announcement-support-for-aurora-serverless-v1-ending-soon). Alle Aurora Serverless v1-Cluster, die bis zum 31. März 2025 nicht migriert wurden, werden während des Wartungsfensters zu Aurora Serverless v2 migriert. Wenn das Upgrade fehlschlägt, konvertiert Amazon Aurora den Serverless-v1-Cluster während des Wartungsfensters in einen bereitgestellten Cluster mit der entsprechenden Engine-Version. Falls zutreffend, registriert Amazon Aurora den konvertierten bereitgestellten Cluster bei Amazon RDS Extended Support. Weitere Informationen finden Sie unter [Amazon RDS Extended Support mit Amazon Aurora](extended-support.md).
Je nachdem, wie Sie einen Aurora Serverless v1-DB-Cluster erstellen, ist der Löschschutz möglicherweise standardmäßig aktiviert. Sie können einen Aurora Serverless v1-DB-Cluster, für den **Löschschutz** aktiviert ist, nicht sofort löschen. Um Aurora Serverless v1-DB-Cluster mit Löschschutz über die AWS-Managementkonsole zu löschen, bearbeiten Sie zuerst den Cluster, um diesen Schutz zu entfernen. Informationen zur Verwendung der AWS CLI für diese Aufgabe finden Sie unter [AWS CLI](#aurora-serverless.delete.cli).
**So deaktivieren Sie den Löschschutz mithilfe der AWS-Managementkonsole**
1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Klicken Sie im Navigationsbereich auf **DB clusters** (DB-Cluster).
1. Wählen Sie Ihren Aurora Serverless v1-DB-Cluster in der Liste aus.
1. Wählen Sie **Modify** (Ändern), um die Konfiguration des DB-Clusters zu öffnen. Auf der Seite "DB-Cluster ändern" werden die Einstellungen, Kapazitätseinstellungen und andere Konfigurationsdetails für Ihren Aurora Serverless v1-DB-Cluster geöffnet. Den Löschschutz finden Sie im Bereich **Additional configuration** (Zusätzliche Konfiguration).
1. Deaktivieren Sie das Kontrollkästchen **Enable deletion protection** (Löschschutz aktivieren) auf der Eigenschaftenkarte **Additional configuration** (Zusätzliche Konfiguration).
1. Klicken Sie auf **Weiter**. **Summary of modifications** (Zusammenfassung der Änderungen) wird angezeigt.
1. 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.
Nachdem der Löschschutz nicht mehr aktiv ist, können Sie Ihren Aurora Serverless v1-DB-Cluster über die AWS-Managementkonsole löschen.
## Konsole
**So löschen Sie einen Aurora Serverless v1-DB-Cluster:**
1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie im Bereich **Resources** (Ressourcen) die Option **DB Clusters** (DB-Cluster) aus.
1. Wählen Sie den Aurora Serverless v1-DB-Cluster aus, den Sie löschen möchten.
1. Klicken Sie bei ** Actions** auf **Delete**. Sie werden aufgefordert, zu bestätigen, dass Sie den Aurora Serverless v1-DB-Cluster löschen möchten.
1. Sie sollten die vorausgewählten Optionen beibehalten:
+ **Yes** (Ja) bei **Create final snapshot?** (Finalen Snapshot erstellen?)
+ Ihr Aurora Serverless v1-DB-Cluster-Name sowie `-final-snapshot` für **Final snapshot name** (Name des finalen Snapshots). Sie können jedoch den Namen für Ihren finalen Snapshot in diesem Feld ändern.
![\[Screenshot zum Löschen des Aurora Serverless v1-Datenbank-Clusters\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-sles-delete-db-1.png)
Wenn Sie bei **Create final snapshot?** (Finalen Snapshot erstellen?) **No** (Nein) wählen, können Sie Ihren DB-Cluster nicht mit Snapshots oder zeitpunktbezogener Wiederherstellung wiederherstellen.
1. Wählen Sie **Delete DB cluster** (DB-Cluster löschen) aus.
Aurora Serverless v1 löscht Ihren DB-Cluster. Wenn Sie sich für einen finalen Snapshot entschieden haben, wird der Status Ihres Aurora Serverless v1-DB-Clusters zu "Backing-up" (Wird gesichert) geändert, bevor er gelöscht wird und nicht mehr in der Liste erscheint.
## AWS CLI
Bevor Sie beginnen, konfigurieren Sie Ihre AWS CLI mit Ihrer AWS-Zugriffsschlüssel-ID, dem geheimen AWS-Zugriffsschlüssel und der AWS-Region, in der sich Ihr Aurora Serverless v1-DB-Cluster befindet. Weitere Informationen finden Sie unter [Konfigurationsgrundlagen](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) im AWS Command Line Interface-Benutzerhandbuch.
Sie können einen Aurora Serverless v1-DB-Cluster erst löschen, nachdem Sie für Cluster, die mit dieser Option konfiguriert sind, den Löschschutz deaktiviert haben. Wenn Sie versuchen, einen Cluster zu löschen, bei dem diese Schutzoption aktiviert ist, wird die folgende Fehlermeldung angezeigt.
```
1. An error occurred (InvalidParameterCombination) when calling the DeleteDBCluster
2. operation: Cannot delete protected Cluster, please disable deletion protection and try again.
```
Sie können die Löschschutzeinstellung Ihres Aurora Serverless v1-DB-Clusters ändern, indem Sie den AWS CLI-Befehl [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) verwenden, wie im Folgenden dargestellt:
```
aws rds modify-db-cluster --db-cluster-identifier your-cluster-name --no-deletion-protection
```
Dieser Befehl liefert die überarbeiteten Eigenschaften für den angegebenen DB-Cluster. Jetzt können Sie den Aurora Serverless v1-DB-Cluster löschen.
Es empfiehlt sich, immer einen finalen Snapshot zu erstellen, wenn Sie einen Aurora Serverless v1-DB-Cluster löschen. Im folgenden Beispiel zur Verwendung der AWS CLI mit [delete-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/delete-db-cluster.html) wird die Vorgehensweise gezeigt. Sie geben den Namen Ihres DB-Clusters und einen Namen für den Snapshot an.
Für Linux, macOS oder Unix:
```
aws rds delete-db-cluster --db-cluster-identifier \
your-cluster-name --no-skip-final-snapshot \
--final-db-snapshot-identifier name-your-snapshot
```
Für Windows:
```
aws rds delete-db-cluster --db-cluster-identifier ^
your-cluster-name --no-skip-final-snapshot ^
--final-db-snapshot-identifier name-your-snapshot
```
# Aurora Serverless v1- und Aurora-Datenbank-Engine-Versionen
**Wichtig**
AWS hat [den end-of-life Termin bekannt gegeben fürAurora Serverless v1: 31. März 2025](https://repost.aws/questions/QUhcMVoChXRm2HLi8F-yih1g/announcement-support-for-aurora-s/announcement-support-for-aurora-serverless-v1-ending-soon). Alle Aurora Serverless v1-Cluster, die bis zum 31. März 2025 nicht migriert wurden, werden während des Wartungsfensters zu Aurora Serverless v2 migriert. Wenn das Upgrade fehlschlägt, konvertiert Amazon Aurora den Serverless-v1-Cluster während des Wartungsfensters in einen bereitgestellten Cluster mit der entsprechenden Engine-Version. Falls zutreffend, registriert Amazon Aurora den konvertierten bereitgestellten Cluster bei Amazon RDS Extended Support. Weitere Informationen finden Sie unter [Amazon RDS Extended Support mit Amazon Aurora](extended-support.md).
Aurora Serverless v1ist nur in bestimmten Versionen AWS-Regionen und nur für bestimmte Aurora MySQL- und Aurora PostgreSQL-Versionen verfügbar. Eine aktuelle Liste AWS-Regionen dieser Unterstützung Aurora Serverless v1 und der spezifischen Versionen von Aurora MySQL und Aurora PostgreSQL, die in jeder Region verfügbar sind, finden Sie unter. [Aurora Serverless v1](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV1.md)
Aurora Serverless v1 verwendet die zugehörige Aurora-Datenbank-Engine, um spezifische unterstützte Versionen für jede unterstützte Datenbank-Engine zu ermitteln:
+ Aurora MySQL Serverless
+ Aurora PostgreSQL Serverless
Wenn Nebenversionen der Datenbank-Engines für Aurora Serverless v1 verfügbar werden, werden sie automatisch in den verschiedenen AWS-Regionen angewendet, in denen Aurora Serverless v1 verfügbar ist. Mit anderen Worten, Sie müssen Ihren Aurora Serverless v1-DB-Cluster nicht aktualisieren, um eine neue Nebenversion für die DB-Engine Ihres Clusters zu erhalten, wenn sie für Aurora Serverless v1 verfügbar ist.
## Aurora MySQL Serverless
Aurora Serverless v1ist nur in bestimmten AWS-Regionen und für bestimmte Aurora MySQL-Versionen verfügbar. Eine aktuelle Liste AWS-Regionen dieser Unterstützung Aurora Serverless v1 und der spezifischen Aurora MySQL-Versionen, die in jeder Region verfügbar sind, finden Sie unter[Aurora Serverless v1 mit Aurora MySQL](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV1.md#Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV1.amy).
Weitere Informationen zu Verbesserungen und Bugfixes für Aurora MySQL Version 2 finden Sie unter [Aktualisierungen der Datenbank-Engine für Amazon Aurora MySQL Version 2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.Updates.20Updates.html) in den *Versionshinweisen für Aurora MySQL*.
Um eine neuere Version von Aurora MySQL zu verwenden, können Sie Aurora Serverless v2 verwenden. Informationen zu den MySQL-Versionen AWS-Regionen und Aurora, die Sie mit verwenden könnenAurora Serverless v2, finden Sie unter[Aurora Serverless v2 mit Aurora MySQL](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.md#Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.amy). Weitere Informationen zur Verwendung von Aurora Serverless v2 finden Sie unter [Verwenden von Aurora Serverless v2](aurora-serverless-v2.md).
## Aurora PostgreSQL Serverless
Aurora Serverless v1ist nur in bestimmten AWS-Regionen und für bestimmte Aurora PostgreSQL-Versionen verfügbar. Eine aktuelle Liste AWS-Regionen dieser Unterstützung Aurora Serverless v1 und der spezifischen Aurora PostgreSQL-Versionen, die in jeder Region verfügbar sind, finden Sie unter. [Aurora Serverless v1 mit Aurora PostgreSQL](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV1.md#Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV1.apg)
Wenn Sie Aurora PostgreSQL für Ihren Aurora Serverless v1-DB-Cluster nutzen möchten, können Sie die mit Aurora PostgreSQL 13 kompatiblen Versionen verwenden. Nebenversionen für Aurora PostgreSQL-kompatible Edition enthalten nur Änderungen, die abwärtskompatibel sind. Ihr DB-Cluster von Aurora Serverless v1 wird transparent aktualisiert, wenn eine Aurora-PostgreSQL-Nebenversion für Aurora Serverless v1 in Ihrer AWS-Region verfügbar wird.
Um eine neuere Version von Aurora PostgreSQL zu nutzen, können Sie Aurora Serverless v2 verwenden. Informationen zu den Versionen AWS-Regionen und Aurora PostgreSQL, die Sie mit verwenden könnenAurora Serverless v2, finden Sie unter. [Aurora Serverless v2 mit Aurora PostgreSQL](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.md#Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.apg) Weitere Informationen zur Verwendung von Aurora Serverless v2 finden Sie unter [Verwenden von Aurora Serverless v2](aurora-serverless-v2.md).
## Automatische Unterversion-Upgrades für Aurora Serverless v1
Wenn kleinere Versionen der Datenbank-Engines verfügbar sindAurora Serverless v1, werden sie automatisch auf die verschiedenen AWS-Regionen verfügbaren Versionen angewendet. Aurora Serverless v1 Mit anderen Worten, Sie müssen Ihren Aurora Serverless v1-DB-Cluster nicht aktualisieren, um eine neue Nebenversion für die DB-Engine Ihres Clusters zu erhalten, wenn sie für Aurora Serverless v1 verfügbar ist.