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.

VPC-übergreifendes Klonen mit Amazon Aurora

Angenommen, Sie möchten für den ursprünglichen Cluster und den Klon unterschiedliche Netzwerkzugriffskontrollen festlegen. Sie können beispielsweise durch Klonen eine Kopie eines Aurora-Produktionsclusters in einer anderen VPC für Entwicklung und Tests erstellen. Oder Sie können einen Klon als Teil einer Migration von öffentlichen Subnetzen zu privaten Subnetzen erstellen, um die Datenbanksicherheit zu erhöhen.

In den folgenden Abschnitten wird gezeigt, wie die Netzwerkkonfiguration für den Klon so eingerichtet wird, dass der ursprüngliche Cluster und der Klon beide auf dieselben Aurora-Speicherknoten zugreifen können, auch von unterschiedlichen Subnetzen oder unterschiedlichen VPCs aus. Durch die vorherige Überprüfung der Netzwerkressourcen können Fehler beim Klonen vermieden werden, die möglicherweise schwer zu diagnostizieren sind.

Wenn Sie nicht wissen, wie Aurora mit VPCs, Subnetzen und DB-Subnetzgruppen interagiert, informieren Sie sich zunächst unter Amazon VPC und Amazon Aurora. Sie können die Tutorials in diesem Abschnitt durcharbeiten, um diese Art von Ressourcen in der AWS-Konsole zu erstellen und zu verstehen, wie sie zusammenpassen.

Da die Schritte das Umschalten zwischen den RDS- und EC2-Diensten beinhalten, verwenden die Beispiele AWS-CLI-Befehle, damit Sie besser verstehen können, wie Sie solche Operationen automatisieren und die Ausgabe speichern.

Bevor Sie beginnen

Stellen Sie vor dem Einrichten eines VPC-übergreifenden Klons sicher, dass Sie über die folgenden Ressourcen verfügen:

Sammeln von Informationen über die Netzwerkumgebung

Beim VPC-übergreifenden Klonen kann sich die Netzwerkumgebung zwischen dem ursprünglichen Cluster und seinem Klon erheblich unterscheiden. Bevor Sie den Klon erstellen, sollten Sie Informationen über die VPC, die Subnetze, die DB-Subnetzgruppe und die AZs sammeln und aufzeichnen, die im ursprünglichen Cluster verwendet wurden. Auf diese Weise können Sie die Wahrscheinlichkeit von Problemen minimieren. Wenn ein Netzwerkproblem auftritt, müssen Sie die Aktivitäten zur Problembehandlung nicht unterbrechen, um nach Diagnoseinformationen zu suchen. Die folgenden Abschnitte zeigen CLI-Beispiele zum Sammeln dieser Art von Informationen. Sie können die Details in einem beliebigen Format speichern, auf das Sie bei der Erstellung des Klons und bei der Problembehandlung schnell zugreifen können.

Schritt 1: Überprüfen der Availability Zones des ursprünglichen Clusters

Bevor Sie den Klon erstellen, überprüfen Sie, welche AZs der ursprüngliche Cluster für seinen Speicher verwendet. Wie unter Amazon-Aurora-Speicher erklärt, ist der Speicher für jeden Aurora-Cluster genau drei AZs zugeordnet. Da Amazon-Aurora-DB-Cluster die Trennung zwischen Rechenleistung und Speicher nutzt, gilt diese Regel unabhängig davon, wie viele Instances in dem Cluster enthalten sind.

Führen Sie beispielsweise einen CLI-Befehl wie den folgenden aus und ersetzen Sie my_cluster durch den Namen Ihres Clusters. Im folgenden Beispiel wird eine alphabetisch nach dem AZ-Namen sortierte Liste erstellt.

aws rds describe-db-clusters \
  --db-cluster-identifier my_cluster \
  --query 'sort_by(*[].AvailabilityZones[].{Zone:@},&Zone)' \
  --output text

Das folgende Beispiel zeigt eine Beispielausgabe für den vorhergehenden describe-db-clusters-Befehl. Es zeigt, dass der Speicher für den Aurora-Cluster immer drei AZs verwendet.

us-east-1c
us-east-1d
us-east-1e

Um einen Klon in einer Netzwerkumgebung zu erstellen, die nicht über alle Ressourcen verfügt, um eine Verbindung zu diesen AZs herzustellen, müssen Sie Subnetze erstellen, die mindestens zwei dieser AZs zugeordnet sind. Danach erstellen Sie eine DB-Subnetzgruppe, die diese zwei oder drei Subnetze enthält. In den nachstehenden Beispielen wird die Vorgehensweise dazu veranschaulicht.

Schritt 2: Überprüfen der DB-Subnetzgruppe des ursprünglichen Clusters

Wenn Sie dieselbe Anzahl von Subnetzen für den Klon wie im ursprünglichen Cluster verwenden möchten, können Sie die Anzahl der Subnetze aus der DB-Subnetzgruppe des ursprünglichen Clusters abrufen. Eine Aurora-DB-Subnetzgruppe enthält mindestens zwei Subnetze, die jeweils einer anderen AZ zugeordnet sind. Notieren Sie sich, welchen AZs die Subnetze zugeordnet sind.

