Migration zu Aurora Serverless v2

Konvertieren Sie einen vorhandenen DB-Cluster zur Verwendung von Aurora Serverless v2 wie folgt:

• Aktualisieren Sie von einem bereitgestellten Aurora-DB-Cluster aus.

• Aktualisieren Sie von einem Aurora Serverless v1-Cluster aus.

• Migration von einer On-Premises-Datenbank zu einem Aurora Serverless v2-Cluster.

Wenn auf Ihrem aktualisierten Cluster die entsprechende Engine-Version ausgeführt wird, wie unter Anforderungen und Einschränkungen für Aurora Serverless v2 aufgeführt, können Sie mit dem Hinzufügen der Aurora Serverless v2-DB-Instances beginnen. Die erste DB-Instance, die Sie dem aktualisierten Cluster hinzufügen, muss eine bereitgestellte DB-Instance sein. Dann können Sie die Verarbeitung für die Schreib-Workload, die Lese-Workload oder beides auf die Aurora Serverless v2DB-Instances umstellen.

Inhalt

• Aktualisieren oder Umstellen vorhandener Cluster auf die Verwendung von Aurora Serverless v2
  • Upgrade-Pfade für MySQL-kompatible Cluster zur Verwendung von Aurora Serverless v2
  • Upgrade-Pfade für PostgreSQL-kompatible Cluster zur Verwendung von Aurora Serverless v2
• Umstellung von einem bereitgestellten Cluster zu Aurora Serverless v2
• Aurora Serverless v2 und Aurora Serverless v1 im Vergleich
  • Aurora Serverless v2- und Aurora Serverless v1-Anforderungen im Vergleich
  • Skalierung und Verfügbarkeit von Aurora Serverless v2 und Aurora Serverless v1 im Vergleich
  • Funktionsunterstützung von Aurora Serverless v2 und Aurora Serverless v1 im Vergleich
  • Anpassen von Aurora Serverless v1-Anwendungsfälle an Aurora Serverless v2
• Aktualisieren eines Aurora Serverless v1-Clusters auf Aurora Serverless v2
  • Mit Aurora MySQL kompatible DB-Cluster
  • Mit Aurora PostgreSQL kompatible DB-Cluster
• Migrieren einer On-Premises-Datenbank zu Aurora Serverless v2

Anmerkung

In diesen Themen wird beschrieben, wie ein vorhandener DB-Cluster konvertiert wird. Weitere Informationen zum Erstellen eines neuen DB-Clusters von Aurora Serverless v2 finden Sie unter Erstellen eines DB-Clusters, das Aurora Serverless v2.

Aktualisieren oder Umstellen vorhandener Cluster auf die Verwendung von Aurora Serverless v2

Wenn Ihr bereitgestellter Cluster über eine Engine-Version verfügt, die Aurora Serverless v2 unterstützt, ist für die Umstellung auf Aurora Serverless v2 kein Upgrade erforderlich. In diesem Fall können Sie Ihrem ursprünglichen Aurora Serverless v2-DB-Instances Cluster hinzufügen. Sie können den Cluster umstellen, um alle Aurora Serverless v2-DB-Instances zu verwenden. Sie können auch eine Kombination aus Aurora Serverless v2 und bereitgestellten DB-Instances im selben DB-Cluster verwenden. Die Aurora-Engine-Versionen, die Aurora Serverless v2 unterstützen, finden Sie unter Unterstützte Regionen und Aurora-DB-Engines für Aurora Serverless v2.

Wenn Sie eine niedrigere Engine-Version ausführen, die Aurora Serverless v2 nicht unterstützt, führen Sie diese allgemeinen Schritte aus:

1. Aktualisieren Sie den Cluster.

2. Erstellen Sie eine bereitgestellte Writer-DB-Instance für den aktualisierten Cluster.

3. Ändern Sie den Cluster, sodass er Aurora Serverless v2-DB-Instances verwendet.

Wichtig

Wenn Sie ein größeres Versions-Upgrade auf eine Aurora Serverless v2-kompatible Version unter Verwendung von Snapshot-Wiederherstellung oder -Klonen durchführen, muss die erste DB-Instance, die Sie dem neuen Cluster hinzufügen, eine bereitgestellte DB-Instance sein. Dieser Hinzufügevorgang startet die letzte Phase des Upgrade-Prozesses.

Bis zu dieser letzten Phase verfügt der Cluster nicht über die Infrastruktur, die für die Unterstützung von Aurora Serverless v2 erforderlich ist. Daher beginnen diese aktualisierten Cluster immer mit einer bereitgestellten Writer-DB-Instance. Dann können Sie die bereitgestellte DB-Instance in eine Aurora Serverless v2-Instance konvertieren oder ein entsprechendes Failover durchführen.

Das Aktualisieren von Aurora Serverless v1 auf Aurora Serverless v2 umfasst das Erstellen eines bereitgestellten Clusters als Zwischenschritt. Anschließend führen Sie dieselben Upgrade-Schritte aus wie beim Start mit einem bereitgestellten Cluster.

Upgrade-Pfade für MySQL-kompatible Cluster zur Verwendung von Aurora Serverless v2

Wenn auf Ihrem ursprünglichen Cluster Aurora MySQL ausgeführt wird, wählen Sie je nach Engine-Version und Engine-Modus Ihres Clusters das entsprechende Verfahren aus.

