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.

Migration zu Aurora Serverless v2

Um einen vorhandenen DB-Cluster zu konvertieren, um ihn zu verwenden Aurora Serverless v2, können Sie wie folgt vorgehen:

Wenn auf Ihrem aktualisierten Cluster die entsprechende Engine-Version ausgeführt wird, wie unter aufgeführtAnforderungen und Einschränkungen für Aurora Serverless v2, können Sie mit dem Hinzufügen beginnen Aurora Serverless v2 DB-Instances dazu. 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 den Schreib-Workload, den Lese-Workload oder beide auf den Aurora Serverless v2 DB-Instances.

Aktualisierung oder Umstellung vorhandener Cluster auf Nutzung Aurora Serverless v2

Wenn Ihr bereitgestellter Cluster über eine Engine-Version verfügt, die Folgendes unterstützt Aurora Serverless v2, wechselt zu Aurora Serverless v2 erfordert kein Upgrade. In diesem Fall können Sie hinzufügen Aurora Serverless v2 DB-Instances zu Ihrem ursprünglichen Cluster. Sie können den Cluster wechseln, um alle zu verwenden Aurora Serverless v2 DB-Instances. Sie können auch eine Kombination von verwenden Aurora Serverless v2 und bereitgestellte DB-Instances im selben DB-Cluster. Für die Aurora-Engine-Versionen, die Folgendes unterstützen Aurora Serverless v2, finden Sie unter Unterstützte Regionen und Aurora-DB-Engines für Aurora Serverless v2.

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

Upgrade von Aurora Serverless v1 to Aurora Serverless v2 beinhaltet die Erstellung eines bereitgestellten Clusters als Zwischenschritt. Anschließend führen Sie dieselben Upgrade-Schritte aus wie beim Start mit einem bereitgestellten Cluster.

Aktualisieren Sie die Pfade für die Verwendung von My SQL -kompatiblen Clustern Aurora Serverless v2

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

Upgrade-Pfade für zu verwendende SQL Postgre-kompatible Cluster Aurora Serverless v2

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

Wechsel von einem bereitgestellten Cluster zu Aurora Serverless v2

Um einen bereitgestellten Cluster zu verwenden Aurora Serverless v2, gehen Sie wie folgt vor:

Das folgende AWS CLI Beispiel zeigt den Switchover-Prozess unter Verwendung eines bereitgestellten Clusters, auf dem Aurora My SQL 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 eine Fehlermeldung, wenn wir irgendwelche hinzufügen Aurora Serverless v2 DB-Instances zum Cluster. Wenn wir AWS Management Console für dieses Verfahren den verwenden, erfolgt dieser Schritt automatisch, wenn wir den ersten hinzufügen Aurora Serverless v2 DB-Instance.

$ 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 Aurora Serverless v2 Reader, die den Platz der ursprünglichen DB-Instances einnehmen sollen. 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 durch, um eine der Aurora Serverless v2 DB-Instances sind der neue Writer für den Cluster.

$ 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 haben wir eine Aurora Serverless v2 Autor und ein Aurora Serverless v2 Leser. 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"
}

Als letzte Überprüfung bestätigen wir, dass die Originaltabelle von der aus zugänglich und beschreibbar ist Aurora Serverless v2 Writer-DB-Instance.

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 auch eine Verbindung zum her Aurora Serverless v2 Lesen Sie die DB-Instance und bestätigen Sie, dass die neu geschriebenen Daten auch dort 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)

Vergleich von Aurora Serverless v2 and Aurora Serverless v1

Wenn Sie bereits verwenden Aurora Serverless v1, können Sie die wichtigsten Unterschiede lernen zwischen Aurora Serverless v1 and Aurora Serverless v2. Die architektonischen Unterschiede, wie die Unterstützung von 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 and Aurora Serverless v1.

Vergleich von Aurora Serverless v2 and Aurora Serverless v1 Anforderungen

In der folgenden Tabelle sind die verschiedenen Anforderungen für den Betrieb Ihrer Datenbank zusammengefasst Aurora Serverless v2 or Aurora Serverless v1. Aurora Serverless v2 bietet höhere Versionen der Aurora My SQL - und Aurora SQL Postgre-DB-Engines als Aurora Serverless v1 tut.

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

In der folgenden Tabelle sind die Unterschiede zusammengefasst zwischen Aurora Serverless v2 and Aurora Serverless v1 für Skalierbarkeit und Verfügbarkeit.

Aurora Serverless v2 Die Skalierung ist reaktionsschneller, detaillierter und weniger störend als die Skalierung Aurora Serverless v1. Aurora Serverless v2 kann sowohl durch Änderung 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 Aurora Serverless v1 Skaliert nur, indem die Kapazität des Schreibers erhöht oder verringert wird. Die ganze Rechenleistung für ein Aurora Serverless v1 Der Cluster wird in einer einzigen Availability Zone und einer einzigen ausgeführt AWS-Region.

Vergleich von Aurora Serverless v2 and Aurora Serverless v1 Unterstützung von Funktionen

Die folgende Tabelle enthält eine Zusammenfassung folgender Funktionen:

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

