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.

VPCKreuzklonen mit Amazon Aurora

Angenommen, Sie möchten dem ursprünglichen Cluster und dem Clone unterschiedliche Netzwerkzugriffskontrollen auferlegen. Sie können das Klonen beispielsweise verwenden, um eine Kopie eines Aurora-Produktionsclusters in einem anderen zu Entwicklungs- und VPC Testzwecken zu erstellen. Oder Sie können im Rahmen einer Migration von öffentlichen Subnetzen zu privaten Subnetzen einen Klon erstellen, um Ihre Datenbanksicherheit zu erhöhen.

In den folgenden Abschnitten wird gezeigt, wie die Netzwerkkonfiguration für den Clone so eingerichtet wird, dass der ursprüngliche Cluster und der Clone beide auf dieselben Aurora-Speicherknoten zugreifen können, auch von unterschiedlichen Subnetzen aus. VPCs 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 Subnetzen und DB-Subnetzgruppen interagiert, finden Sie zuerst weitere Informationen. VPCs 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 EC2 Diensten RDS und beinhalten, werden in den Beispielen AWS CLI Befehle verwendet, damit Sie verstehen, wie Sie solche Vorgänge automatisieren und die Ausgabe speichern können.

Bevor Sie beginnen

Bevor Sie mit der Einrichtung eines VPC Cross-Clones beginnen, stellen Sie sicher, dass Sie über die folgenden Ressourcen verfügen:

Sammeln von Informationen über die Netzwerkumgebung

Beim VPC Cross-Cloning kann sich die Netzwerkumgebung zwischen dem ursprünglichen Cluster und seinem Klon erheblich unterscheiden. Bevor Sie den Clone erstellen, sollten Sie Informationen über die Subnetze und die VPC DB-Subnetzgruppe sammeln und aufzeichnen, die im ursprünglichen AZs 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. In den folgenden Abschnitten finden Sie CLI Beispiele für die Erfassung dieser Art von Informationen. Sie können die Details in einem beliebigen Format speichern, das Sie bei der Erstellung des Klons und bei der Problembehandlung verwenden können.

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

Bevor Sie den Clone erstellen, überprüfen Sie, welche AZs der ursprüngliche Cluster für seinen Speicher verwendet. Wie unter erklärtAmazon Aurora Aurora-Speicher, ist der Speicher für jeden Aurora-Cluster genau drei zugeordnetAZs. Da Amazon-Aurora-DB-Cluster sich der Vorteil der Trennung von Rechenleistung und Speicher zunutze macht, gilt diese Regel unabhängig davon, wie viele Instanzen sich im Cluster befinden.

Führen Sie beispielsweise einen CLI Befehl wie den folgenden aus und ersetzen Sie dabei Ihren eigenen Clusternamen durch. my_cluster 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 des vorherigen describe-db-clusters Befehls. Es zeigt, dass der Speicher für den Aurora-Cluster immer drei verwendetAZs.

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

Um einen Clone in einer Netzwerkumgebung zu erstellen, in der nicht alle Ressourcen vorhanden sind, um eine Verbindung zu diesen herzustellenAZs, müssen Sie Subnetze erstellen, die mindestens zwei davon zugeordnet sindAZs, und dann eine DB-Subnetzgruppe erstellen, die diese zwei oder drei Subnetze enthält. Die folgenden Beispiele zeigen, wie das geht.

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

Wenn Sie dieselbe Anzahl von Subnetzen für den Clone 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, mit welchen Subnetzen AZs die Subnetze verknüpft sind.

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

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 two-subnets handelt es sich um einen Namen, der bei der Erstellung der DB-Subnetzgruppe angegeben wurde.

two-subnets

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

Bei einem Cluster, in 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 Sie die 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 demselben VPC verwenden oder Subnetze mit ähnlichen Eigenschaften in einem anderen erstellen möchten. VPC

Suchen Sie das Subnetz IDs aller Subnetze, die in Ihrem verfügbar sind. VPC

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