Wenn Ihr ursprünglicher Aurora-MySQL-Cluster dieser ist	Gehen Sie wie folgt vor, um auf Aurora Serverless v2 umzustellen.
Bereitgestellter Cluster mit Aurora MySQL Version 3, kompatibel mit MySQL 8.0	Dies ist die letzte Phase für alle Konvertierungen aus bestehenden Aurora-MySQL-Clustern. Führen Sie ggf. ein Nebenversions-Upgrade auf Version 3.02.0 oder höher durch. Verwenden Sie eine bereitgestellte DB-Instance für die Writer-DB-Instance. Fügen Sie eine Aurora Serverless v2-Reader-DB-Instance hinzu. Führen Sie ein Failover durch, um diese zur Writer-DB-Instance hochzustufen. (Optional) Konvertieren Sie andere bereitgestellte DB-Instances im Cluster in Aurora Serverless v2. Oder fügen Sie neue DB-Instances von Aurora Serverless v2 hinzu und entfernen Sie die bereitgestellten DB-Instances. Das vollständige Verfahren und Beispiele finden Sie unter Umstellung von einem bereitgestellten Cluster zu Aurora Serverless v2.
Bereitgestellter Cluster mit Aurora MySQL Version 2, kompatibel mit MySQL 5.7	Führen Sie ein Hauptversions-Upgrade auf Aurora MySQL Version 3.02.0 oder höher durch. Befolgen Sie dann die Vorgehensweise für Aurora-MySQL-Version 3, um den Cluster auf die Verwendung von Aurora Serverless v2-DB-Instances umzustellen.
Aurora Serverless v1-Cluster mit Aurora MySQL Version 2, kompatibel mit MySQL 5.7	Hilfestellung zur Planung Ihrer Konvertierung von Aurora Serverless v1 finden Sie unter Aurora Serverless v2 und Aurora Serverless v1 im Vergleich. Folgen Sie dann dem Verfahren unter Aktualisieren eines Aurora Serverless v1-Clusters auf Aurora Serverless v2.

Upgrade-Pfade für PostgreSQL-kompatible Cluster zur Verwendung von Aurora Serverless v2

Wenn auf Ihrem ursprünglichen Cluster Aurora PostgreSQL ausgeführt wird, wählen Sie je nach Engine-Version und Engine-Modus Ihres Clusters das entsprechende Verfahren aus.

Wenn Ihr ursprünglicher Aurora-PostgreSQL-Cluster dieser ist	Gehen Sie wie folgt vor, um auf Aurora Serverless v2 umzustellen.
Bereitgestellter Cluster, auf dem Aurora-PostgreSQL-Version 13 ausgeführt wird	Dies ist die letzte Phase für alle Konvertierungen aus bestehenden Aurora-PostgreSQL-Clustern. Führen Sie ggf. ein Nebenversions-Upgrade auf Version 13.6 oder höher durch. Fügen Sie eine bereitgestellte DB-Instance für die Writer-DB-Instance hinzu. Fügen Sie eine Aurora Serverless v2-Reader-DB-Instance hinzu. Führen Sie ein Failover aus, damit diese Aurora Serverless v2-Instance zur Writer-DB-Instance wird. (Optional) Konvertieren Sie andere bereitgestellte DB-Instances im Cluster zu Aurora Serverless v2. Oder fügen Sie neue DB-Instances von Aurora Serverless v2 hinzu und entfernen Sie die bereitgestellten DB-Instances. Das vollständige Verfahren und Beispiele finden Sie unter Umstellung von einem bereitgestellten Cluster zu Aurora Serverless v2.
Bereitgestellter Cluster mit Aurora PostgreSQL Version 11 oder 12	Führen Sie ein Hauptversions-Upgrade auf Aurora PostgreSQL Version 13.6 oder höher durch. Befolgen Sie dann die Vorgehensweise für Aurora PostgreSQL Version 13, um den Cluster auf die Verwendung von Aurora Serverless v2-DB-Instances umzustellen.
Aurora Serverless v1-Cluster, auf dem Aurora PostgreSQL Version 11 oder 13 ausgeführt wird	Hilfestellung zur Planung Ihrer Konvertierung von Aurora Serverless v1 finden Sie unter Aurora Serverless v2 und Aurora Serverless v1 im Vergleich. Folgen Sie dann dem Verfahren unter Aktualisieren eines Aurora Serverless v1-Clusters auf Aurora Serverless v2.

Umstellung von einem bereitgestellten Cluster zu Aurora Serverless v2

Stellen Sie einen bereitgestellten Cluster wie folgt auf die Verwendung von Aurora Serverless v2 um:

1. Prüfen Sie, ob der bereitgestellte Cluster aktualisiert werden muss, um mit Aurora Serverless v2-DB-Instances verwendet werden zu können. Die Aurora-Versionen, die mit Aurora Serverless v2 kompatibel sind, finden Sie unter Anforderungen und Einschränkungen für Aurora Serverless v2.

   Wenn auf dem bereitgestellten Cluster eine Engine-Version ausgeführt wird, die für Aurora Serverless v2 nicht verfügbar ist, aktualisieren Sie die Engine-Version des Clusters:

   • Wenn Sie einen mit MySQL 5.7 kompatiblen bereitgestellten Cluster vorliegen haben, befolgen Sie die Upgrade-Anweisungen für Aurora MySQL Version 3. Verwenden Sie die Verfahren in Erläuterung der Durchführung eines direkten Upgrades.

   • Wenn Sie einen mit PostgreSQL kompatiblen bereitgestellten Cluster vorliegen haben, auf dem PostgreSQL Version 11 oder 12 ausgeführt wird, befolgen Sie die Upgrade-Anweisungen für Aurora PostgreSQL Version 13. Verwenden Sie die Verfahren in Durchführen eines Hauptversions-Upgrades.

2. Konfigurieren Sie alle anderen Cluster-Eigenschaften so, dass sie den Aurora Serverless v2-Anforderungen von Anforderungen und Einschränkungen für Aurora Serverless v2 entsprechen.

3. Konfigurieren Sie die Skalierungskonfiguration für den Cluster. Folgen Sie dem Verfahren unter Festlegen des Aurora Serverless v2-Kapazitätsbereichs für einen Cluster.