Anpassung Aurora Serverless v1 Anwendungsfälle an Aurora Serverless v2

Abhängig von Ihrem Anwendungsfall für Aurora Serverless v1, Sie könnten diesen Ansatz anpassen, um folgende Vorteile zu nutzen Aurora Serverless v2 verfügt wie folgt.

Angenommen, Sie haben eine Aurora Serverless v1 Ein Cluster mit geringer Auslastung, und Ihre Priorität ist die Aufrechterhaltung der kontinuierlichen Verfügbarkeit bei gleichzeitiger Minimierung der Kosten. Mit Aurora Serverless v2, Sie können eine kleinere ACU Mindesteinstellung von 0,5 konfigurieren, verglichen mit einer Mindesteinstellung von 1 ACU für Aurora Serverless v1. Sie können die Verfügbarkeit erhöhen, indem Sie eine Multi-AZ-Konfiguration erstellen, wobei die Reader-DB-Instance ebenfalls mindestens 0,5 ACUs hat.

Angenommen, Sie haben eine Aurora Serverless v1 Cluster, 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. Aurora Serverless v2 kann jede Instanz automatisch pausieren, wenn sie vollständig inaktiv ist. Sie tun dies, indem Sie eine Mindestkapazität von 0 ACUs für den Cluster angeben, wie unter erklärtSkalierung auf Null ACUs mit automatischer Pause und Wiederaufnahme für Aurora Serverless v2. Sie können den Cluster auch manuell beenden, wenn er nicht benötigt wird, und ihn starten, wenn der nächste Test- oder Entwicklungszyklus ansteht.

Angenommen, Sie haben eine Aurora Serverless v1 Cluster mit einer hohen Arbeitslast. Ein äquivalenter Cluster mit Aurora Serverless v2 kann mit größerer Granularität skaliert werden. Zum Beispiel Aurora Serverless v1 skaliert durch Verdoppelung der Kapazität, beispielsweise von 64 auf 128. ACUs Im Gegensatz dazu ist Ihr Aurora Serverless v2 Die DB-Instance kann in ACU Schritten von 0,5 skaliert werden.

Nehmen wir an, Ihr Workload erfordert eine höhere Gesamtkapazität als die, die in verfügbar ist Aurora Serverless v1. Sie können mehrere verwenden Aurora Serverless v2 Reader-DB-Instances, um die leseintensiven Teile der Arbeitslast von der Writer-DB-Instance zu entlasten. 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önnten dies zusammen mit einer oder mehreren tun Aurora Serverless v2 Reader-DB-Instances.

Upgrade von einem Aurora Serverless v1 Cluster zu Aurora Serverless v2

Der Prozess des Upgrades eines DB-Clusters von Aurora Serverless v1 to Aurora Serverless v2 besteht aus mehreren Schritten. Das liegt daran, dass Sie nicht direkt von konvertieren können Aurora Serverless v1 to Aurora Serverless v2. Es gibt immer einen Zwischenschritt, der die Konvertierung von beinhaltet Aurora Serverless v1 DB-Cluster in einen bereitgestellten Cluster.

Aurora My SQL —kompatible DB-Cluster

Sie können Ihre konvertieren Aurora Serverless v1 DB-Cluster in einen bereitgestellten DB-Cluster, dann verwenden Sie eine blaue/grüne Bereitstellung, um ihn zu aktualisieren und in einen Aurora Serverless v2 DB-Cluster. Wir empfehlen dieses Verfahren für Produktionsumgebungen. Weitere Informationen finden Sie unter Verwenden von Aurora Blue/Green Deployments für Datenbank-Updates.

Aurora SQL Postgre-kompatible DB-Cluster

Sie können Ihre konvertieren Aurora Serverless v1 DB-Cluster in einen bereitgestellten DB-Cluster, dann verwenden Sie eine blaue/grüne Bereitstellung, um ihn zu aktualisieren und in einen Aurora Serverless v2 DB-Cluster. Wir empfehlen dieses Verfahren für Produktionsumgebungen. Weitere Informationen finden Sie unter Verwenden von Aurora Blue/Green Deployments für Datenbank-Updates.

Sie können auch Ihr Upgrade durchführen Aurora Serverless v1 DB-Cluster direkt von Aurora Postgre SQL Version 11 auf Version 13, konvertieren Sie ihn in einen bereitgestellten DB-Cluster und konvertieren Sie dann den bereitgestellten Cluster in einen Aurora Serverless v2 DB-Cluster.

Wählen Sie in der &Snowconsole; Ihren Auftrag aus der Tabelle. Aurora Serverless v1 DB-Cluster, auf denen Aurora SQL Postgre-Version 13 ausgeführt wird, konvertieren Sie Aurora Serverless v1 Cluster in einen bereitgestellten DB-Cluster und konvertieren Sie dann den bereitgestellten Cluster in einen Aurora Serverless v2 DB-Cluster.

Migration von einer lokalen Datenbank zu Aurora Serverless v2

Sie können Ihre lokalen Datenbanken migrieren zu Aurora Serverless v2, genau wie bei den bereitgestellten Versionen Aurora My SQL und Aurora SQL Postgre.