Finden 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. Ersetzen Sie die Namen Ihrer Subnetze usw. my_subnet_1

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 VPC die, 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 die Availability Zones der DB-Instances im ursprünglichen Cluster

Sie können dieses Verfahren verwenden, um zu verstehen, welche für die DB-Instances im ursprünglichen Cluster AZs verwendet wurden. Auf diese Weise können Sie genau dasselbe AZs für die DB-Instances im Clone einrichten. Sie können auch mehr oder weniger DB-Instances im Clone verwenden, je nachdem, ob der Clone für Produktion, Entwicklung und Tests usw. verwendet wird.

Führen Sie für jede Instance im ursprünglichen Cluster einen Befehl wie den folgenden aus. Stellen Sie zunächst sicher, dass die Instanz die Erstellung abgeschlossen hat und sich im Available Status befindet. Ersetzen Sie die Instanz-ID durchmy_instance.

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

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

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

Nachdem der Clone 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 dasselbe konfiguriert sind AZs wie im ursprünglichen Cluster.

Schritt 5: Überprüfen Sie, ob VPCs Sie das für den Clone verwenden können

Wenn Sie beabsichtigen, den Klon auf einem anderen VPC als dem Original zu erstellen, können Sie sich eine Liste der für Ihr Konto VPC IDs verfügbaren Dateien anzeigen lassen. Sie können diesen Schritt auch ausführen, wenn Sie zusätzliche Subnetze im gleichen Cluster VPC wie im ursprünglichen 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 aufzulisten:

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

Das folgende Beispiel zeigt eine Beispielausgabe des vorherigen describe-vpcs Befehls. Die Ausgabe zeigt, dass das aktuelle AWS Konto vier VPCs enthält, die als Quelle oder Ziel für VPC Cross-Cloning verwendet werden können.

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

Sie können dasselbe VPC Ziel für den Clone oder ein anderes VPC verwenden. Wenn sich der ursprüngliche Cluster und der Clone im selben befindenVPC, können Sie dieselbe DB-Subnetzgruppe für den Clone 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 Clone in einem anderen Cluster erstellenVPC, stellen Sie sicher, dass im neuen Cluster genügend Subnetze vorhanden sind VPC und dass die Subnetze mit den Rechten aus dem ursprünglichen Cluster verknüpft sind. AZs

Netzwerkressourcen für den Clone erstellen

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

Schritt 1: Erstellen Sie die Subnetze für den Clone

Wenn Sie neue Subnetze für den Clone erstellen müssen, führen Sie einen Befehl aus, der dem folgenden ähnelt. Möglicherweise müssen Sie dies tun, wenn Sie den Clone in einem anderen erstellen oder wenn Sie eine andere Netzwerkänderung vornehmenVPC, z. B. private Subnetze anstelle von öffentlichen Subnetzen verwenden.

AWS generiert automatisch die ID des Subnetzes. Ersetzen Sie den Namen der Klone durch. VPC my_vpc Wählen Sie den Adressbereich für die --cidr-block Option, um mindestens 16 IP-Adressen in dem Bereich zuzulassen. Sie können alle anderen Eigenschaften einbeziehen, die Sie angeben möchten. Führen Sie den Befehl ausaws ec2 create-subnet help, 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 Sie die DB-Subnetzgruppe für den Clone

Wenn Sie den Clone in einem anderen oder einer anderen VPC Gruppe von Subnetzen innerhalb desselben erstellenVPC, erstellen Sie eine neue DB-Subnetzgruppe und geben sie bei der Erstellung des Clones an.

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

Prüfen Sie, wie AZs viele davon sowohl dem Speicher des ursprünglichen Clusters als auch den Subnetzen im Zielcluster zugeordnet sind. VPC Um den Clone erfolgreich zu erstellen, müssen zwei oder drei AZs Gemeinsamkeiten vorhanden sein. Wenn Sie weniger als zwei AZs gemeinsam haben, gehen Sie zurück zuSchritt 1: Erstellen Sie die Subnetze für den Clone. Erstellen Sie ein, zwei oder drei neue Subnetze, die dem Speicher des ursprünglichen Clusters AZs zugeordnet sind.

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

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

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 eine teilweise Ausgabe des create-db-subnet-group Befehls.