4. Fügen Sie dem Cluster eine oder mehrere Aurora Serverless v2-DB-Instances hinzu. Gehen Sie vor, wie im allgemeinen Verfahren unter Hinzufügen von Aurora-Replicas zu einem DB-Cluster beschrieben. Geben Sie für jede neue DB-Instance den speziellen DB-Instance-Klassennamen Serverless in der AWS Management Console oder AWS CLI oder db.serverless der Amazon RDS-API an.

   In einigen Fällen sind möglicherweise bereits eine oder mehrere bereitgestellte Reader-DB-Instances im Cluster vorhanden. Wenn dies der Fall ist, können Sie einen der Reader in eine Aurora Serverless v2-DB-Instance konvertieren, anstatt eine neue DB-Instance zu erstellen. Eine Schritt-für-Schritt-Anleitung hierzu finden Sie unter Konvertieren eines bereitgestellten Writers oder Readers in Aurora Serverless v2.

5. Führen Sie einen Failover-Vorgang aus, damit eine der Aurora Serverless v2-DB-Instances zur Writer-DB-Instance für den Cluster wird.

6. (Optional) Konvertieren Sie alle bereitgestellten DB-Instances in Aurora Serverless v2 oder entfernen Sie sie aus dem Cluster. Gehen Sie vor, wie im allgemeinen Verfahren unter Konvertieren eines bereitgestellten Writers oder Readers in Aurora Serverless v2 oder Löschen einer DB-Instance aus einem Aurora-DB-Cluster beschrieben.

   Tipp

   Das Entfernen der bereitgestellten DB-Instances ist nicht zwingend erforderlich. Sie können einen Cluster einrichten, der sowohl Aurora Serverless v2 als auch bereitgestellte DB-Instances enthält. Bevor Sie jedoch mit den Leistungs- und Skalierungsmerkmalen von Aurora Serverless v2-DB-Instances vertraut sind, empfehlen wir Ihnen, Ihre Cluster mit DB-Instances desselben Typs zu konfigurieren.

Das folgende AWS CLI Beispiel zeigt den Switchover-Prozess unter Verwendung eines bereitgestellten Clusters, auf dem Aurora MySQL Version 3.02.0 ausgeführt wird. Der Cluster heißt mysql-80. Der Cluster beginnt mit zwei bereitgestellten DB-Instances namens provisioned-instance-1 und provisioned-instance-2, ein Writer und ein Reader. Beide verwenden die db.r6g.large-DB-Instance-Klasse.

$ aws rds describe-db-clusters --db-cluster-identifier mysql-80 \
  --query '*[].[DBClusterIdentifier,DBClusterMembers[*].[DBInstanceIdentifier,IsClusterWriter]]' --output text
mysql-80
provisioned-instance-2     False
provisioned-instance-1     True

$ aws rds describe-db-instances --db-instance-identifier provisioned-instance-1 \
  --output text --query '*[].[DBInstanceIdentifier,DBInstanceClass]'
provisioned-instance-1     db.r6g.large

$ aws rds describe-db-instances --db-instance-identifier provisioned-instance-2 \
  --output text --query '*[].[DBInstanceIdentifier,DBInstanceClass]'
provisioned-instance-2     db.r6g.large

Wir erstellen eine Tabelle mit einigen Daten. Auf diese Weise können wir bestätigen, dass die Daten und der Betrieb des Clusters vor und nach der Umstellung gleich sind.

mysql> create database serverless_v2_demo;
mysql> create table serverless_v2_demo.demo (s varchar(128));
mysql> insert into serverless_v2_demo.demo values ('This cluster started with a provisioned writer.');
Query OK, 1 row affected (0.02 sec)

Zunächst fügen wir dem Cluster einen Kapazitätsbereich hinzu. Andernfalls erhalten wir einen Fehler beim Hinzufügen von Aurora Serverless v2-DB-Instances zum Cluster. Wenn wir das AWS Management Console für dieses Verfahren verwenden, erfolgt dieser Schritt automatisch, wenn wir die erste Aurora Serverless v2 DB-Instance hinzufügen.

$ aws rds create-db-instance --db-instance-identifier serverless-v2-instance-1 \
  --db-cluster-identifier mysql-80 --db-instance-class db.serverless --engine aurora-mysql

An error occurred (InvalidDBClusterStateFault) when calling the CreateDBInstance operation:
Set the Serverless v2 scaling configuration on the parent DB cluster before creating a Serverless v2 DB instance.

$ # The blank ServerlessV2ScalingConfiguration attribute confirms that the cluster doesn't have a capacity range set yet.
$ aws rds describe-db-clusters --db-cluster-identifier mysql-80 --query 'DBClusters[*].ServerlessV2ScalingConfiguration'
[]

$ aws rds modify-db-cluster --db-cluster-identifier mysql-80 \
  --serverless-v2-scaling-configuration MinCapacity=0.5,MaxCapacity=16
{
  "DBClusterIdentifier": "mysql-80",
  "ServerlessV2ScalingConfiguration": {
    "MinCapacity": 0.5,
    "MaxCapacity": 16
  }
}

Wir erstellen zwei Reader von Aurora Serverless v2, die an die Stelle der ursprünglichen DB-Instances treten. Dazu geben wir die db.serverless-DB-Instance-Klasse für die neuen DB-Instances an.

$ aws rds create-db-instance --db-instance-identifier serverless-v2-instance-1 --db-cluster-identifier mysql-80 --db-instance-class db.serverless --engine aurora-mysql
{
  "DBInstanceIdentifier": "serverless-v2-instance-1",
  "DBClusterIdentifier": "mysql-80",
  "DBInstanceClass": "db.serverless",
  "DBInstanceStatus": "creating"
}

$ aws rds create-db-instance --db-instance-identifier serverless-v2-instance-2 \
  --db-cluster-identifier mysql-80 --db-instance-class db.serverless --engine aurora-mysql
{
  "DBInstanceIdentifier": "serverless-v2-instance-2",
  "DBClusterIdentifier": "mysql-80",
  "DBInstanceClass": "db.serverless",
  "DBInstanceStatus": "creating"
}

$ # Wait for both DB instances to finish being created before proceeding.
$ aws rds wait db-instance-available --db-instance-identifier serverless-v2-instance-1 && \
  aws rds wait db-instance-available --db-instance-identifier serverless-v2-instance-2