Das folgende Beispiel zeigt, wie Sie die DB-Subnetzgruppe des ursprünglichen Clusters finden und dann rückwärts zu den entsprechenden AZs arbeiten. Ersetzen Sie my_cluster im ersten Befehl durch den Namen Ihres Clusters. Geben Sie im zweiten Befehl für my_subnet den Namen der DB-Subnetzgruppe an.

aws rds describe-db-clusters --db-cluster-identifier my_cluster \
  --query '*[].DBSubnetGroup' --output text

aws rds describe-db-subnet-groups --db-subnet-group-name my_subnet_group \
  --query '*[].Subnets[].[SubnetAvailabilityZone.Name]' --output text

Die Beispielausgabe könnte für einen Cluster mit einer DB-Subnetzgruppe, die zwei Subnetze enthält, in etwa wie folgt aussehen. In diesem Fall ist two-subnets ein Name, der bei der Erstellung der DB-Subnetzgruppe angegeben wurde.

two-subnets

us-east-1d
us-east-1c

Für einen Cluster, bei dem die DB-Subnetzgruppe drei Subnetze enthält, könnte die Ausgabe wie folgt aussehen.

three-subnets

us-east-1f
us-east-1d
us-east-1c

Schritt 3: Überprüfen der Subnetze des ursprünglichen Clusters

Wenn Sie weitere Informationen zu den Subnetzen im ursprünglichen Cluster benötigen, führen Sie AWS-CLI-Befehle aus, die den folgenden ähneln. Sie können die Subnetzattribute wie IP-Adressbereiche, Besitzer usw. untersuchen. Auf diese Weise können Sie bestimmen, ob Sie verschiedene Subnetze in derselben VPC verwenden oder Subnetze mit ähnlichen Eigenschaften in einer anderen VPC erstellen möchten.

Suchen Sie die Subnetz-IDs aller Subnetze, die in Ihrer VPC verfügbar sind.

aws ec2 describe-subnets --filters Name=vpc-id,Values=my_vpc \
  --query '*[].[SubnetId]' --output text

Suchen Sie die genauen Subnetze, die in Ihrer DB-Subnetzgruppe verwendet werden.

aws rds describe-db-subnet-groups --db-subnet-group-name my_subnet_group \
  --query '*[].Subnets[].[SubnetIdentifier]' --output text

Geben Sie dann die Subnetze, die Sie untersuchen möchten, in einer Liste an, wie im folgenden Befehl. Geben Sie die Namen Ihrer Subnetze für my_subnet_1 usw. ein.

aws ec2 describe-subnets \
  --subnet-ids '["my_subnet_1","my_subnet2","my_subnet3"]'

Das folgende Beispiel zeigt die teilweise Ausgabe eines solchen describe-subnets-Befehls. Die Ausgabe zeigt einige der wichtigen Attribute, die Sie für jedes Subnetz sehen können, z. B. die zugehörige AZ und die VPC, zu der es gehört.