{
    '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 wirklich erstellt. Sie haben alle relevanten Ressourcen VPC und Subnetzressourcen erstellt, sodass Sie bei der Erstellung des Klons die entsprechenden Parameter für die create-db-instance Befehle restore-db-cluster-to-point-in-time und angeben können.

Einen Aurora-Clone mit neuen Netzwerkeinstellungen erstellen

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

Schritt 1: Geben Sie die DB-Subnetzgruppe für den Clone an

Wenn Sie den Clone erstellen, können Sie alle Rechte-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 Clone zu verwenden, fügen Sie bei der Erstellung des Clones eine --serverless-v2-scaling-configuration Option hinzu, wie in der Abbildung gezeigt. Auf diese Weise können Sie die db.serverless Klasse verwenden, wenn Sie DB-Instances im Clone erstellen. Sie können den Klon auch später ändern, um dieses Skalierungskonfigurationsattribut hinzuzufügen. Die Kapazitätszahlen in diesem Beispiel ermöglichen es jeder Serverless v2-Instance im Cluster, zwischen 2 und 32 Aurora-Kapazitätseinheiten (ACUs) zu skalieren. Informationen zur Aurora Serverless v2-Funktion und zur Auswahl des Kapazitätsbereichs finden Sie unterVerwenden 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 Subnetze, die von den DB-Instances verwendet werden, ist der Aurora-Speicher für den Quell-Cluster und den Clone drei AZs zugeordnet. Im folgenden Beispiel werden die Befehle aufgeführt, die sowohl dem ursprünglichen Cluster als auch dem Clone AZs 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 beiden ursprünglichen Cluster und der Klon-Cluster AZs überschneiden, können beide Cluster auf denselben zugrunde liegenden Aurora-Speicher zugreifen.

Schritt 2: Geben Sie die Netzwerkeinstellungen für Instances im Clone an

Wenn Sie DB-Instances im Clone 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 nicht den Überblick über das Subnetz IDs oder das Hinzufügen neuer Instances zum AZs Clone behalten müssen.

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

Das folgende Beispiel fügt einem geklonten Aurora SQL Postgre-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 My SQL Clone 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 eine 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 Clone

Wenn Sie bereits von einem Clientsystem aus eine Verbindung zu einem Aurora-Cluster herstellen, möchten Sie möglicherweise dieselbe Art von Konnektivität für einen neuen Clone zulassen. Sie können beispielsweise von einer Amazon Cloud9-Instance oder EC2 -Instance aus eine Verbindung zum ursprünglichen Cluster herstellen. Um Verbindungen von denselben oder neuen Clientsystemen, die Sie im Ziel erstellen, zuzulassenVPC, richten Sie äquivalente DB-Subnetzgruppen und VPC Sicherheitsgruppen ein wie in der. VPC Geben Sie dann die Subnetzgruppe und die Sicherheitsgruppen an, wenn Sie den Clone erstellen.

In den folgenden Beispielen wird ein Aurora Serverless v2-Clone 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 jeder DB-Instance im Cluster. Der provisioned Engine-Modus 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 Clone dieselbe --db-subnet-group-name Option an. Optional können Sie die --availability-zone Option einbeziehen und eines der den Subnetzen in dieser Subnetzgruppe AZs zugewiesenen Optionen angeben. Bei dieser AZ muss es sich auch um eine der mit dem ursprünglichen Cluster AZs verknüpften Domänen handeln.

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 von öffentlichen Subnetzen in private

Sie können das Klonen verwenden, um einen Cluster zwischen öffentlichen und privaten Subnetzen zu 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, die Aurora betreffen, können Sie dieselben allgemeinen Schritte wie in den vorherigen Beispielen für Sammeln von Informationen über die Netzwerkumgebung und befolgenEinen Aurora-Clone mit neuen Netzwerkeinstellungen erstellen. Der Hauptunterschied besteht darin, dass Sie, selbst wenn Sie öffentliche Subnetze haben, die allen AZs aus dem ursprünglichen Cluster zugeordnet sind, jetzt überprüfen müssen, ob Sie über genügend private Subnetze für einen Aurora-Cluster verfügen und dass diese Subnetze allen Subnetzen zugeordnet sind, die für den Aurora-Speicher im ursprünglichen Cluster verwendet wurden. AZs Ähnlich wie bei anderen Anwendungsfällen beim Klonen können Sie die DB-Subnetzgruppe für den Clone mit entweder drei oder zwei privaten Subnetzen erstellen, die den erforderlichen Subnetzen zugeordnet sind. AZs 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 unterbrechen, während Sie den Clone erstellen, und Ihre Anwendung so einstellen, dass er verwendet wird. Nachdem der Clone erstellt wurde und Sie sich vergewissert haben, dass Sie eine Verbindung zu ihm herstellen, Ihren Anwendungscode ausführen usw. können, können Sie die Verwendung des ursprünglichen Clusters einstellen.

nd-to-end Ein Beispiel für die Erstellung eines Cross-Clones VPC

Beim Erstellen eines Klons in einem anderen Format VPC als dem Original werden dieselben allgemeinen Schritte wie in den vorherigen Beispielen verwendet. Da es sich bei der VPC ID um eine Eigenschaft der Subnetze handelt, geben Sie die VPC ID nicht wirklich 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 Subnetzen zugeordnet sindAZs, eine VPC Sicherheitsgruppe und eine neue DB-Subnetzgruppe erstellen müssen. Das gilt insbesondere, wenn dies der erste Aurora-Cluster ist, den Sie darin erstellenVPC.

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

Wenn alle Voraussetzungen erfüllt sind, können Sie die Datenbankaktivität auf dem ursprünglichen Cluster unterbrechen, während Sie den Clone erstellen, und Ihre Anwendung so einstellen, dass er verwendet wird. Nachdem der Clone erstellt wurde und Sie sich vergewissert haben, dass Sie eine Verbindung zu ihm herstellen, Ihren Anwendungscode ausführen usw. können, können Sie überlegen, ob Sie sowohl das Original als auch die Klone weiterlaufen lassen oder die Verwendung des ursprünglichen Clusters einstellen möchten.

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

Zuerst überprüfen wir die IDs Quelle und das ZielVPCs. Der beschreibende Name, den Sie einem VPC bei der 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 Quelle VPC vorhanden. Um den Clone mit demselben Satz von AZs für den Aurora-Speicher einzurichten, überprüfen wir die vom ursprünglichen Cluster AZs verwendeten.

$ 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 es Subnetze gibt, die den vom ursprünglichen Cluster AZs verwendeten Subnetzen entsprechen: us-east-1cus-east-1d, undus-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 Subnetzen AZs im Ziel zugeordnet sind. VPC

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 erstellenVPC, benötigen Sie eine DB-Subnetzgruppe mit Subnetzen, die dem für Aurora AZs verwendeten Speicher zugeordnet sind. Wenn Sie einen regulären Cluster erstellen, können Sie einen beliebigen Satz von drei Clustern verwenden. AZs Wenn Sie einen vorhandenen Cluster klonen, muss die Subnetzgruppe mindestens zwei der dreiAZs, die sie für Aurora-Speicher verwendet, entsprechen.

$ 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 vorhanden. Das folgende Beispiel zeigt, restore-db-cluster-to-point-in-time dass der Cluster geklont wird. Die --db-subnet-group-name Option ordnet den Clone dem richtigen Satz von Subnetzen zu, die dem richtigen Satz von Subnetzen 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'
}

Das folgende Beispiel bestätigt, dass der Aurora-Speicher im Clone denselben Satz von verwendet AZs wie im ursprünglichen Cluster.

$ 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

Zu diesem Zeitpunkt können Sie DB-Instances für den Clone 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. verwenden, die sich im Ziel befindenVPC.