Wir führen einen Failover-Vorgang aus, damit eine der Aurora Serverless v2-DB-Instances zur Writer-DB-Instance für den Cluster wird.

$ aws rds failover-db-cluster --db-cluster-identifier mysql-80 \
  --target-db-instance-identifier serverless-v2-instance-1
{
  "DBClusterIdentifier": "mysql-80",
  "DBClusterMembers": [
    {
      "DBInstanceIdentifier": "serverless-v2-instance-1",
      "IsClusterWriter": false,
      "DBClusterParameterGroupStatus": "in-sync",
      "PromotionTier": 1
    },
    {
      "DBInstanceIdentifier": "serverless-v2-instance-2",
      "IsClusterWriter": false,
      "DBClusterParameterGroupStatus": "in-sync",
      "PromotionTier": 1
    },
    {
      "DBInstanceIdentifier": "provisioned-instance-2",
      "IsClusterWriter": false,
      "DBClusterParameterGroupStatus": "in-sync",
      "PromotionTier": 1
    },
    {
      "DBInstanceIdentifier": "provisioned-instance-1",
      "IsClusterWriter": true,
      "DBClusterParameterGroupStatus": "in-sync",
      "PromotionTier": 1
    }
  ],
  "Status": "available"
}

Es dauert einige Sekunden, bis diese Änderung wirksam wird. Zu diesem Zeitpunkt verfügen wir über einen Aurora Serverless v2-Writer und einen Aurora Serverless v2-Reader. Daher benötigen wir keine der ursprünglich bereitgestellten DB-Instances.

$ aws rds describe-db-clusters --db-cluster-identifier mysql-80 \
  --query '*[].[DBClusterIdentifier,DBClusterMembers[*].[DBInstanceIdentifier,IsClusterWriter]]' \
  --output text
mysql-80
serverless-v2-instance-1        True
serverless-v2-instance-2        False
provisioned-instance-2          False
provisioned-instance-1          False

Der letzte Schritt im Umstellungsverfahren besteht darin, beide bereitgestellten DB-Instances zu löschen.

$ aws rds delete-db-instance --db-instance-identifier provisioned-instance-2 --skip-final-snapshot
{
  "DBInstanceIdentifier": "provisioned-instance-2",
  "DBInstanceStatus": "deleting",
  "Engine": "aurora-mysql",
  "EngineVersion": "8.0.mysql_aurora.3.02.0",
  "DBInstanceClass": "db.r6g.large"
}

$ aws rds delete-db-instance --db-instance-identifier provisioned-instance-1 --skip-final-snapshot
{
  "DBInstanceIdentifier": "provisioned-instance-1",
  "DBInstanceStatus": "deleting",
  "Engine": "aurora-mysql",
  "EngineVersion": "8.0.mysql_aurora.3.02.0",
  "DBInstanceClass": "db.r6g.large"
}

Abschließend bestätigen wir zur Überprüfung, dass die ursprüngliche Tabelle von der Aurora Serverless v2-Writer-DB-Instance aus zugänglich und beschreibbar ist.

mysql> select * from serverless_v2_demo.demo;
+---------------------------------------------------+
| s                                                 |
+---------------------------------------------------+
| This cluster started with a provisioned writer.   |
+---------------------------------------------------+
1 row in set (0.00 sec)

mysql> insert into serverless_v2_demo.demo values ('And it finished with a Serverless v2 writer.');
Query OK, 1 row affected (0.01 sec)

mysql> select * from serverless_v2_demo.demo;
+---------------------------------------------------+
| s                                                 |
+---------------------------------------------------+
| This cluster started with a provisioned writer.   |
| And it finished with a Serverless v2 writer.      |
+---------------------------------------------------+
2 rows in set (0.01 sec)

Wir stellen außerdem eine Verbindung mit der Aurora Serverless v2-Reader-DB-Instance her und bestätigen, dass die neu geschriebenen Daten dort auch verfügbar sind.

mysql> select * from serverless_v2_demo.demo;
+---------------------------------------------------+
| s                                                 |
+---------------------------------------------------+
| This cluster started with a provisioned writer.   |
| And it finished with a Serverless v2 writer.      |
+---------------------------------------------------+
2 rows in set (0.01 sec)

Aurora Serverless v2 und Aurora Serverless v1 im Vergleich

Wenn Sie Aurora Serverless v1 bereits verwenden, können Sie sich mit den Hauptunterschieden zwischen Aurora Serverless v1 und Aurora Serverless v2 vertraut machen. Die architektonischen Unterschiede, wie die Unterstützung für Reader-DB-Instances, eröffnen neue Arten von Anwendungsfällen.

Sie können die folgenden Tabellen verwenden, um die wichtigsten Unterschiede zwischen Aurora Serverless v2 und Aurora Serverless v1besser zu verstehen.

Themen

• Aurora Serverless v2- und Aurora Serverless v1-Anforderungen im Vergleich
• Skalierung und Verfügbarkeit von Aurora Serverless v2 und Aurora Serverless v1 im Vergleich
• Funktionsunterstützung von Aurora Serverless v2 und Aurora Serverless v1 im Vergleich
• Anpassen von Aurora Serverless v1-Anwendungsfälle an Aurora Serverless v2

Aurora Serverless v2- und Aurora Serverless v1-Anforderungen im Vergleich

Die folgende Tabelle fasst die verschiedenen Anforderungen zum Ausführen Ihrer Datenbank mit Aurora Serverless v2 oder Aurora Serverless v1 zusammen. Aurora Serverless v2 bietet höhere Versionen der Aurora-MySQL- und Aurora-PostgreSQL-DB-Engines als Aurora Serverless v1.