{
    'Subnets': [
        {
            'AvailabilityZone': 'us-east-1d',
            'AvailableIpAddressCount': 54,
            'CidrBlock': '10.0.0.64/26',
            'State': 'available',
            'SubnetId': 'subnet-000a0bca00e0b0000',
            'VpcId': 'vpc-3f3c3fc3333b3ffb3',
            ...
        },
        {
            'AvailabilityZone': 'us-east-1c',
            'AvailableIpAddressCount': 55,
            'CidrBlock': '10.0.0.0/26',
            'State': 'available',
            'SubnetId': 'subnet-4b4dbfe4d4a4fd4c4',
            'VpcId': 'vpc-3f3c3fc3333b3ffb3',
            ...

Schritt 4: Überprüfen Sie der Availability Zones der DB-Instances im ursprünglichen Cluster

Sie können dieses Verfahren verwenden, um nachzuvollziehen, welche AZs für die DB-Instances im ursprünglichen Cluster verwendet werden. Auf diese Weise können Sie exakt dieselben AZs für die DB-Instances im Klon einrichten. Sie können auch mehr oder weniger DB-Instances im Klon verwenden, je nachdem, ob der Klon für Produktion, Entwicklung und Tests verwendet wird usw.

Führen Sie für jede Instance im ursprünglichen Cluster einen Befehl wie den folgenden aus. Stellen Sie sicher, dass die Instance den Erstellungsvorgang abgeschlossen hat und sich im Status Available befindet. Geben Sie die Instance-ID für my_instance ein.

aws rds describe-db-instances --db-instance-identifier my_instance \
  --query '*[].AvailabilityZone' --output text

Das folgende Beispiel zeigt die Ausgabe nach dem Ausführen des describe-db-instances-Befehls. Der Aurora-Cluster hat vier Datenbank-Instances. Daher führen wir den Befehl viermal aus und geben dabei jedes Mal eine andere DB-Instance-ID an. Die Ausgabe zeigt, wie diese DB-Instances auf maximal drei AZs verteilt sind.

us-east-1a
us-east-1c
us-east-1d
us-east-1a

Wenn der Klon erstellt wurde und Sie ihm DB-Instances hinzufügen, können Sie dieselben AZ-Namen in den create-db-instance-Befehlen angeben. Sie können dies tun, um DB-Instances im neuen Cluster einzurichten, die für genau dieselben AZs wie im ursprünglichen Cluster konfiguriert sind.

Schritt 5: Überprüfen der VPCs, die für den Klon verwendet werden können

Wenn Sie beabsichtigen, den Klon in einer anderen VPC als der ursprünglichen zu erstellen, können Sie eine Liste der für Ihr Konto verfügbaren VPC-IDs abrufen. Sie können diesen Schritt auch ausführen, wenn Sie zusätzliche Subnetze in derselben VPC wie der ursprüngliche Cluster erstellen müssen. Wenn Sie den Befehl zum Erstellen eines Subnetzes ausführen, geben Sie die VPC-ID als Parameter an.

Führen Sie den folgenden CLI-Befehl aus, um alle VPCs für Ihr Konto aufzuführen:

aws ec2 describe-vpcs --query '*[].[VpcId]' --output text

Das folgende Beispiel zeigt eine Beispielausgabe für den vorhergehenden describe-vpcs-Befehl. Die Ausgabe zeigt, dass das aktuelle AWS-Konto vier VPCs enthält, die als Quelle oder Ziel für das VPC-übergreifende Klonen verwendet werden können.

vpc-fd111111
vpc-2222e2cd2a222f22e
vpc-33333333a33333d33
vpc-4ae4d4de4a4444dad

Sie können dieselbe VPC als Ziel für den Klon oder eine andere VPC verwenden. Wenn sich der ursprüngliche Cluster und der Klon in derselben VPC befinden, können Sie dieselbe DB-Subnetzgruppe für den Klon wiederverwenden. Sie können auch eine andere DB-Subnetzgruppe erstellen. Beispielsweise könnte die neue DB-Subnetzgruppe private Subnetze verwenden, während die DB-Subnetzgruppe des ursprünglichen Clusters öffentliche Subnetze verwenden könnte. Wenn Sie den Klon in einer anderen VPC erstellen, stellen Sie sicher, dass in der neuen VPC genügend Subnetze vorhanden sind und dass die Subnetze den richtigen AZs aus dem ursprünglichen Cluster zugeordnet sind.

Erstellen von Netzwerkressourcen für den Klon

Wenn Sie beim Sammeln der Netzwerkinformationen festgestellt haben, dass zusätzliche Netzwerkressourcen für den Klon benötigt werden, können Sie diese Ressourcen erstellen, bevor Sie versuchen, den Klon einzurichten. Beispielsweise müssen Sie möglicherweise mehr Subnetze, bestimmten AZs zugeordnete Subnetze oder eine neue DB-Subnetzgruppe erstellen.

Schritt 1: Erstellen der Subnetze für den Klon

Wenn Sie neue Subnetze für den Klon erstellen müssen, führen Sie einen Befehl wie den folgenden aus. Möglicherweise müssen Sie dies tun, wenn Sie den Klon in einer anderen VPC erstellen oder wenn Sie eine andere Netzwerkänderung vornehmen und z. B. private Subnetze anstelle von öffentlichen Subnetzen verwenden.

AWS generiert automatisch die ID des Subnetzes. Geben Sie den Namen der VPC des Klons für my_vpc ein. Wählen Sie den Adressbereich für die --cidr-block-Option so aus, dass mindestens 16 IP-Adressen in dem Bereich zugelassen werden. Sie können alle anderen Eigenschaften einbeziehen, die Sie angeben möchten. Führen Sie den Befehl aws ec2 create-subnet help aus, um alle Auswahlmöglichkeiten zu sehen.

aws ec2 create-subnet --vpc-id my_vpc \
  --availability-zone AZ_name --cidr-block IP_range

Das folgende Beispiel zeigt einige wichtige Attribute eines neu erstellten Subnetzes.

{
    'Subnet': {
        'AvailabilityZone': 'us-east-1b',
        'AvailableIpAddressCount': 59,
        'CidrBlock': '10.0.0.64/26',
        'State': 'available',
        'SubnetId': 'subnet-44b4a44f4e44db444',
        'VpcId': 'vpc-555fc5df555e555dc',
        ...
        }
}

Schritt 2: Erstellen der DB-Subnetzgruppe für den Klon

Wenn Sie den Klon in einer anderen VPC oder eine andere Gruppe von Subnetzen innerhalb derselben VPC erstellen, erstellen Sie eine neue DB-Subnetzgruppe und geben sie bei der Erstellung des Klons an.

Stellen Sie sicher, dass Ihnen alle folgenden Details bekannt sind. Sie können all diese Informationen in der Ausgabe der vorherigen Beispiele finden.

Prüfen Sie, wie viele AZs sowohl dem Speicher des ursprünglichen Clusters als auch den Subnetzen in der Ziel-VPC zugeordnet sind. Um den Klon erfolgreich zu erstellen, müssen sie zwei oder drei AZs gemeinsam haben. Wenn weniger als zwei gemeinsam verwendete AZs vorhanden sind, gehen Sie zurück zu Schritt 1: Erstellen der Subnetze für den Klon. Erstellen Sie ein, zwei oder drei neue Subnetze, die den AZs zugeordnet sind, die dem Speicher des ursprünglichen Clusters zugeordnet sind.

Wählen Sie Subnetze in der Ziel-VPC aus, die denselben AZs zugeordnet sind wie der Aurora-Speicher im ursprünglichen Cluster. Wählen Sie idealerweise drei AZs aus. Auf diese Weise haben Sie die größte Flexibilität, um die DB-Instances des Klons auf mehrere AZs zu verteilen und so eine hohe Verfügbarkeit der Rechenressourcen zu gewährleisten.

Führen Sie einen ähnlichen Befehl wie den folgenden aus, um die neue DB-Subnetzgruppe zu erstellen. Ersetzen Sie die IDs Ihrer Subnetze in der Liste. Wenn Sie die Subnetz-IDs mithilfe von Umgebungsvariablen angeben, achten Sie darauf, die --subnet-ids-Parameterliste so in Anführungszeichen zu setzen, dass die IDs weiter in doppelten Anführungszeichen stehen.

aws rds create-db-subnet-group --db-subnet-group-name my_subnet_group \
  --subnet-ids '["my_subnet_1","my_subnet_2","my_subnet3"]' \
  --db-subnet-group-description 'DB subnet group with 3 subnets for clone'

Das folgende Beispiel zeigt teilweise die Ausgabe des Befehls create-db-subnet-group.

{
    'DBSubnetGroup': {
        'DBSubnetGroupName': 'my_subnet_group',
        'DBSubnetGroupDescription': 'DB subnet group with 3 subnets for clone',
        'VpcId': 'vpc-555fc5df555e555dc',
        'SubnetGroupStatus': 'Complete',
        'Subnets': [
            {
                'SubnetIdentifier': 'my_subnet_1',
                'SubnetAvailabilityZone': {
                    'Name': 'us-east-1c'
                },
                'SubnetStatus': 'Active'
            },
            {
                'SubnetIdentifier': 'my_subnet_2',
                'SubnetAvailabilityZone': {
                    'Name': 'us-east-1d'
                },
                'SubnetStatus': 'Active'
            }
            ...
        ],
        'SupportedNetworkTypes': [
            'IPV4'
        ]
    }
}

Zu diesem Zeitpunkt haben Sie den Klon noch nicht erstellt. Sie haben alle relevanten VPC- und Subnetzressourcen erstellt, sodass Sie beim Erstellen des Klons die entsprechenden Parameter für die Befehle restore-db-cluster-to-point-in-time und create-db-instance angeben können.

Erstellen eines Aurora-Klons mit neuen Netzwerkeinstellungen

Sobald Sie sichergestellt haben, dass die richtige Konfiguration von VPCs, Subnetzen, AZs und Subnetzgruppen für den neuen Cluster vorhanden ist, können Sie den eigentlichen Klonvorgang durchführen. In den folgenden CLI-Beispielen werden die Optionen wie --db-subnet-group-name, --availability-zone und --vpc-security-group-ids hervorgehoben, die Sie in den Befehlen zum Einrichten des Klons und seiner DB-Instances angeben.

Schritt 1: Angeben der DB-Subnetzgruppe für den Klon

Wenn Sie den Klon erstellen, können Sie die richtigen VPC-, Subnetz- und AZ-Einstellungen konfigurieren, indem Sie eine DB-Subnetzgruppe angeben. Verwenden Sie die Befehle in den vorherigen Beispielen, um alle Beziehungen und Zuordnungen zu überprüfen, die zur DB-Subnetzgruppe gehören.

Die folgenden Befehle veranschaulichen beispielsweise das Klonen eines ursprünglichen Clusters in einen Klon. Im ersten Beispiel ist der Quellcluster mit zwei Subnetzen und der Klon mit drei Subnetzen verknüpft. Das zweite Beispiel zeigt den umgekehrten Fall, nämlich das Klonen von einem Cluster mit drei Subnetzen zu einem Cluster mit zwei Subnetzen.

aws rds restore-db-cluster-to-point-in-time \
  --source-db-cluster-identifier cluster-with-3-subnets \
  --db-cluster-identifier cluster-cloned-to-2-subnets \
  --restore-type copy-on-write --use-latest-restorable-time \
  --db-subnet-group-name two-subnets

Wenn Sie beabsichtigen, Aurora-Serverless-v2-Instances im Klon zu verwenden, fügen Sie bei der Erstellung des Klons eine --serverless-v2-scaling-configuration-Option hinzu, wie hier gezeigt. Auf diese Weise können Sie die db.serverless-Klasse verwenden, wenn Sie DB-Instances im Klon erstellen. Sie können den Klon auch später ändern, um dieses Attribut für die Skalierungskonfiguration hinzuzufügen. Die Kapazitätswerte in diesem Beispiel ermöglichen es jeder Serverless-v2-Instance im Cluster, zwischen 2 und 32 Aurora Capacity Units (ACUs) zu skalieren. Informationen zur Aurora-Serverless-v2-Funktion und zur Auswahl des Kapazitätsbereichs finden Sie unter Verwenden von Aurora Serverless v2.

aws rds restore-db-cluster-to-point-in-time \
  --source-db-cluster-identifier cluster-with-2-subnets \
  --db-cluster-identifier cluster-cloned-to-3-subnets \
  --restore-type copy-on-write --use-latest-restorable-time \
  --db-subnet-group-name three-subnets \
  --serverless-v2-scaling-configuration 'MinCapacity=2,MaxCapacity=32'

Unabhängig von der Anzahl der von den DB-Instances verwendeten Subnetze ist der Aurora-Speicher für den Quell-Cluster und den Klon drei AZs zugeordnet. Das folgende Beispiel listet die AZs auf, die sowohl dem ursprünglichen Cluster als auch dem Klon zugeordnet sind, und zwar für beide restore-db-cluster-to-point-in-time-Befehle in den vorherigen Beispielen.

aws rds describe-db-clusters --db-cluster-identifier cluster-with-3-subnets \
  --query 'sort_by(*[].AvailabilityZones[].{Zone:@},&Zone)' --output text

us-east-1c
us-east-1d
us-east-1f

aws rds describe-db-clusters --db-cluster-identifier cluster-cloned-to-2-subnets \
  --query 'sort_by(*[].AvailabilityZones[].{Zone:@},&Zone)' --output text

us-east-1c
us-east-1d
us-east-1f

aws rds describe-db-clusters --db-cluster-identifier cluster-with-2-subnets \
  --query 'sort_by(*[].AvailabilityZones[].{Zone:@},&Zone)' --output text

us-east-1a
us-east-1c
us-east-1d

aws rds describe-db-clusters --db-cluster-identifier cluster-cloned-to-3-subnets \
  --query 'sort_by(*[].AvailabilityZones[].{Zone:@},&Zone)' --output text

us-east-1a
us-east-1c
us-east-1d

Da sich mindestens zwei der AZs zwischen jedem Paar aus Original- und Kloncluster überschneiden, können beide Cluster auf denselben zugrunde liegenden Aurora-Speicher zugreifen.

Schritt 2: Angeben der Netzwerkeinstellungen für Instances im Klon

Wenn Sie DB-Instances im Klon erstellen, erben diese standardmäßig die DB-Subnetzgruppe vom Cluster selbst. Auf diese Weise weist Aurora jede Instance automatisch einem bestimmten Subnetz zu und erstellt sie in der AZ, die dem Subnetz zugeordnet ist. Diese Wahl ist besonders für Entwicklungs- und Testsysteme praktisch, da Sie beim Hinzufügen neuer Instances zum Klon nicht die Subnetz-IDs oder AZs im Auge behalten müssen.

Als Alternative können Sie die AZ angeben, wenn Sie eine Aurora-DB-Instance für den Klon erstellen. Die AZ, die Sie angeben, muss aus der Gruppe von AZs stammen, die dem Klon zugeordnet sind. Wenn die DB-Subnetzgruppe, die Sie für den Klon verwenden, nur zwei Subnetze enthält, können Sie nur aus den AZs auswählen, die diesen beiden Subnetzen zugeordnet sind. Diese Wahl bietet Flexibilität und Resilienz für Systeme mit hoher Verfügbarkeit, da Sie sicherstellen können, dass sich die Writer-Instance und die Standby-Reader-Instance in unterschiedlichen AZs befinden. Oder wenn Sie dem Cluster weitere Reader hinzufügen, können Sie sicherstellen, dass diese auf drei AZs verteilt sind. Auf diese Weise haben Sie selbst im seltenen Fall eines AZ-Ausfalls immer noch eine Writer-Instance und eine weitere Reader-Instance in zwei anderen AZs.

Das folgende Beispiel fügt einem geklonten Aurora-PostgreSQL-Cluster, der eine benutzerdefinierte DB-Subnetzgruppe verwendet, eine bereitgestellte DB-Instance hinzu.

aws rds create-db-instance --db-cluster-identifier my_aurora_postgresql_clone \
  --db-instance-identifier my_postgres_instance \
  --db-subnet-group-name my_new_subnet \
  --engine aurora-postgresql \
  --db-instance-class db.t4g.medium

Das folgende Beispiel zeigt die teilweise Ausgabe eines solchen Befehls.

{
  'DBInstanceIdentifier': 'my_postgres_instance',
  'DBClusterIdentifier': 'my_aurora_postgresql_clone',
  'DBInstanceClass': 'db.t4g.medium',
  'DBInstanceStatus': 'creating'
  ...
}

Das folgende Beispiel fügt eine Aurora-Serverless-v2-DB-Instance zu einem Aurora-MySQL-Klon hinzu, der eine benutzerdefinierte DB-Subnetzgruppe verwendet. Um Serverless-v2-Instances verwenden zu können, stellen Sie sicher, dass Sie die --serverless-v2-scaling-configuration-Option für den restore-db-cluster-to-point-in-time-Befehl angeben, wie in den vorherigen Beispielen gezeigt.

aws rds create-db-instance --db-cluster-identifier my_aurora_mysql_clone \
  --db-instance-identifier my_mysql_instance \
  --db-subnet-group-name my_other_new_subnet \
  --engine aurora-mysql \
  --db-instance-class db.serverless

Das folgende Beispiel zeigt die teilweise Ausgabe eines solchen Befehls.

{
  'DBInstanceIdentifier': 'my_mysql_instance',
  'DBClusterIdentifier': 'my_aurora_mysql_clone',
  'DBInstanceClass': 'db.serverless',
  'DBInstanceStatus': 'creating'
  ...
}

Schritt 3: Herstellen der Konnektivität zwischen einem Clientsystem und einem Klon

Wenn Sie bereits von einem Clientsystem aus eine Verbindung zu einem Aurora-Cluster herstellen, sollten Sie dieselbe Art von Konnektivität für einen neuen Klon zulassen. Beispielsweise können Sie über eine Amazon-Cloud9-Instance oder EC2-Instance eine Verbindung mit dem ursprünglichen Cluster herstellen. Um Verbindungen von denselben oder neuen Clientsystemen, die Sie in der Ziel-VPC erstellen, zuzulassen, richten Sie äquivalente DB-Subnetzgruppen und VPC-Sicherheitsgruppen wie in der VPC ein. Geben Sie dann die Subnetzgruppe und die Sicherheitsgruppen an, wenn Sie den Klon erstellen.

In den folgenden Beispielen wird ein Aurora-Serverless-v2-Klon eingerichtet. Diese Konfiguration basiert auf der Kombination von --engine-mode provisioned und --serverless-v2-scaling-configuration bei der Erstellung des DB-Clusters und dann --db-instance-class db.serverless bei der Erstellung der einzelnen DB-Instances im Cluster. Der Engine-Modus provisioned ist die Standardeinstellung, sodass Sie diese Option auch weglassen können, wenn Sie dies bevorzugen.

aws rds restore-db-cluster-to-point-in-time \
  --source-db-cluster-identifier serverless-sql-postgres\
  --db-cluster-identifier serverless-sql-postgres-clone \
  --db-subnet-group-name 'default-vpc-1234' \
  --vpc-security-group-ids 'sg-4567' \
  --serverless-v2-scaling-configuration 'MinCapacity=0.5,MaxCapacity=16' \
  --restore-type copy-on-write \
  --use-latest-restorable-time

Geben Sie dann beim Erstellen der DB-Instances im Klon dieselbe --db-subnet-group-name-Option an. Optional können Sie die --availability-zone-Option einschließen und eine der AZs angeben, die den Subnetzen in dieser Subnetzgruppe zugeordnet sind. Diese AZ muss auch eine der AZs sein, die dem ursprünglichen Cluster zugeordnet sind.

aws rds create-db-instance \
  --db-cluster-identifier serverless-sql-postgres-clone \
  --db-instance-identifier serverless-sql-postgres-clone-instance \
  --db-instance-class db.serverless \
  --db-subnet-group-name 'default-vpc-987zyx654' \
  --availability-zone 'us-east-1c' \
  --engine aurora-postgresql

Verschieben eines Clusters aus öffentlichen Subnetzen in private

Mithilfe des Klonens können Sie einen Cluster zwischen öffentlichen und privaten Subnetzen migrieren. Sie können dies tun, wenn Sie Ihrer Anwendung zusätzliche Sicherheitsebenen hinzufügen, bevor Sie sie in der Produktion einsetzen. In diesem Beispiel sollten Sie die privaten Subnetze und das NAT-Gateway bereits eingerichtet haben, bevor Sie den Klonvorgang mit Aurora starten.

Für die Schritte, an denen Aurora beteiligt ist, können Sie dieselben allgemeinen Schritte wie in den vorherigen Beispielen für Sammeln von Informationen über die Netzwerkumgebung und Erstellen eines Aurora-Klons mit neuen Netzwerkeinstellungen befolgen. Der Hauptunterschied besteht darin, dass Sie, selbst wenn Sie über öffentliche Subnetze verfügen, die allen AZs des ursprünglichen Clusters zugeordnet sind, jetzt überprüfen müssen, ob Sie über genügend private Subnetze für einen Aurora-Cluster verfügen. Außerdem müssen diese Subnetze allen AZs zugeordnet sein, die für Aurora-Speicher im ursprünglichen Cluster verwendet werden. Ähnlich wie bei anderen Anwendungsfällen des Klonens können Sie die DB-Subnetzgruppe für den Klon entweder mit drei oder zwei privaten Subnetzen erstellen, die den erforderlichen AZs zugeordnet sind. Wenn Sie jedoch zwei private Subnetze in der DB-Subnetzgruppe verwenden, benötigen Sie ein drittes privates Subnetz, das der dritten AZ zugeordnet ist, die für Aurora-Speicher im ursprünglichen Cluster verwendet wird.

Anhand dieser Checkliste können Sie überprüfen, ob alle Voraussetzungen für diese Art von Klonvorgang erfüllt sind.

Wenn alle Voraussetzungen erfüllt sind, können Sie die Datenbankaktivität auf dem ursprünglichen Cluster pausieren, während Sie den Klon erstellen, und Ihre Anwendung auf die Verwendung des Klons umstellen. Nachdem der Klon erstellt wurde und Sie sich vergewissert haben, dass eine Verbindung dazu hergestellt werden kann, Sie Ihren Anwendungscode ausführen können usw., können Sie die Verwendung des ursprünglichen Clusters einstellen.

Umfassendes Beispiel für das Erstellen eines VPC-Klons

Beim Erstellen eines Klons in einer anderen VPC als dem Original werden dieselben allgemeinen Schritte wie in den vorherigen Beispielen ausgeführt. Da die VPC-ID eine Eigenschaft der Subnetze ist, geben Sie die VPC-ID nicht als Parameter an, wenn Sie einen der RDS-CLI-Befehle ausführen. Der Hauptunterschied besteht darin, dass Sie mit größerer Wahrscheinlichkeit neue Subnetze, neue Subnetze, die bestimmten AZs zugeordnet sind, eine VPC-Sicherheitsgruppe und eine neue DB-Subnetzgruppe erstellen müssen. Dies gilt insbesondere, wenn dies der erste Aurora-Cluster ist, den Sie in dieser VPC erstellen.

Anhand dieser Checkliste können Sie überprüfen, ob alle Voraussetzungen für diese Art von Klonvorgang erfüllt sind.

Wenn alle Voraussetzungen erfüllt sind, können Sie die Datenbankaktivität auf dem ursprünglichen Cluster pausieren, während Sie den Klon erstellen, und Ihre Anwendung auf die Verwendung des Klons umstellen. Nachdem der Klon erstellt wurde und Sie sich vergewissert haben, dass eine Verbindung dazu hergestellt werden kann, Sie Ihren Anwendungscode ausführen können usw., können Sie entscheiden, ob sowohl der ursprüngliche Cluster als auch die Klone ausgeführt werden sollen, oder die Ausführung des ursprünglichen Clusters einstellen.

Die folgenden Linux-Beispiele zeigen die Abfolge der AWS-CLI-Operationen zum Klonen eines Aurora-DB-Clusters von einer VPC in eine andere. Einige Felder, die für die Beispiele nicht relevant sind, werden in der Befehlsausgabe nicht angezeigt.

Zunächst überprüfen wir die IDs der Quell- und Ziel-VPCs. Der beschreibende Name, den Sie einer VPC bei ihrer Erstellung zuweisen, wird in den VPC-Metadaten als Tag dargestellt.

$ aws ec2 describe-vpcs --query '*[].[VpcId,Tags]'
[
    [
        'vpc-0f0c0fc0000b0ffb0',
        [
            {
                'Key': 'Name',
                'Value': 'clone-vpc-source'
            }
        ]
    ],
    [
        'vpc-9e99d9f99a999bd99',
        [
            {
                'Key': 'Name',
                'Value': 'clone-vpc-dest'
            }
        ]
    ]
]

Der ursprüngliche Cluster ist bereits in der Quell-VPC vorhanden. Um den Klon mit demselben Satz von AZs für den Aurora-Speicher einzurichten, überprüfen wir die AZs, die vom ursprünglichen Cluster verwendet werden.

$ aws rds describe-db-clusters --db-cluster-identifier original-cluster \
  --query 'sort_by(*[].AvailabilityZones[].{Zone:@},&Zone)' --output text

us-east-1c
us-east-1d
us-east-1f

Wir stellen sicher, dass Subnetze vorhanden sind, die den vom ursprünglichen Cluster verwendeten AZs entsprechen: us-east-1c, us-east-1d und us-east-1f.

$ aws ec2 create-subnet --vpc-id vpc-9e99d9f99a999bd99 \
  --availability-zone us-east-1c --cidr-block 10.0.0.128/28
{
    'Subnet': {
        'AvailabilityZone': 'us-east-1c',
        'SubnetId': 'subnet-3333a33be3ef3e333',
        'VpcId': 'vpc-9e99d9f99a999bd99',
    }
}

$ aws ec2 create-subnet --vpc-id vpc-9e99d9f99a999bd99 \
--availability-zone us-east-1d --cidr-block 10.0.0.160/28
{
    'Subnet': {
        'AvailabilityZone': 'us-east-1d',
        'SubnetId': 'subnet-4eeb444cd44b4d444',
        'VpcId': 'vpc-9e99d9f99a999bd99',
    }
}

$ aws ec2 create-subnet --vpc-id vpc-9e99d9f99a999bd99 \
--availability-zone us-east-1f --cidr-block 10.0.0.224/28
{
    'Subnet': {
        'AvailabilityZone': 'us-east-1f',
        'SubnetId': 'subnet-66eea6666fb66d66c',
        'VpcId': 'vpc-9e99d9f99a999bd99',
    }
}

Dieses Beispiel bestätigt, dass es Subnetze gibt, die den erforderlichen AZs in der Ziel-VPC zugeordnet sind.

aws ec2 describe-subnets --query 'sort_by(*[] | [?VpcId == `vpc-9e99d9f99a999bd99`] |
[].{SubnetId:SubnetId,VpcId:VpcId,AvailabilityZone:AvailabilityZone}, &AvailabilityZone)' --output table

---------------------------------------------------------------------------
|                             DescribeSubnets                             |
+------------------+----------------------------+-------------------------+
| AvailabilityZone |         SubnetId           |          VpcId          |
+------------------+----------------------------+-------------------------+
|  us-east-1a      |  subnet-000ff0e00000c0aea  |  vpc-9e99d9f99a999bd99  |
|  us-east-1b      |  subnet-1111d111111ca11b1  |  vpc-9e99d9f99a999bd99  |
|  us-east-1c      | subnet-3333a33be3ef3e333   |  vpc-9e99d9f99a999bd99  |
|  us-east-1d      | subnet-4eeb444cd44b4d444   |  vpc-9e99d9f99a999bd99  |
|  us-east-1f      | subnet-66eea6666fb66d66c   |  vpc-9e99d9f99a999bd99  |
+------------------+----------------------------+-------------------------+

Bevor Sie einen Aurora-DB-Cluster in der VPC erstellen, benötigen Sie eine DB-Subnetzgruppe mit Subnetzen, die den für Aurora-Speicher verwendeten AZs zugeordnet sind. Wenn Sie einen regulären Cluster erstellen, können Sie einen beliebigen Satz von drei AZs verwenden. Wenn Sie einen vorhandenen Cluster klonen, muss die Subnetzgruppe mit mindestens zwei der drei AZs übereinstimmen, die für Aurora-Speicher verwendet werden.

$ aws rds create-db-subnet-group \
  --db-subnet-group-name subnet-group-in-other-vpc \
  --subnet-ids '["subnet-3333a33be3ef3e333","subnet-4eeb444cd44b4d444","subnet-66eea6666fb66d66c"]' \
  --db-subnet-group-description 'DB subnet group with 3 subnets: subnet-3333a33be3ef3e333,subnet-4eeb444cd44b4d444,subnet-66eea6666fb66d66c'

{
    'DBSubnetGroup': {
        'DBSubnetGroupName': 'subnet-group-in-other-vpc',
        'DBSubnetGroupDescription': 'DB subnet group with 3 subnets: subnet-3333a33be3ef3e333,subnet-4eeb444cd44b4d444,subnet-66eea6666fb66d66c',
        'VpcId': 'vpc-9e99d9f99a999bd99',
        'SubnetGroupStatus': 'Complete',
        'Subnets': [
            {
                'SubnetIdentifier': 'subnet-4eeb444cd44b4d444',
                'SubnetAvailabilityZone': { 'Name': 'us-east-1d' }
            },
            {
                'SubnetIdentifier': 'subnet-3333a33be3ef3e333',
                'SubnetAvailabilityZone': { 'Name': 'us-east-1c' }
            },
            {
                'SubnetIdentifier': 'subnet-66eea6666fb66d66c',
                'SubnetAvailabilityZone': { 'Name': 'us-east-1f' }
            }
        ]
    }
}

Jetzt sind die Subnetze und die DB-Subnetzgruppe eingerichtet. Das folgende Beispiel zeigt restore-db-cluster-to-point-in-time, womit der Cluster geklont wird. Die --db-subnet-group-name-Option ordnet den Klon dem richtigen Satz von Subnetzen zu, die wiederum dem richtigen Satz von AZs aus dem ursprünglichen Cluster zugeordnet sind.

$ aws rds restore-db-cluster-to-point-in-time \
  --source-db-cluster-identifier original-cluster \
  --db-cluster-identifier clone-in-other-vpc \
  --restore-type copy-on-write --use-latest-restorable-time \
  --db-subnet-group-name subnet-group-in-other-vpc

{
  'DBClusterIdentifier': 'clone-in-other-vpc',
  'DBSubnetGroup': 'subnet-group-in-other-vpc',
  'Engine': 'aurora-postgresql',
  'EngineVersion': '15.4',
  'Status': 'creating',
  'Endpoint': 'clone-in-other-vpc.cluster-c0abcdef.us-east-1.rds.amazonaws.com'
}

Im folgenden Beispiel wird bestätigt, dass der Aurora-Speicher im Klon denselben Satz von AZs wie im ursprünglichen Cluster verwendet.

$ aws rds describe-db-clusters --db-cluster-identifier clone-in-other-vpc \
  --query 'sort_by(*[].AvailabilityZones[].{Zone:@},&Zone)' --output text

us-east-1c
us-east-1d
us-east-1f

Nun können Sie DB-Instances für den Klon erstellen. Stellen Sie sicher, dass die jeder Instance zugeordnete VPC-Sicherheitsgruppe Verbindungen aus den IP-Adressbereichen zulässt, die Sie für die EC2-Instances, Anwendungsserver usw. in der Ziel-VPC verwenden.