Funktion	Anforderung von Aurora Serverless v2	Anforderung von Aurora Serverless v1
DB-Engines	Aurora MySQL, Aurora PostgreSQL	Aurora MySQL, Aurora PostgreSQL
Unterstützte Aurora-MySQL-Versionen	Siehe Aurora Serverless v2 mit Aurora MySQL.	Siehe Aurora Serverless v1 mit Aurora MySQL.
Unterstützte Aurora-PostgreSQL-Versionen	Siehe Aurora Serverless v2 mit Aurora PostgreSQL.	Siehe Aurora Serverless v1 mit Aurora PostgreSQL.
Upgraden eines DB-Clusters	Ähnlich wie bei bereitgestellten DB-Clustern können Sie Upgrades manuell durchführen, ohne darauf zu warten, dass Aurora den DB-Cluster für Sie aktualisiert. Weitere Informationen finden Sie unter Ändern eines Amazon Aurora-DB-Clusters. Anmerkung Um ein Hauptversions-Upgrade von 13.x auf 14.x oder 15.x für einen mit Aurora PostgreSQL kompatiblen DB-Cluster durchzuführen, muss die maximale Kapazität des Clusters mindestens 2 ACUs betragen.	Nebenversions-Upgrades werden automatisch angewendet, sobald sie verfügbar sind. Weitere Informationen finden Sie unter Aurora Serverless v1- und Aurora-Datenbank-Engine-Versionen. Sie können Hauptversions-Upgrades manuell durchführen. Weitere Informationen finden Sie unter Ändern eines Aurora Serverless v1-DB-Clusters.
Konvertieren von bereitgestellten Clustern aus	Sie können die folgenden Methoden verwenden: Fügen Sie einem vorhandenen bereitgestellten Cluster eine oder mehrere Aurora Serverless v2-Reader DB-Instances hinzu. Wenn Sie Aurora Serverless v2 für den Writer verwenden möchten, führen Sie ein Failover auf eine der Aurora Serverless v2-DB-Instances durch. Damit der gesamte Cluster Aurora Serverless v2 verwendet, entfernen Sie alle bereitgestellten Writer-DB-Instances, nachdem Sie die Aurora Serverless v2-DB-Instance zum Writer hochgestuft haben. Erstellen Sie ein neues Cluster mit der entsprechenden DB-Engine und Engine-Version. Verwenden Sie eine der Standardmethoden. Stellen Sie beispielsweise einen Cluster-Snapshot wieder her oder erstellen Sie einen Klon eines vorhandenen Clusters. Wählen Sie Aurora Serverless v2 für einige oder alle DB-Instances im neuen Cluster. Wenn Sie den neuen Cluster durch Klonen erstellen, können Sie die Engine-Version nicht gleichzeitig aktualisieren. Stellen Sie sicher, dass auf dem ursprünglichen Cluster bereits eine Engine-Version ausgeführt wird, die mit Aurora Serverless v2 kompatibel ist.	Stellen Sie den Snapshot des bereitgestellten Clusters wieder her, um einen neuen Aurora Serverless v1-Cluster zu erstellen.
Konvertieren von einem Cluster von Aurora Serverless v1 aus	Folgen Sie dem Verfahren unter Aktualisieren eines Aurora Serverless v1-Clusters auf Aurora Serverless v2.	Nicht zutreffend
Verfügbare DB-Instance-Klassen	Die DB-Instance-Sonderklasse db.serverless. In der AWS Management Console ist es als Serverless gekennzeichnet.	Nicht zutreffend. Aurora Serverless v1 verwendet den serverless-Engine-Modus.
Port	Jeder Port, der mit MySQL oder PostgreSQL kompatibel ist	Nur MySQL- oder PostgreSQL-Standard-Port
Öffentliche IP-Adresse zulässig?	Ja	Nein
Virtual Private Cloud (VPC) erforderlich?	Ja	Ja. Jeder Aurora Serverless v1-Cluster verbraucht 2 Schnittstellen- und Gateway-Load-Balancer-Endpunkte, die Ihrer VPC zugewiesen sind.

Skalierung und Verfügbarkeit von Aurora Serverless v2 und Aurora Serverless v1 im Vergleich

In der folgenden Tabelle werden die Unterschiede zwischen Aurora Serverless v2 und Aurora Serverless v1 im Hinblick auf Skalierbarkeit und Verfügbarkeit zusammengefasst.

Die Aurora Serverless v2-Skalierung ist reaktionsschneller, stärker granular und weniger störend als die Skalierung in Aurora Serverless v1.Aurora Serverless v2 kann sowohl durch Ändern der Größe der DB-Instance als auch durch Hinzufügen weiterer DB-Instances zum DB-Cluster skaliert werden. Es kann auch skaliert werden, indem Cluster in anderen AWS-Regionen zu einer globalen Aurora-Datenbank hinzugefügt werden. Im Gegensatz dazu skaliert Aurora Serverless v1 nur durch Erhöhung oder Verringerung der Kapazität des Writers. Sämtliche Berechnungen für einen Aurora Serverless v1-Cluster erfolgen in einer einzigen Availability Zone und einer einzigen AWS-Region.

Funktion für Skalierung und Hochverfügbarkeit	Aurora Serverless v2Verhalten	Aurora Serverless v1Verhalten
Minimale Aurora-Kapazitätseinheiten (ACUs) (Aurora MySQL)	0.5	1 wenn der Cluster läuft, 0, wenn der Cluster angehalten wird.
Minimale ACUs (Aurora PostgreSQL)	0.5	2 wenn der Cluster läuft, 0, wenn der Cluster angehalten wird.
Maximale ACUs (Aurora MySQL)	128	256
Maximale ACUs (Aurora PostgreSQL)	128	384
Stoppen eines Clusters	Sie können den Cluster manuell stoppen und starten, indem Sie die gleiche Cluster-Stopp-und Start-Funktion verwenden wie für bereitgestellte Cluster.	Der Cluster pausiert nach einem Timeout automatisch. Es dauert einige Zeit, bis er wieder verfügbar ist und die Aktivität fortgesetzt wird.
Skalierung von DB-Instances	Skalieren Sie mit einem Mindestinkrement von 0,5 ACU hoch und herunter.	Skalieren Sie durch Verdoppeln bzw. Halbieren der ACUs hoch und herunter.
Anzahl von DB-Instances	Entspricht einem bereitgestellten Cluster: 1 Writer-DB-Instance, bis zu 15 Reader-DB-Instances.	1 DB-Instance, die sowohl Lese- als auch Schreibvorgänge verarbeitet
Ist die Skalierung möglich, während SQL-Anweisungen ausgeführt werden?	Ja. Bei Aurora Serverless v2 entfällt das Warten auf Ruhepunkt.	Nein. Zum Beispiel wartet die Skalierung auf den Abschluss von lang andauernden Transaktionen, temporären Tabellen und Tabellensperren.
Reader-DB-Instances skalieren zusammen mit dem Writer	Optional.	Nicht zutreffend.
Maximaler Speicher	128 TiB	128 TiB oder 64 TiB, je nach Datenbank-Engine und Version.
Puffer-Cache wird beim Skalieren beibehalten	Ja. Die Größe des Puffer-Caches wird dynamisch geändert.	Nein. Der Puffer-Cache wird nach der Skalierung wiederverwendet.
Failover	Ja, genauso wie für bereitgestellte Cluster.	Nur bestmöglich, vorbehaltlich der Verfügbarkeit der Kapazität. Langsamer als in Aurora Serverless v2.
Multi-AZ-Fähigkeit	Ja, genauso wie für bereitgestellte Cluster. Ein Multi-AZ-Cluster benötigt eine Reader-DB-Instance in einer zweiten Availability Zone (AZ). Für einen Multi-AZ-Cluster führt Aurora im Falle eines AZ-Fehlers ein Multi-AZ-Failover durch.	Aurora Serverless v1-Cluster führen alle ihre Berechnungen in einer einzigen AZ aus. Die Wiederherstellung im Falle eines AZ-Ausfalls ist nur bestmöglich und unterliegt der Verfügbarkeit der Kapazität.
Globale Aurora-Datenbanken	Ja	Nein
Skalierung basierend auf Speicherauslastung	Ja	Nein
Skalierung basierend auf CPU-Last	Ja	Ja
Skalierung basierend auf Netzwerkverkehr	Ja, basierend auf Speicher- und CPU-Overhead des Netzwerkverkehrs. Der max_connections-Parameter bleibt konstant, um einen Abbruch von Verbindungen beim Herunterskalieren zu vermeiden.	Ja, basierend auf der Anzahl der Verbindungen.
Timeout-Aktion für Skalierungs-Ereignisse	Nein	Ja
Hinzufügen neuer DB-Instances zum Cluster über AWS Auto Scaling	Nicht zutreffend. Sie können Aurora Serverless v2-Reader DB-Instances in den Hochstufungsstufen 2 bis 15 erstellen und sie auf geringe Kapazität herunterskaliert lassen.	Nein. Reader-DB-Instances sind nicht verfügbar.

Funktionsunterstützung von Aurora Serverless v2 und Aurora Serverless v1 im Vergleich

Die folgende Tabelle enthält eine Zusammenfassung folgender Funktionen:

• Funktionen, die in Aurora Serverless v2, aber nicht in Aurora Serverless v1 verfügbar sind

• Funktionen, die in Aurora Serverless v1 und Aurora Serverless v2 unterschiedlich funktionieren

• Funktionen, die derzeit in Aurora Serverless v2 nicht verfügbar sind

Aurora Serverless v2 enthält viele Funktionen aus bereitgestellten Clustern, die für Aurora Serverless v1 nicht verfügbar sind.

Funktion	Aurora Serverless v2-Support	Aurora Serverless v1-Support
Cluster-Topologie	Aurora Serverless v2 ist eine Eigenschaft einzelner DB-Instances. Ein Cluster kann mehrere Aurora Serverless v2DB-Instances oder eine Kombination aus Aurora Serverless v2 und bereitgestellten DB-Instances enthalten.	Aurora Serverless v1-Cluster verwenden nicht den Begriff der DB-Instances. Sie können die Aurora Serverless v1-Eigenschaft nach dem Erstellen des Clusters nicht mehr ändern.
Konfigurationsparameter	Es können fast alle Parameter geändert werden wie in bereitgestellten Clustern. Details hierzu finden Sie unter Arbeiten mit Parametergruppen für Aurora Serverless v2.	Es kann nur eine Teilmenge von Parametern geändert werden.
Parametergruppen	Cluster-Parametergruppen und DB-Parametergruppen Parameter mit dem Wert provisioned im Attribut SupportedEngineModes sind verfügbar. Dies sind deutlich mehr Parameter als in Aurora Serverless v1.	Nur Cluster-Parametergruppe. Parameter mit dem Wert serverless im Attribut SupportedEngineModes sind verfügbar.
Verschlüsselung für Cluster-Volume	Optional	Erforderlich Die Einschränkungen in Einschränkungen von Amazon Aurora-verschlüsselten DB-Clustern gelten für alle Aurora Serverless v1-Cluster.
Regionsübergreifende Snapshots	Ja	Der Snapshot muss mit Ihrem eigenen Schlüssel AWS Key Management Service (AWS KMS) verschlüsselt werden.
Automatische Backups, die nach dem Löschen des DB-Clusters beibehalten werden	Ja	Nein
TLS/SSL	Ja. Die Unterstützung ist die gleiche wie für bereitgestellte Cluster. Weitere Informationen zur Nutzung finden Sie unter Verwenden von TLS/SSL mit Aurora Serverless v2.	Ja. Es gibt einige Unterschiede im Hinblick auf den TLS-Unterstützung für bereitgestellte Cluster. Weitere Informationen zur Nutzung finden Sie unter Verwenden von TLS/SSL mit Aurora Serverless v1.
Klonen	Nur von und zu DB-Engine-Versionen, die mit Aurora Serverless v2 kompatibel sind. Sie können das Klonen nicht verwenden, um ein Upgrade von Aurora Serverless v1 oder einer früheren Version eines bereitgestellten Clusters durchzuführen.	Nur von und zu DB-Engine-Versionen, die mit Aurora Serverless v1 kompatibel sind.
Integration in Amazon S3	Ja	Ja
Integration mit AWS Secrets Manager	Nein	Nein
Exportieren von DB-Cluster-Snapshots zu S3	Ja	Nein
Zuweisen einer IAM-Rolle	Ja	Nein
Logs auf Amazon hochladen CloudWatch	Optional. Sie wählen aus, welche Protokolle aktiviert und in welche Protokolle hochgeladen werden sollen. CloudWatch	Alle Protokolle, die aktiviert sind, werden CloudWatch automatisch hochgeladen.
Daten-API verfügbar	Ja (derzeit nur Aurora PostgreSQL)	Ja
Abfrage-Editor verfügbar	Ja (derzeit nur Aurora PostgreSQL)	Ja
Performance Insights	Ja	Nein
Amazon RDS Proxy verfügbar	Ja	Nein
Babelfish für Aurora PostgreSQL verfügbar	Ja. Unterstützt für Aurora-PostgreSQL-Versionen, die sowohl mit Babelfish als auch Aurora Serverless v2 kompatibel sind.	Nein

Anpassen von Aurora Serverless v1-Anwendungsfälle an Aurora Serverless v2

Abhängig von Ihrem Anwendungsfall für Aurora Serverless v1 können Sie diesen Ansatz wie folgt anpassen, um die Aurora Serverless v2-Funktionen zu nutzen.

Angenommen, Sie haben einen Aurora Serverless v1-Cluster vorliegen, der leicht geladen ist, und Ihre Priorität besteht darin, die kontinuierliche Verfügbarkeit aufrechtzuerhalten und gleichzeitig die Kosten zu minimieren. Mit Aurora Serverless v2 können Sie mit 0,5 eine kleinere Mindesteinstellung für ACU konfigurieren als bei Aurora Serverless v1. Hier beträgt der Mindestwert 1 ACU. Sie können die Verfügbarkeit erhöhen, indem Sie eine Multi-AZ-Konfiguration erstellen, wobei die DB-Instance des Readers ebenfalls auf den Mindestwert von 0,5 ACUs eingestellt ist.

Angenommen, Sie haben einen Aurora Serverless v1-Cluster vorliegen, den Sie in einem Entwicklungs- und Testszenario verwenden. In diesem Fall haben die Kosten ebenfalls eine hohe Priorität, aber der Cluster muss nicht jederzeit verfügbar sein. Derzeit pausiert Aurora Serverless v2 den Cluster nicht automatisch, wenn er vollständig inaktiv ist. Stattdessen können Sie den Cluster manuell stoppen, wenn er nicht benötigt wird, und ihn starten, wenn der nächste Test- oder Entwicklungszyklus ansteht.

Angenommen, Sie haben einen Aurora Serverless v1-Cluster mit einer hohen Workload vorliegen. Ein gleichwertiger Cluster mit Aurora Serverless v2 kann mit größerer Granularität skaliert werden. Aurora Serverless v1 skaliert beispielsweise durch Verdoppelung der Kapazität, z. B. von 64 auf 128 ACU. Im Gegensatz dazu kann Ihre Aurora Serverless v2-DB-Instance auf einen beliebigen Wert zwischen diesen Zahlen skaliert werden.

Angenommen, Ihre Workload erfordert eine höhere Gesamtkapazität, als in Aurora Serverless v1 verfügbar ist. Sie können mehrere Aurora Serverless v2-Reader-DB-Instances verwenden, um die leseintensiven Teile der Workload von der Writer-DB-Instance auszulagern. Sie können leseintensive Workloads auch auf mehrere Reader-DB-Instances verteilen.

Für eine schreibintensive Workload können Sie den Cluster mit einer großen bereitgestellten DB-Instance als Writer konfigurieren. Sie können diesen Vorgang zusammen mit einer oder mehreren Reader-DB-Instances von Aurora Serverless v2 ausführen.

Aktualisieren eines Aurora Serverless v1-Clusters auf Aurora Serverless v2

Der Prozess zum Aktualisieren eines DB-Clusters von Aurora Serverless v1 auf Aurora Serverless v2 umfasst mehrere Schritte. Das liegt daran, dass Sie nicht direkt von Aurora Serverless v1 in Aurora Serverless v2 konvertieren können. Es gibt immer einen Zwischenschritt, bei dem der Aurora Serverless v1-DB-Cluster in einen bereitgestellten Cluster konvertiert wird.

Mit Aurora MySQL kompatible DB-Cluster

Sie können Ihren Aurora Serverless v1 DB-Cluster in einen bereitgestellten DB-Cluster umwandeln und ihn dann mit einer blauen/grünen Implementierung aktualisieren und in einen DB-Cluster konvertieren. Aurora Serverless v2 Wir empfehlen dieses Verfahren für Produktionsumgebungen. Weitere Informationen finden Sie unter Verwendung von Blau/Grün-Bereitstellungen von Amazon RDS für Datenbankaktualisierungen.

Um eine blaue/grüne Bereitstellung für ein Upgrade eines Aurora Serverless v1 Clusters zu verwenden, auf dem Aurora MySQL Version 2 (MySQL 5.7-kompatibel) ausgeführt wird

1. Konvertieren Sie den DB-Cluster von Aurora Serverless v1 in einen bereitgestellten Cluster von Aurora MySQL Version 2. Folgen Sie dem Verfahren unter Konvertieren von Aurora Serverless v1 in bereitgestellt.

2. Erstellen Sie eine blaue/grüne Bereitstellung. Folgen Sie dem Verfahren unter Erstellen einer Blau/Grün-Bereitstellung.

3. Wählen Sie eine Aurora MySQL-Version für den grünen Cluster, die beispielsweise mit Aurora Serverless v2 3.04.1 kompatibel ist.

   Eine Liste kompatibler Versionen finden Sie unter Aurora Serverless v2 mit Aurora MySQL.

4. Ändern Sie die Writer-DB-Instance des grünen Clusters so, dass sie die DB-Instance-Klasse Serverless v2 (db.serverless) verwendet.

   Details hierzu finden Sie unter Konvertieren eines bereitgestellten Writers oder Readers in Aurora Serverless v2.

5. Wenn Ihr aktualisiertes Aurora Serverless v2 DB-Cluster verfügbar ist, wechseln Sie vom blauen Cluster zum grünen Cluster.

Mit Aurora PostgreSQL kompatible DB-Cluster

Sie können Ihren Aurora Serverless v1 DB-Cluster in einen bereitgestellten DB-Cluster konvertieren und ihn dann mit einer blauen/grünen Bereitstellung aktualisieren und in einen Aurora Serverless v2 DB-Cluster konvertieren. Wir empfehlen dieses Verfahren für Produktionsumgebungen. Weitere Informationen finden Sie unter Verwendung von Blau/Grün-Bereitstellungen von Amazon RDS für Datenbankaktualisierungen.

So verwenden Sie eine blaue/grüne Bereitstellung für ein Upgrade eines Aurora Serverless v1 Clusters, auf dem Aurora PostgreSQL Version 11 ausgeführt wird

1. Konvertieren Sie den DB-Cluster von Aurora Serverless v1 in einen bereitgestellten Cluster von Aurora PostgreSQL. Folgen Sie dem Verfahren unter Konvertieren von Aurora Serverless v1 in bereitgestellt.

2. Erstellen Sie eine blaue/grüne Bereitstellung. Folgen Sie dem Verfahren unter Erstellen einer Blau/Grün-Bereitstellung.

3. Wählen Sie eine Aurora PostgreSQL-Version für den grünen Cluster, die beispielsweise mit 15.3 Aurora Serverless v2 kompatibel ist.

   Eine Liste kompatibler Versionen finden Sie unter Aurora Serverless v2 mit Aurora PostgreSQL.

4. Ändern Sie die Writer-DB-Instance des grünen Clusters so, dass sie die DB-Instance-Klasse Serverless v2 (db.serverless) verwendet.

   Details hierzu finden Sie unter Konvertieren eines bereitgestellten Writers oder Readers in Aurora Serverless v2.

5. Wenn Ihr aktualisiertes Aurora Serverless v2 DB-Cluster verfügbar ist, wechseln Sie vom blauen Cluster zum grünen Cluster.

Sie können Ihren Aurora Serverless v1 DB-Cluster auch direkt von Aurora PostgreSQL Version 11 auf Version 13 aktualisieren, ihn in einen bereitgestellten DB-Cluster konvertieren und dann den bereitgestellten Cluster in einen DB-Cluster konvertieren. Aurora Serverless v2

Um ein Upgrade durchzuführen, konvertieren Sie dann einen Aurora Serverless v1 Cluster, auf dem Aurora PostgreSQL Version 11 ausgeführt wird

1. Führen Sie ein Upgrade des Aurora Serverless v1 Clusters auf eine Aurora PostgreSQL-Version 13 durch, die beispielsweise mit Aurora Serverless v2 13.12 kompatibel ist. Folgen Sie dem Verfahren unter Durchführen eines Upgrades der Hauptversion.

   Eine Liste kompatibler Versionen finden Sie unter Aurora Serverless v2 mit Aurora PostgreSQL.

2. Konvertieren Sie den DB-Cluster von Aurora Serverless v1 in einen bereitgestellten Cluster von Aurora PostgreSQL. Folgen Sie dem Verfahren unter Konvertieren von Aurora Serverless v1 in bereitgestellt.

3. Fügen Sie dem Cluster eine Aurora Serverless v2 Reader-DB-Instance hinzu. Weitere Informationen finden Sie unter Hinzufügen eines Aurora Serverless v2-Readers.

4. Führen Sie einen Failover zur Aurora Serverless v2 DB-Instance durch:

   1. Wählen Sie die Writer-DB-Instance des DB-Clusters aus.

   2. Wählen Sie für Aktionen die Option Failover aus.

   3. Wählen Sie auf der Bestätigungsseite Failover aus.

Für Aurora Serverless v1 DB-Cluster, auf denen Aurora PostgreSQL Version 13 ausgeführt wird, konvertieren Sie den Aurora Serverless v1 Cluster in einen bereitgestellten DB-Cluster und anschließend den bereitgestellten Cluster in einen DB-Cluster. Aurora Serverless v2

So führen Sie ein Upgrade eines Clusters von Aurora Serverless v1 durch, auf dem Aurora PostgreSQL Version 13 ausgeführt wird

1. Konvertieren Sie den DB-Cluster von Aurora Serverless v1 in einen bereitgestellten Cluster von Aurora PostgreSQL. Folgen Sie dem Verfahren unter Konvertieren von Aurora Serverless v1 in bereitgestellt.

2. Fügen Sie dem Cluster eine Aurora Serverless v2 Reader-DB-Instance hinzu. Weitere Informationen finden Sie unter Hinzufügen eines Aurora Serverless v2-Readers.

3. Führen Sie einen Failover zur Aurora Serverless v2 DB-Instance durch:

   1. Wählen Sie die Writer-DB-Instance des DB-Clusters aus.

   2. Wählen Sie für Aktionen die Option Failover aus.

   3. Wählen Sie auf der Bestätigungsseite Failover aus.

Migrieren einer On-Premises-Datenbank zu Aurora Serverless v2

Sie können Ihre On-Premises-Datenbanken zu Aurora Serverless v2 migrieren, genau wie bei bereitgestellten Aurora MySQL und Aurora PostgreSQL.

• Für MySQL-Datenbanken können Sie den mysqldump-Befehl verwenden. Weitere Informationen finden Sie unter Importieren von Daten in eine MySQL- oder -MariaDB-Datenbank-Instance mit reduzierter Ausfallzeit.

• Für PostgreSQL-Datenbanken können Sie die Befehle pg_dump und pg_restore verwenden. Weitere Informationen finden Sie im Blog-Beitrag Best practices for migrating PostgreSQL databases to Amazon RDS and Amazon Aurora (Bewährte Methoden für die Migration von PostgreSQL Datenbanken zu RDS und Amazon Aurora).