Klonen eines Volumes für einen Amazon-Aurora-DB-Cluster - Amazon Aurora
Übersicht über das Aurora-KlonenEinschränkungen für das Aurora-KlonenFunktionsweise des Klonens von AuroraErstellen eines Aurora-KlonsVPC-übergreifendes KlonenKontoübergreifendes Klonen

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.

Klonen eines Volumes für einen Amazon-Aurora-DB-Cluster

Mithilfe der Aurora-Klonfunktion können Sie einen neuen Cluster erstellen, der anfänglich diesselben Datenseiten wie das Original enthält, aber ein separates und unabhängiges Volume darstellt. Der Prozess ist so konzipiert, dass er schnell und kostengünstig ist. Der neue Cluster mit dem zugehörigen Datenvolume wird als clone (Klon) bezeichnet. Das Erstellen eines Klons ist schneller und platzsparender als das physische Kopieren der Daten mit anderen Techniken, wie z. B. das Wiederherstellen eines Snapshots.

Übersicht über das Aurora-Klonen

Aurora verwendet ein copy-on-write Protokoll, um einen Klon zu erstellen. Dieser Mechanismus verwendet minimalen zusätzlichen Speicherplatz, um einen ersten Klon zu erstellen. Wenn der Klon zum ersten Mal erstellt wird, behält Aurora eine einzelne Kopie der Daten, die vom Aurora-DB-Quellcluster und dem neuen (geklonten) Aurora-DB-Cluster verwendet werden. Zusätzlicher Speicher wird nur zugewiesen, wenn Änderungen an Daten (auf dem Aurora-Speicher-Volume) durch den Aurora-DB-Quellcluster oder den Aurora-DB-Clusterklon vorgenommen werden. Weitere Informationen über das copy-on-write Protokoll finden Sie unterFunktionsweise des Klonens von Aurora.

Das Klonen von Aurora ist besonders nützlich, um Testumgebungen mit Ihren Produktionsdaten schnell einzurichten, ohne Datenbeschädigung zu riskieren. Sie können Klone für viele Arten von Anwendungen verwenden, z. B. für Folgende:

  • Experimentieren Sie mit möglichen Änderungen (z. B. Schemaänderungen und Parametergruppenänderungen), um alle Auswirkungen zu bewerten.

  • Führen Sie Workload-intensive Vorgänge aus, z. B. das Exportieren von Daten oder das Ausführen analytischer Abfragen auf dem Klon.

  • Erstellen Sie eine Kopie Ihres Produktions-DB-Clusters zu Entwicklungs-, Test- oder anderen Zwecken.

Sie können mehr als einen Klon aus demselben Aurora-DB-Cluster erstellen. Sie können auch mehrere Klone aus einem anderen Klon erstellen.

Nachdem Sie einen Aurora-Klon erstellt haben, können Sie die Aurora-DB-Instances anders als den Aurora-DB-Quellcluster konfigurieren. Beispielsweise benötigen Sie möglicherweise keinen Klon für Entwicklungszwecke, um dieselben Hochverfügbarkeitsanforderungen zu erfüllen wie der Aurora-DB-Cluster für die Quellproduktion. In diesem Fall können Sie den Klon mit einer einzelnen Aurora-DB-Instance konfigurieren, anstatt mit mehreren DB-Instances, die vom Aurora-DB-Cluster verwendet werden.

Wenn Sie einen Clone mit einer anderen Bereitstellungskonfiguration als der Quelle erstellen, wird der Clone mit der neuesten Nebenversion der Aurora-DB-Engine der Quelle erstellt.

Wenn Sie Klone aus Ihren Aurora-DB-Clustern erstellen, werden die Klone in Ihrem Konto erstellt AWS — demselben Konto, dem der Aurora-DB-Cluster als Quelle gehört. Sie können Aurora-DB-Cluster Aurora Serverless v2 und -Clones jedoch auch mit anderen AWS Konten teilen und bereitstellen. Weitere Informationen finden Sie unter Kontoübergreifendes Klonen mit AWS RAM und Amazon Aurora.

Wenn Sie den Klon für Test-, Entwicklungs- oder andere Zwecke nicht mehr verwenden, können Sie ihn löschen.

Einschränkungen für das Aurora-Klonen

Das Klonen von Aurora hat derzeit die folgenden Einschränkungen:

  • Sie können so viele Klone erstellen, wie Sie möchten, bis zur maximalen Anzahl von DB-Clustern, die in der AWS-Region zulässig sind.

    Sie können die Klone mithilfe des copy-on-write Protokolls oder des vollständigen Kopierprotokolls erstellen. Das Protokoll für die vollständige Kopie funktioniert wie eine Wiederherstellung. point-in-time

  • Sie können keinen Clone in einer anderen AWS Region als dem Aurora-DB-Cluster der Quelle erstellen.

  • Sie können keinen Klon von einem Aurora-DB-Cluster ohne die parallele Abfragefunktion für einen Cluster erstellen, der parallele Abfragen verwendet. Um Daten in einen Cluster zu bringen, der parallele Abfragen verwendet, erstellen Sie einen Snapshot des ursprünglichen Clusters und stellen Sie ihn in dem Cluster wieder her, der die parallele Abfragefunktion verwendet.

  • Sie können keinen Klon aus einem Aurora DB-Cluster erstellen, der keine DB-Instances hat. Sie können nur Aurora-DB-Cluster klonen, die über mindestens eine DB-Instance verfügen.

  • Sie können einen Klon in einer anderen Virtual Private Cloud (VPC) als der des Aurora-DB-Clusters erstellen. In diesem Fall müssen die Subnetze der VPCs denselben Availability Zones zugeordnet sein.

  • Sie können einen von Aurora bereitgestellten Klon aus einem bereitgestellten Aurora-DB-Cluster erstellen.

  • Cluster mit Aurora Serverless v2-Instances folgen den gleichen Regeln wie bereitgestellte Cluster.

  • Aurora Serverless v1:

    • Sie können einen bereitgestellten Clone aus einem Aurora Serverless v1 DB-Cluster erstellen.

    • Sie können einen Aurora Serverless v1 Clone aus einem Aurora Serverless v1 oder einem bereitgestellten DB-Cluster erstellen.

    • Sie können keinen Aurora Serverless v1 Clone aus einem unverschlüsselten, bereitgestellten Aurora-DB-Cluster erstellen.

    • Das kontoübergreifende Klonen unterstützt derzeit das Klonen von Aurora Serverless v1-DB-Clustern nicht. Weitere Informationen finden Sie unter Einschränkungen für kontoübergreifendes Klonen.

    • Ein geklonter Aurora Serverless v1-DB-Cluster hat das gleiche Verhalten und die gleichen Einschränkungen wie jeder Aurora Serverless v1-DB-Cluster. Weitere Informationen finden Sie unter Verwenden von Amazon Aurora Serverless v1.

    • Aurora Serverless v1-DB-Cluster sind immer verschlüsselt. Wenn Sie einen Aurora Serverless v1-DB-Cluster in einen bereitgestellten Aurora-DB-Cluster klonen, wird der bereitgestellte Aurora-DB-Cluster verschlüsselt. Sie können den Verschlüsselungsschlüssel auswählen, aber Sie können die Verschlüsselung nicht deaktivieren. Um von einem bereitgestellten Aurora-DB-Cluster auf einen zu klonenAurora Serverless v1, müssen Sie mit einem verschlüsselten, bereitgestellten Aurora-DB-Cluster beginnen.

Funktionsweise des Klonens von Aurora

Das Klonen von Aurora funktioniert auf der Speicherschicht eines Aurora-DB-Clusters. Es verwendet ein Copy-on-Write-Protokoll, das sowohl schnell als auch platzsparend in Bezug auf die zugrunde liegenden langlebigen Medien ist, die das Aurora-Speichervolumen unterstützen. Weitere Informationen zu Aurora-Cluster-Volumes finden Sie unterÜbersicht über Amazon-Aurora-Speicher.

Das Protokoll verstehen copy-on-write

Ein Aurora-DB-Cluster speichert Daten in Seiten im zugrunde liegenden Aurora-Speicher-Volume.

Im folgenden Diagramm finden Sie beispielsweise einen Aurora-DB-Cluster (A) mit vier Datenseiten 1, 2, 3 und 4. Stellen Sie sich vor, dass ein Klon, Klon B, aus dem Aurora-DB-Cluster erstellt wird. Wenn der Klon erstellt wird, werden keine Daten kopiert. Stattdessen verweist der Klon auf denselben Seitensatz wie der Aurora-DB-Quellcluster.

Amazon-Aurora-Cluster-Volume mit 4 Seiten für Quellcluster A und Klon B

Wenn der Klon erstellt wird, ist normalerweise kein zusätzlicher Speicher erforderlich. Das copy-on-write Protokoll verwendet dasselbe Segment auf dem physischen Speichermedium wie das Quellsegment. Zusätzlicher Speicher ist nur erforderlich, wenn die Kapazität des Quellsegments für das gesamte Klonsegment nicht ausreicht. Wenn dies der Fall ist, wird das Quellsegment auf ein anderes physisches Gerät kopiert.

In den folgenden Diagrammen finden Sie ein Beispiel für das copy-on-write Protokoll in Aktion, das denselben Cluster A und seinen Klon B verwendet, wie oben gezeigt. Nehmen wir an, Sie nehmen eine Änderung an Ihrem Aurora-DB-Cluster (A) vor, was zu einer Änderung der Daten auf Seite 1 führt. Anstatt auf die ursprüngliche Seite 1 zu schreiben, erstellt Aurora eine neue Seite 1 [A]. Das Aurora-DB-Cluster-Volume für Cluster (A) verweist nun auf Seite 1 [A], 2, 3 und 4, während der Klon (B) weiterhin auf die ursprünglichen Seiten verweist.

Amazon-Aurora-Quell-DB-Cluster-Volume und sein Klon, beide mit Änderungen.

Auf dem Klon wird eine Änderung an Seite 4 auf dem Speichervolume vorgenommen. Anstatt auf die ursprüngliche Seite 4 zu schreiben, erstellt Aurora eine neue Seite, 4 [B]. Der Klon verweist nun auf die Seiten 1, 2, 3 und auf Seite 4[B], während der Cluster (A) weiterhin auf 1[A], 2, 3 und 4 verweist.

Amazon-Aurora-Quell-DB-Cluster-Volume und sein Klon, beide mit Änderungen.

Da im Laufe der Zeit mehr Änderungen sowohl im Aurora-DB-Cluster-Quellvolume als auch im Klon auftreten, wird mehr Speicherplatz benötigt, um die Änderungen zu erfassen und zu speichern.

Löschen eines Quell-Cluster-Volumes

Anfänglich verwendet das Klon-Volume dieselben Datenseiten wie das ursprüngliche Volume, aus dem der Clone erstellt wurde. Solange das ursprüngliche Volume existiert, gilt das Clone-Volume nur als Eigentümer der Seiten, die der Clone erstellt oder geändert hat. Die VolumeBytesUsed Metrik für das Klon-Volume ist also zunächst klein und wächst nur, wenn die Daten zwischen dem ursprünglichen Cluster und dem Clone voneinander abweichen. Für Seiten, die zwischen dem Quell-Volume und dem Clone identisch sind, gelten die Speichergebühren nur für den ursprünglichen Cluster. Für weitere Informationen über die VolumeBytesUsed-Metrik siehe Metriken auf Clusterebene für Amazon Aurora.

Wenn Sie ein Quell-Cluster-Volume löschen, dem ein oder mehrere Klone zugeordnet sind, werden die Daten in den Cluster-Volumes der Klone nicht geändert. Aurora behält die Seiten bei, die zuvor dem Quell-Cluster-Volume gehörten. Aurora verteilt die Speicherabrechnung für die Seiten, die dem gelöschten Cluster gehörten, neu. Nehmen wir zum Beispiel an, ein ursprünglicher Cluster hatte zwei Klone und dann wurde der ursprüngliche Cluster gelöscht. Die Hälfte der Datenseiten, die dem ursprünglichen Cluster gehörten, würde jetzt einem Klon gehören. Die andere Hälfte der Seiten würde dem anderen Klon gehören.

Wenn Sie den ursprünglichen Cluster löschen und weitere Klone erstellen oder löschen, verteilt Aurora weiterhin den Besitz der Datenseiten auf alle Klone, die dieselben Seiten gemeinsam nutzen. Daher stellen Sie möglicherweise fest, dass sich der Wert der VolumeBytesUsed Metrik für das Cluster-Volume eines Clones ändert. Der Metrikwert kann sinken, wenn mehr Klone erstellt werden und der Seitenbesitz auf mehr Cluster verteilt wird. Der Metrikwert kann auch steigen, wenn Klone gelöscht werden und der Seitenbesitz einer kleineren Anzahl von Clustern zugewiesen wird. Hinweise dazu, wie sich Schreibvorgänge auf Datenseiten auf Clone-Volumes auswirken, finden Sie unterDas Protokoll verstehen copy-on-write .

Wenn der ursprüngliche Cluster und die Klone demselben AWS Konto gehören, fallen alle Speichergebühren für diese Cluster auf dasselbe AWS Konto an. Wenn es sich bei einigen Clustern um kontenübergreifende Klone handelt, kann das Löschen des ursprünglichen Clusters zu zusätzlichen Speichergebühren für die AWS Konten führen, denen die kontenübergreifenden Klone gehören.

Nehmen wir beispielsweise an, dass ein Cluster-Volume 1000 verwendete Datenseiten hat, bevor Sie Klone erstellen. Wenn Sie diesen Cluster klonen, hat das Klon-Volume zunächst keine verwendeten Seiten. Wenn der Clone Änderungen an 100 Datenseiten vornimmt, werden nur diese 100 Seiten auf dem Clone-Volume gespeichert und als verwendet markiert. Die anderen 900 unveränderten Seiten des übergeordneten Volumes werden von beiden Clustern gemeinsam genutzt. In diesem Fall fallen für den übergeordneten Cluster Speichergebühren für 1000 Seiten und für das Clone-Volume für 100 Seiten an.

Wenn Sie das Quellvolume löschen, umfassen die Speichergebühren für den Clone die 100 Seiten, die er geändert hat, plus die 900 gemeinsam genutzten Seiten aus dem ursprünglichen Volume, also insgesamt 1000 Seiten.

Erstellen eines Amazon-Aurora-DB-Klons

Sie können einen Clone in demselben AWS Konto wie der Aurora-DB-Cluster als Quelle erstellen. Dazu können Sie das AWS Management Console oder das AWS CLI und die folgenden Verfahren verwenden.

Gehen Sie wie unter beschrieben vor, um einem anderen AWS Konto die Erstellung eines Klons oder die gemeinsame Nutzung eines Klons mit einem anderen AWS Konto zu ermöglichenKontoübergreifendes Klonen mit AWS RAM und Amazon Aurora.

Das folgende Verfahren beschreibt das Klonen eines Aurora-DB-Clusters mittels der AWS Management Console.

Erstellen eines Klons anhand der AWS Management Console Ergebnisse in einem Aurora-DB-Cluster mit einer Aurora-DB-Instance.

Diese Anweisungen gelten für DB-Cluster, die demselben AWS Konto gehören, das den Clone erstellt. Wenn der DB-Cluster einem anderen AWS Konto gehört, finden Sie Kontoübergreifendes Klonen mit AWS RAM und Amazon Aurora stattdessen weitere Informationen unter.

Um einen Klon eines DB-Clusters zu erstellen, der Ihrem AWS Konto gehört, verwenden Sie den AWS Management Console

  1. Melden Sie sich bei der Amazon RDS-Konsole an AWS Management Console und öffnen Sie sie unter https://console.aws.amazon.com/rds/.

  2. Wählen Sie im Navigationsbereich Databases (Datenbanken) aus.

  3. Wählen Sie Ihren Aurora-DB-Cluster aus der Liste aus, und wählen Sie für Aktionen die Option Klon erstellen aus.

    Das Erstellen eines Klons beginnt mit der Auswahl Ihres Aurora-DB-Clusters.

    Die Seite „Klon erstellen“ wird geöffnet, auf der Sie Einstellungen, Konnektivität und andere Optionen für den Klon des Aurora-DB-Clusters konfigurieren können.

  4. Geben Sie als DB-Instance-ID den Namen ein, den Sie Ihrem geklonten Aurora-DB-Cluster geben möchten.

  5. Wählen Sie für Aurora Serverless v1 DB-Cluster als Kapazitätstyp „Bereitgestellt“ oder „Serverlos“.

    Sie können Serverless nur auswählen, wenn der Aurora-DB-Quellcluster ein Aurora Serverless v1-DB-Cluster oder ein bereitgestellter Aurora-DB-Cluster ist, der verschlüsselt ist.

  6. Wählen Sie für Aurora Serverless v2 oder bereitgestellte DB-Cluster entweder Aurora I/O-Optimizedoder Aurora Standardfür die Cluster-Speicherkonfiguration aus.

    Weitere Informationen finden Sie unter Speicherkonfigurationen für DB-Cluster von Amazon Aurora.

  7. Wählen Sie die Größe der DB-Instance oder die DB-Cluster-Kapazität aus:

    • Wählen Sie für einen bereitgestellten Clone eine DB-Instance-Klasse aus.

      Um einen bereitgestellten Clone zu erstellen, geben Sie die DB-Instance-Größe an.

      Sie können die bereitgestellte Einstellung akzeptieren oder eine andere DB-Instance-Klasse für Ihren Klon verwenden.

    • Wählen Sie für einen Aurora Serverless v1 Aurora Serverless v2 OR-Klon die Kapazitätseinstellungen aus.

      Um einen Serverless-Klon aus einem Aurora-DB-Cluster zu erstellen, geben Sie die Kapazität an.

      Sie können die bereitgestellten Einstellungen akzeptieren oder sie für Ihren Clone ändern.

  8. Wählen Sie je nach Bedarf weitere Einstellungen für Ihren Clone. Weitere Informationen zu Aurora DB-Cluster- und -Instance-Einstellungen finden Sie unter Erstellen eines Amazon Aurora-DB Clusters.

  9. Wählen Sie „Klon erstellen“.

Wenn der Klon erstellt wird, wird er mit Ihren anderen Aurora-DB-Clustern im Abschnitt Datenbanken der Konsole aufgelistet und zeigt seinen aktuellen Status an. Ihr Klon ist einsatzbereit, wenn sein Status Verfügbar ist.

Die Verwendung des AWS CLI zum Klonen Ihres Aurora-DB-Clusters umfasst einige Schritte.

Der restore-db-cluster-to-point-in-time AWS CLI Befehl, den Sie verwenden, führt zu einem leeren Aurora-DB-Cluster mit 0 Aurora-DB-Instances. Das heißt, der Befehl stellt nur den Aurora-DB-Cluster wieder her, nicht die DB-Instances für diesen Cluster. Sie tun dies separat, nachdem der Klon verfügbar ist. Die zwei Schritte im Prozess sind wie folgt:

  1. Erstellen Sie den Klon mit dem CLI-Befehl restore-db-cluster-to-point-in-time. Die Parameter, die Sie mit diesem Befehl verwenden, steuern den Kapazitätstyp und andere Details des leeren Aurora-DB-Clusters (Klon), der erstellt wird.

  2. Erstellen Sie die Aurora-DB-Instance für den Klon, indem Sie den CLI-Befehl create-db-instance verwenden, um die Aurora-DB-Instance im wiederhergestellten Aurora-DB-Cluster neu zu erstellen.

Erstellen des Klons

Die spezifischen Parameter, die Sie an den restore-db-cluster-to-point-in-time-CLI-Befehl übergeben, variieren. Was Sie übergeben, hängt vom Engine-Modus-Typ des Quell-DB-Clusters – Serverless oder bereitgestellt – und vom Typ des Klons ab, den Sie erstellen möchten.

So erstellen Sie einen Klon mit demselben Engine-Modus wie der Aurora-DB-Quellcluster

  • Verwenden Sie den restore-db-cluster-to-point-in-time-CLI-Befehl und geben Sie Werte für die folgenden Parameter an:

    • --db-cluster-identifier – Wählen Sie einen aussagekräftigen Namen für Ihren Klon. Sie benennen den Klon, wenn Sie den CLI-Befehl restore-db-cluster-to-point-in-time verwenden. Anschließend übergeben Sie den Namen des Klons im CLI-Befehl create-db-instance.

    • --restore-type – Verwenden Sie copy-on-write, um einen Klon des Quell-DB-Clusters zu erstellen. Ohne diesen Parameter stellt restore-db-cluster-to-point-in-time den Aurora-DB-Cluster wieder her, anstatt einen Klon zu erstellen.

    • --source-db-cluster-identifier – Verwenden Sie den Namen des Aurora-DB-Quell-Clusters, den Sie klonen möchten.

    • --use-latest-restorable-time— Dieser Wert verweist auf die neuesten wiederherstellbaren Volume-Daten für den Quell-DB-Cluster. Verwenden Sie ihn, um Klone zu erstellen.

Im folgenden Beispiel wird ein Klon namens my-clone aus einem Cluster namens my-source-cluster erstellt.

Für LinuxmacOS, oderUnix:

aws rds restore-db-cluster-to-point-in-time \
    --source-db-cluster-identifier my-source-cluster \
    --db-cluster-identifier my-clone \
    --restore-type copy-on-write \
    --use-latest-restorable-time

Windows:

aws rds restore-db-cluster-to-point-in-time ^
    --source-db-cluster-identifier my-source-cluster ^
    --db-cluster-identifier my-clone ^
    --restore-type copy-on-write ^
    --use-latest-restorable-time

Der Befehl gibt das JSON-Objekt zurück, das Details des Klons enthält. Stellen Sie sicher, dass Ihr geklonter DB-Cluster verfügbar ist, bevor Sie versuchen, die DB-Instance für Ihren Klon zu erstellen. Weitere Informationen finden Sie unter Überprüfen des Status und Abrufen von Klon-Details.

Um einen Clone mit einem anderen Engine-Modus als dem Aurora-DB-Cluster der Quelle zu erstellen

  • Verwenden Sie den restore-db-cluster-to-point-in-time-CLI-Befehl und geben Sie Werte für die folgenden Parameter an:

    • --db-cluster-identifier – Wählen Sie einen aussagekräftigen Namen für Ihren Klon. Sie benennen den Klon, wenn Sie den CLI-Befehl restore-db-cluster-to-point-in-time verwenden. Anschließend übergeben Sie den Namen des Klons im CLI-Befehl create-db-instance.

    • --source-db-cluster-identifier – Verwenden Sie den Namen des Aurora-DB-Quell-Clusters, den Sie klonen möchten.

    • --restore-type – Verwenden Sie copy-on-write, um einen Klon des Quell-DB-Clusters zu erstellen. Ohne diesen Parameter stellt restore-db-cluster-to-point-in-time den Aurora-DB-Cluster wieder her, anstatt einen Klon zu erstellen.

    • --use-latest-restorable-time— Dieser Wert verweist auf die neuesten wiederherstellbaren Volume-Daten für den Quell-DB-Cluster. Verwenden Sie ihn, um Klone zu erstellen.

    • --engine-mode— (Optional) Verwenden Sie diesen Parameter nur, um Klone zu erstellen, die einen anderen Typ als das Aurora-DB-Cluster der Quelle haben. Wählen Sie den mit --engine-mode zu übergebenden Wert wie folgt aus:

      • Verwenden Sie provisioned, um einen bereitgestellten Aurora-DB-Clusterklon aus einem Aurora Serverless-DB-Cluster zu erstellen.

      • Verwenden Sie serverless, um einen Aurora Serverless v1-DB-Cluster-Klon aus einem bereitgestellten Aurora-DB-Cluster zu erstellen. Wenn Sie den serverless Engine-Modus angeben, können Sie auch den --scaling-configuration auswählen.

    • --scaling-configuration— (Optional) Verwenden Sie mit--engine-mode serverless, um die Mindest- und Höchstkapazität für einen Aurora Serverless v1 Clone zu konfigurieren. Wenn Sie diesen Parameter nicht verwenden, erstellt Aurora den Clone mit den Standardkapazitätswerten für die DB-Engine.

    • --serverless-v2-scaling-configuration— (Optional) Verwenden Sie diesen Parameter, um die Mindest- und Höchstkapazität für einen Aurora Serverless v2 Clone zu konfigurieren. Wenn Sie diesen Parameter nicht verwenden, erstellt Aurora den Clone mit den Standardkapazitätswerten für die DB-Engine.

Das folgende Beispiel erstellt einen Aurora Serverless v1 Klon mit dem Namenmy-clone, aus einem bereitgestellten Aurora-DB-Cluster namensmy-source-cluster. Der bereitgestellte Aurora-DB-Cluster ist verschlüsselt.

Für LinuxmacOS, oderUnix:

aws rds restore-db-cluster-to-point-in-time \
    --source-db-cluster-identifier my-source-cluster \
    --db-cluster-identifier my-clone \
    --engine-mode serverless \
    --scaling-configuration MinCapacity=8,MaxCapacity=64 \
    --restore-type copy-on-write \
    --use-latest-restorable-time

Windows:

aws rds restore-db-cluster-to-point-in-time ^
    --source-db-cluster-identifier my-source-cluster ^
    --db-cluster-identifier my-clone ^
    --engine-mode serverless ^
    --scaling-configuration MinCapacity=8,MaxCapacity=64 ^
    --restore-type copy-on-write ^
    --use-latest-restorable-time

Diese Befehle geben das JSON-Objekt zurück, das Details des Klons enthält, den Sie zum Erstellen der DB-Instance benötigen. Dies ist erst möglich, wenn der Status des Klons (der leere Aurora-DB-Cluster) den Status Verfügbar hat.

Anmerkung

Der AWS -CLI-Befehl restore-db-cluster-to-point-in-time stellt nur das DB-Cluster wieder her, nicht die DB-Instances für dieses DB-Cluster. Sie müssen den Befehl create-db-instance aufrufen, um DB-Instances für den wiederhergestellten DB-Cluster zu erstellen, wobei Sie die ID des wiederhergestellten DB-Clusters in --db-cluster-identifier angeben. Sie können DB-Instances erst dann erstellen, wenn der Befehl restore-db-cluster-to-point-in-time abgeschlossen ist und der DB-Cluster verfügbar ist.

Angenommen, Sie haben einen Cluster mit dem Namen tpch100g, den Sie klonen möchten. Im folgenden Linux-Beispiel wird ein geklonter Cluster namens tpch100g-clone und eine primäre Instance mit dem Namen tpch100g-clone-instance für den neuen Clusters erstellt. Einige Parameter wie --master-username und --master-user-password müssen nicht angegeben werden. Aurora ermittelt diese automatisch aus dem ursprünglichen Cluster. Sie müssen die zu verwendende DB-Engine angeben. Daher testet das Beispiel den neuen Cluster, um den richtigen Wert für den Parameter --engine zu ermitteln.

$ aws rds restore-db-cluster-to-point-in-time \
  --source-db-cluster-identifier tpch100g \
  --db-cluster-identifier tpch100g-clone \
  --restore-type copy-on-write \
  --use-latest-restorable-time

$ aws rds describe-db-clusters \
  --db-cluster-identifier tpch100g-clone \
    --query '*[].[Engine]' \
    --output text
aurora-mysql

$ aws rds create-db-instance \
  --db-instance-identifier tpch100g-clone-instance \
  --db-cluster-identifier tpch100g-clone \
  --db-instance-class db.r5.4xlarge \
  --engine aurora-mysql

Überprüfen des Status und Abrufen von Klon-Details

Mit dem folgenden Befehl können Sie den Status Ihres neu erstellten leeren DB-Clusters überprüfen.

$ aws rds describe-db-clusters --db-cluster-identifier my-clone --query '*[].[Status]' --output text

Oder Sie können den Status und die anderen Werte, die Sie zum Erstellen der DB-Instance für Ihren Clone benötigen, mithilfe der folgenden AWS CLI Abfrage abrufen.

Für LinuxmacOS, oderUnix:

aws rds describe-db-clusters --db-cluster-identifier my-clone \
  --query '*[].{Status:Status,Engine:Engine,EngineVersion:EngineVersion,EngineMode:EngineMode}'

Windows:

aws rds describe-db-clusters --db-cluster-identifier my-clone ^
  --query "*[].{Status:Status,Engine:Engine,EngineVersion:EngineVersion,EngineMode:EngineMode}"

Diese Abfrage gibt eine Ausgabe ähnlich der folgenden zurück.

[
  {
        "Status": "available",
        "Engine": "aurora-mysql",
        "EngineVersion": "8.0.mysql_aurora.3.04.1",
        "EngineMode": "provisioned"
    }
]

Erstellen einer Aurora-DB-Instance für Ihren Klon

Verwenden Sie den CLI-Befehl create-db-instance, um die DB-Instance für Ihren Aurora Serverless v2 oder den bereitgestellten Clone zu erstellen. Sie erstellen keine DB-Instance für einen Clone. Aurora Serverless v1

Die DB-Instance erbt die --master-user-password Eigenschaften --master-username und vom Quell-DB-Cluster.

Im folgenden Beispiel wird eine DB-Instance für einen bereitgestellten Clone erstellt.

Für LinuxmacOS, oderUnix:

aws rds create-db-instance \
    --db-instance-identifier my-new-db \
    --db-cluster-identifier my-clone \
    --db-instance-class db.r5.4xlarge \
    --engine aurora-mysql

Windows:

aws rds create-db-instance ^
    --db-instance-identifier my-new-db ^
    --db-cluster-identifier my-clone ^
    --db-instance-class db.r5.4xlarge ^
    --engine aurora-mysql

Zu verwendende Parameter für das Klonen

Die folgende Tabelle fasst die verschiedenen Parameter zusammen, die mit restore-db-cluster-to-point-in-time zum Klonen von Aurora-DB-Clustern verwendet werden.

Parameter Beschreibung

--source-db-cluster-identifier

Verwenden Sie den Namen des Aurora-DB-Quell-Clusters, den Sie klonen möchten.

--db-cluster-identifier

Wählen Sie einen aussagekräftigen Namen für Ihren Klon, wenn Sie ihn mit dem restore-db-cluster-to-point-in-time Befehl erstellen. Dann übergeben Sie diesen Namen an den create-db-instance-Befehl.

--restore-type

Geben Sie copy-on-write als --restore-type an, um einen Klon des Quell-DB-Clusters zu erstellen, anstatt den Quell-Aurora-DB-Cluster wiederherzustellen.
--use-latest-restorable-time

Dieser Wert verweist auf die neuesten wiederherstellbaren Volume-Daten für den Quell-DB-Cluster. Verwenden Sie ihn, um Klone zu erstellen.

--engine-mode

Verwenden Sie diesen Parameter, um Klone zu erstellen, die einen anderen Typ als das Aurora-DB-Cluster der Quelle haben, und zwar mit einem der folgenden Werte:

  • Wird verwendetprovisioned, um einen bereitgestellten DB-Cluster oder einen Aurora Serverless v2 Klon aus einem Aurora Serverless v1 DB-Cluster zu erstellen.

  • Wird verwendetserverless, um einen Aurora Serverless v1 Clone aus einem bereitgestellten oder einem Aurora Serverless v2 DB-Cluster zu erstellen.

    Wenn Sie den serverless Engine-Modus angeben, können Sie auch den --scaling-configuration auswählen.

--scaling-configuration

Verwenden Sie diesen Parameter, um die Mindest- und Höchstkapazität für einen Aurora Serverless v1 Clone zu konfigurieren. Wenn Sie diesen Parameter nicht angeben, erstellt Aurora den Clone mit den Standardkapazitätswerten für die DB-Engine.
--serverless-v2-scaling-configuration

Verwenden Sie diesen Parameter, um die Mindest- und Höchstkapazität für einen Aurora Serverless v2 Clone zu konfigurieren. Wenn Sie diesen Parameter nicht angeben, erstellt Aurora den Clone mit den Standardkapazitätswerten für die DB-Engine.

VPC-übergreifendes Klonen 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 einer anderen VPC für Entwicklung und Tests zu erstellen. Oder Sie können einen Klon als Teil einer Migration von öffentlichen Subnetzen zu privaten Subnetzen 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 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, finden Sie zuerst weitere Informationen. Amazon VPCs 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, um Ihnen zu helfen, zu verstehen, wie Sie solche Operationen automatisieren und die Ausgabe speichern können.

Bevor Sie beginnen

Bevor Sie mit der Einrichtung eines vPC-übergreifenden Klons beginnen, stellen Sie 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 Clone 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, 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-Speicher und -Zuverlässigkeit, ist der Speicher für jeden Aurora-Cluster genau drei AZs zugeordnet. Da der die Vorteile der Trennung von Rechenleistung und Speicher Amazon-Aurora-DB-Cluster nutzt, gilt diese Regel unabhängig davon, wie viele Instances 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 AZs verwendet. 

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

Um einen Clone 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, 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, 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 im ersten Befehl den Namen Ihres Clusters durch. my_cluster Ersetzen Sie im zweiten Befehl den Namen der DB-Subnetzgruppe durch. my_subnet 

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 derselben VPC verwenden oder Subnetze mit ähnlichen Eigenschaften in einer anderen VPC erstellen möchten.

Finden 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

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

Sie können dieses Verfahren verwenden, um die AZs zu verstehen, die für die DB-Instances im ursprünglichen Cluster verwendet wurden. Auf diese Weise können Sie exakt dieselben 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 AZs verteilt sind. 

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 dieselben AZs wie im ursprünglichen Cluster konfiguriert sind.

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

Wenn Sie beabsichtigen, den Clone 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 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 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 Clone oder eine andere VPC verwenden. Wenn sich der ursprüngliche Cluster und der Clone in derselben VPC befinden, 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 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.

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 AZs zugeordnet sind, 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 einer anderen VPC erstellen oder wenn Sie eine andere Netzwerkänderung vornehmen, z. B. private Subnetze anstelle von öffentlichen Subnetzen verwenden.

AWS generiert automatisch die ID des Subnetzes. Ersetzen Sie den Namen der VPC des Klons durch. 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 einer anderen VPC oder einer anderen Gruppe von Subnetzen innerhalb derselben VPC erstellen, 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.

  1. VPC des ursprünglichen Clusters. Anweisungen finden Sie unter Schritt 3: Überprüfen Sie die Subnetze des ursprünglichen Clusters.

  2. VPC des Klons, wenn Sie ihn in einer anderen VPC erstellen. Anweisungen finden Sie unter Schritt 5: Überprüfen Sie die VPCs, die Sie für den Clone verwenden können.

  3. Drei AZs, die dem Aurora-Speicher für den ursprünglichen Cluster zugeordnet sind. Anweisungen finden Sie unter Schritt 1: Überprüfen Sie die Availability Zones des ursprünglichen Clusters.

  4. Zwei oder drei AZs, die der DB-Subnetzgruppe für den ursprünglichen Cluster zugeordnet sind. Anweisungen finden Sie unter Schritt 2: Überprüfen Sie die DB-Subnetzgruppe des ursprünglichen Clusters.

  5. Die Subnetz-IDs und zugehörigen AZs aller Subnetze in der VPC, die Sie für den Clone verwenden möchten. Verwenden Sie denselben describe-subnets Befehl wie in Schritt 3: Überprüfen Sie die Subnetze des ursprünglichen Clusters und ersetzen Sie dabei die VPC-ID der Ziel-VPC.

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 Clone erfolgreich zu erstellen, müssen zwei oder drei AZs gemeinsam 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 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 Clone auf mehrere AZs zu verteilen, 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 die Subnetz-IDs mithilfe von Umgebungsvariablen angeben, achten Sie darauf, die --subnet-ids Parameterliste so in Anführungszeichen zu setzen, dass die IDs 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 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 erstellt. Sie haben alle relevanten VPC- und Subnetzressourcen erstellt, sodass Sie beim Erstellen 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, 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, 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 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 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 Capacity Units (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 von den DB-Instances verwendeten Subnetze ist der Aurora-Speicher für den Quell-Cluster und den Clone drei AZs zugeordnet. Das folgende Beispiel listet die AZs auf, die sowohl dem ursprünglichen Cluster als auch dem Clone zugeordnet sind, 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 von Original- und Klonclustern ü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 beim Hinzufügen neuer Instances zum Clone 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 Clone erstellen. Die AZ, die Sie angeben, muss aus der Gruppe von AZs stammen, 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 AZs auswählen, die diesen beiden Subnetzen 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 in unterschiedlichen AZs befinden. Oder wenn Sie dem Cluster weitere Leser hinzufügen, können Sie sicherstellen, dass diese auf drei AZs verteilt sind. Auf diese Weise haben Sie selbst im seltenen Fall eines AZ-Fehlers 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 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 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 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 beim Erstellen 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 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 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 ü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 und dass diese Subnetze denselben AZs zugeordnet sind, die für Aurora-Speicher im ursprünglichen Cluster verwendet werden. Ähnlich wie bei anderen Anwendungsfällen beim Klonen können Sie die DB-Subnetzgruppe für den Clone 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 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 Beispiel für die Erstellung eines vPC-übergreifenden Klons

Beim Erstellen eines Klons in einer anderen VPC als dem Original werden dieselben allgemeinen Schritte wie in den vorherigen Beispielen verwendet. Da die VPC-ID eine Eigenschaft der Subnetze ist, 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 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 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 überprüft haben, ob 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 einer VPC auf 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 Clone mit demselben Satz von AZs für den Aurora-Speicher einzurichten, überprüfen wir die AZs, die vom ursprünglichen Cluster verwendet wurden. 

$ 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 verwendeten AZs 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 AZs in der Ziel-VPC VPC 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 sie für Aurora-Speicher verwendet. 

$ 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 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 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

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. in der Ziel-VPC verwenden.

Kontoübergreifendes Klonen mit AWS RAM und Amazon Aurora

Wenn Sie AWS Resource Access Manager (AWS RAM) mit Amazon Aurora verwenden, können Sie Aurora-DB-Cluster und -Clones, die zu Ihrem AWS Konto gehören, mit einem anderen AWS Konto oder einer anderen Organisation teilen. Ein solches kontoübergreifendes Klonen ist viel schneller als das Erstellen und Wiederherstellen eines Datenbank-Snapshots. Sie können einen Klon eines Ihrer Aurora-DB-Cluster erstellen und den Klon freigeben. Oder Sie können Ihren Aurora-DB-Cluster mit einem anderen AWS Konto teilen und den Kontoinhaber den Clone erstellen lassen. Welchen Ansatz Sie wählen, hängt von Ihrem Anwendungsfall ab.

Beispielsweise müssen Sie möglicherweise regelmäßig einen Klon Ihrer Finanzdatenbank für das interne Revisionsteam Ihres Unternehmens freigeben. In diesem Fall hat Ihr Prüfungsteam ein eigenes AWS -Konto für die von ihm verwendeten Anwendungen. Sie können dem AWS Konto des Prüfungsteams die Erlaubnis erteilen, auf Ihren Aurora-DB-Cluster zuzugreifen und ihn nach Bedarf zu klonen.

Auf der anderen Seite, wenn ein externer Anbieter Ihre Finanzdaten prüft, ziehen Sie es möglicherweise vor, den Klon selbst zu erstellen. Sie geben dann dem externen Anbieter nur Zugriff auf den Klon.

Sie können auch kontenübergreifendes Klonen verwenden, um viele der gleichen Anwendungsfälle für das Klonen innerhalb desselben AWS Kontos zu unterstützen, z. B. Entwicklung und Testen. Beispielsweise könnte Ihre Organisation unterschiedliche AWS Konten für Produktion, Entwicklung, Tests usw. verwenden. Weitere Informationen finden Sie unter Übersicht über das Aurora-Klonen.

Daher möchten Sie vielleicht einen Clone mit einem anderen Konto teilen oder einem anderen AWS Konto erlauben, Klone Ihrer Aurora-DB-Cluster zu erstellen. AWS Verwenden Sie in beiden Fällen zunächst, AWS RAM um ein Share-Objekt zu erstellen. Vollständige Informationen zur gemeinsamen Nutzung von AWS Ressourcen zwischen AWS Konten finden Sie im AWS RAM Benutzerhandbuch.

Zum Erstellen eines kontoübergreifenden Clones sind Aktionen von dem AWS Konto, dem der ursprüngliche Cluster gehört, und von dem AWS Konto, das den Clone erstellt, erforderlich. Zuerst ändert der ursprüngliche Clusterbesitzer den Cluster, um es einem oder mehreren anderen Konten zu ermöglichen, ihn zu klonen. Wenn sich eines der Konten in einer anderen AWS Organisation befindet, wird eine Einladung zum Teilen AWS generiert. Das andere Konto muss die Einladung annehmen, bevor Sie fortfahren können. Dann kann jedes autorisierte Konto den Cluster klonen. Während dieses Prozesses wird der Cluster durch seinen eindeutigen Amazon-Ressourcennamen (ARN) identifiziert.

Wie beim Klonen innerhalb desselben AWS Kontos wird zusätzlicher Speicherplatz nur verwendet, wenn die Quelle oder der Klon Änderungen an den Daten vornehmen. Zu diesem Zeitpunkt werden dann Gebühren für die Speicherung erhoben. Wenn der Quellen-Cluster gelöscht wird, werden Speicherkosten gleichmäßig auf die verbleibenden geklonten Cluster verteilt.

Einschränkungen für kontoübergreifendes Klonen

Kontoübergreifendes Aurora-Klonen hat folgende Einschränkungen:

  • Sie können einen Aurora Serverless v1 Cluster nicht für mehrere AWS Konten klonen.

  • Sie können keine Einladungen zu gemeinsam genutzten Ressourcen mit dem anzeigen oder annehmen AWS Management Console. Verwenden Sie die AWS CLI, die Amazon RDS-API oder die AWS RAM Konsole, um Einladungen zu gemeinsam genutzten Ressourcen anzuzeigen und anzunehmen.

  • Sie können nur einen neuen Klon aus einem Klon erstellen, der mit Ihrem AWS Konto geteilt wurde.

  • Sie können keine Ressourcen (Klone oder Aurora-DB-Cluster) teilen, die mit Ihrem AWS Konto geteilt wurden.

  • Sie können maximal 15 kontoübergreifende Klone aus einem einzelnen Aurora-DB-Cluster erstellen.

  • Jeder der 15 kontoübergreifenden Klone muss einem anderen Konto gehören. AWS Das heißt, Sie können innerhalb eines Kontos nur einen kontenübergreifenden Klon eines Clusters erstellen. AWS

  • Nachdem Sie einen Cluster geklont haben, werden der ursprüngliche Cluster und sein Klon als identisch angesehen, um Grenzwerte für kontoübergreifende Klone durchzusetzen. Sie können innerhalb desselben Kontos keine kontenübergreifenden Klone sowohl des ursprünglichen Clusters als auch des geklonten Clusters erstellen. AWS Die Gesamtzahl der kontoübergreifenden Klone für den ursprünglichen Cluster und einen seiner Klone darf 15 nicht überschreiten.

  • Sie können einen Aurora-DB-Cluster nicht mit anderen AWS Konten teilen, es sei denn, der Cluster befindet sich in einem ACTIVE Status.

  • Sie können einen Aurora-DB-Cluster, der mit anderen AWS Konten geteilt wurde, nicht umbenennen.

  • Sie können keinen kontoübergreifenden Klon eines Clusters erstellen, der mit dem RDS-Standardschlüssel verschlüsselt ist.

  • Sie können in einem AWS Konto keine unverschlüsselten Klone aus verschlüsselten Aurora-DB-Clustern erstellen, die von einem anderen AWS Konto gemeinsam genutzt wurden. Der Clustereigentümer muss die Erlaubnis zum Zugriff auf den Quellcluster AWS KMS key. Sie können jedoch auch einen anderen Schlüssel verwenden, wenn Sie den Klon erstellen.

Erlauben Sie anderen AWS Konten, Ihren Cluster zu klonen

Um anderen AWS Konten das Klonen eines Clusters zu ermöglichen, dessen Eigentümer Sie sind, legen AWS RAM Sie die Freigabeberechtigung fest. Dadurch wird auch eine Einladung an jedes der anderen Konten gesendet, die sich in einer anderen AWS Organisation befinden.

Informationen zur gemeinsamen Nutzung von Ressourcen, die Ihnen gehören, in der AWS RAM Konsole finden Sie im AWS RAM Benutzerhandbuch unter Gemeinsame Nutzung von Ressourcen, die Ihnen gehören.

Erteilen Sie anderen AWS Konten die Erlaubnis, Ihren Cluster zu klonen

Wenn der Cluster, den Sie gemeinsam nutzen, verschlüsselt ist, teilen Sie auch die AWS KMS key für den Cluster. Sie können AWS Identity and Access Management (IAM-) Benutzern oder Rollen in einem AWS Konto erlauben, einen KMS-Schlüssel in einem anderen Konto zu verwenden.

Dazu fügen Sie zunächst das externe Konto (Root-Benutzer) zur Schlüsselrichtlinie des KMS-Schlüssels hinzu. AWS KMS Sie fügen der Schlüsselrichtlinie nicht die einzelnen Benutzer oder Rollen hinzu, sondern nur das externe Konto, das sie enthält. Sie können nur einen von Ihnen erstellten KMS-Schlüssel freigeben, nicht den Standardschlüssel des RDS-Dienstes. Informationen zur Zugriffskontrolle für KMS-Schlüssel finden Sie unter Authentifizierung und Zugriffskontrolle für AWS KMS.

So gewähren Sie die Berechtigung zum Klonen Ihres Clusters

  1. Melden Sie sich bei der Amazon RDS-Konsole an AWS Management Console und öffnen Sie sie unter https://console.aws.amazon.com/rds/.

  2. Wählen Sie im Navigationsbereich Databases (Datenbanken) aus.

  3. Wählen Sie den DB-Cluster aus, den Sie freigeben möchten, um seine Details-Seite anzuzeigen, und wählen Sie dann die Registerkarte Connectivity & security (Konnektivität und Sicherheit) aus.

  4. Geben Sie im Abschnitt DB-Cluster mit anderen AWS Konten teilen die numerische Konto-ID für das AWS Konto ein, dem Sie das Klonen dieses Clusters erlauben möchten. Bei Konto-IDs in derselben Organisation können Sie die ersten Zeichen in das Feld eintippen und dann aus dem Menü auswählen.

    Wichtig

    In manchen Fällen möchten Sie vielleicht, dass ein Konto, das sich nicht in derselben AWS -Organisation befindet wie Ihr Konto, einen Cluster klont. In diesen Fällen meldet die Konsole aus Sicherheitsgründen nicht, wer diese Konto-ID besitzt oder ob das Konto existiert.

    Seien Sie vorsichtig bei der Eingabe von Kontonummern, die sich nicht in derselben AWS Organisation wie Ihr AWS Konto befinden. Überprüfen Sie sofort, ob Sie die Freigabe für das beabsichtigte Konto erteilt haben.

  5. Überprüfen Sie auf der Bestätigungsseite, dass die von Ihnen angegebene Konto-ID richtig ist. Geben Sie im Bestätigungsfeld share ein, um dies zu bestätigen.

    Auf der Detailseite wird unter Konten, mit denen dieser DB-Cluster gemeinsam genutzt wird, ein Eintrag mit der angegebenen AWS Konto-ID angezeigt. Die Spalte Status zeigt ursprünglich den Status Pending (Ausstehend) an.

  6. Wenden Sie sich an den Besitzer des anderen AWS Kontos, oder melden Sie sich bei diesem Konto an, wenn Sie beide besitzen. Weisen Sie den Besitzer des anderen Kontos an, die Freigabeeinladung anzunehmen und den DB-Cluster zu klonen, wie nachfolgend beschrieben.

So gewähren Sie die Berechtigung zum Klonen Ihres Clusters

  1. Tragen Sie die Daten für die erforderlichen Parameter zusammen. Sie benötigen den ARN für Ihren Cluster und die numerische ID für das andere AWS Konto.

  2. Führen Sie den AWS RAM CLI-Befehl aus create-resource-share.

    Für LinuxmacOS, oderUnix:

    aws ram create-resource-share --name descriptive_name \
  --region region \
  --resource-arns cluster_arn \
  --principals other_account_ids

    Windows:

    aws ram create-resource-share --name descriptive_name ^
  --region region ^
  --resource-arns cluster_arn ^
  --principals other_account_ids

    Geben Sie, um mehrere Konto-IDs für den --principals-Parameter einzuschließen, IDs mit Leerzeichen voneinander getrennt ein. Um anzugeben, ob die genehmigten Konto-IDs außerhalb Ihrer AWS -Organisation sein können, schließen Sie auch den --allow-external-principals- bzw. den --no-allow-external-principals-Parameter für create-resource-share ein.

So gewähren Sie die Berechtigung zum Klonen Ihres Clusters

  1. Tragen Sie die Daten für die erforderlichen Parameter zusammen. Sie benötigen den ARN für Ihren Cluster und die numerische ID für das andere AWS Konto.

  2. Rufen Sie die AWS RAM API-Operation CreateResourceShare auf und geben Sie die folgenden Werte an:

    • Geben Sie die Konto-ID für ein oder mehrere AWS Konten als principals Parameter an.

    • Geben Sie die ARN mindestens eines Aurora-DB-Clusters als resourceArns-Parameter an.

    • Geben Sie an, ob sich die genehmigten Konto-IDs außerhalb Ihrer AWS -Organisation befinden dürfen, indem Sie einen booleschen Wert für den allowExternalPrincipals-Parameter einfügen.

Neuerstellen eines Clusters, der den RDS-Standardschlüssel verwendet

Wenn der verschlüsselte Cluster, den Sie freigeben möchten, den RDS-Standardschlüssel verwendet, stellen Sie sicher, dass der Cluster neu erstellt wird. Erstellen Sie dazu einen manuellen Snapshot Ihres DB-Clusters, verwenden Sie eine AWS KMS key, und stellen Sie den Cluster dann in einem neuen Cluster wieder her. Geben Sie dann den neuen Cluster frei. Führen Sie die folgenden Schritte aus, um diesen Vorgang durchzuführen.

So erstellen Sie einen verschlüsselten Cluster neu, der den RDS-Standardschlüssel verwendet

  1. Melden Sie sich bei der Amazon RDS-Konsole an AWS Management Console und öffnen Sie sie unter https://console.aws.amazon.com/rds/.

  2. Wählen Sie im Navigationsbereich die Option Snapshots aus.

  3. Wählen Sie Ihren Snapshot aus.

  4. Wählen Sie unter Actions (Aktionen) die Option Copy Snapshot (Snapshot kopieren) und anschließend Enable encryption (Verschlüsselung aktivieren) aus.

  5. Wählen Sie für AWS KMS key den neuen Verschlüsselungscode, den Sie verwenden möchten.

  6. Stellen Sie den kopierten Snapshot wieder her. Eine Schritt-für-Schritt-Anleitung hierzu finden Sie unter Wiederherstellen aus einem DB-Cluster-Snapshot. Die neue DB-Instance verwendet Ihren neuen Verschlüsselungsschlüssel.

  7. (Optional) Löschen Sie den alten DB-Cluster, wenn Sie ihn nicht mehr benötigen. Eine Schritt-für-Schritt-Anleitung hierzu finden Sie unter Löschen eines DB-Cluster-Snapshots. Bevor Sie dies tun, überprüfen Sie, ob Ihr neuer Cluster über alle notwendigen Daten verfügt und ob Ihre Anwendung erfolgreich darauf zugreifen kann.

Prüfen Sie, ob ein Cluster, den Sie besitzen, mit anderen AWS Konten geteilt wird

Sie können überprüfen, ob andere Benutzer die Berechtigung für die Freigabe eines Clusters haben. Dies kann hilfreich sein, um zu wissen, ob der Cluster sich dem Limit für die maximale Anzahl an kontoübergreifenden Klonen nähert.

Die Verfahren zur gemeinsamen Nutzung von Ressourcen mithilfe der AWS RAM Konsole finden Sie im AWS RAM Benutzerhandbuch unter Gemeinsame Nutzung von Ressourcen, die Ihnen gehören.

Finden Sie heraus, ob ein Cluster, den Sie besitzen, mit anderen AWS Konten gemeinsam genutzt wird

  • Rufen Sie den AWS RAM CLI-Befehl list-principalsauf und verwenden Sie dabei Ihre Konto-ID als Ressourcenbesitzer und den ARN Ihres Clusters als Ressourcen-ARN. Sie können mit dem folgenden Befehl alle Freigaben anzeigen. Die Ergebnisse geben an, welche AWS Konten den Cluster klonen dürfen. 

    aws ram list-principals \
    --resource-arns your_cluster_arn \
    --principals your_aws_id
Um herauszufinden, ob ein Cluster, den Sie besitzen, mit anderen AWS Konten geteilt wird

  • Rufen Sie den AWS RAM API-Vorgang auf ListPrincipals. Verwenden Sie Ihre Konto-ID als Ressourcenbesitzer und den ARN Ihres Clusters als Ressourcen-ARN.

Einen Cluster klonen, der einem anderen AWS Konto gehört

Um einen Cluster zu klonen, der einem anderen AWS Konto gehört, holen Sie sich AWS RAM die Erlaubnis ein, den Klon zu erstellen. Wenn Sie die erforderliche Berechtigung haben, verwenden Sie das Standardverfahren zum Klonen eines Aurora-Clusters.

Sie können auch überprüfen, ob es sich bei einem Cluster, den Sie besitzen, um einen Klon eines Clusters handelt, der einem anderen AWS Konto gehört.

Informationen zu den Verfahren für die Arbeit mit Ressourcen, die anderen Benutzern gehören, AWS RAM finden Sie im AWS RAM Benutzerhandbuch unter Zugreifen auf Ressourcen, die mit Ihnen geteilt wurden.

Einladungen zum Klonen von Clustern anzeigen, die anderen AWS Konten gehören

Um mit Einladungen zum Klonen von Clustern zu arbeiten, die AWS Konten in anderen AWS Organisationen gehören AWS CLI, verwenden Sie die, die AWS RAM Konsole oder die AWS RAM API. Aktuell können Sie dieses Verfahren nicht mithilfe der Amazon RDS-Konsole durchführen.

Die Verfahren zur Verwendung von Einladungen in der AWS RAM Konsole finden Sie im AWS RAM Benutzerhandbuch unter Zugreifen auf Ressourcen, die mit Ihnen geteilt wurden.

Um Einladungen zum Klonen von Clustern anzuzeigen, die anderen AWS Konten gehören

  1. Führen Sie den AWS RAM CLI-Befehl aus get-resource-share-invitations. 

    aws ram get-resource-share-invitations --region region_name

    Die Ergebnisse des vorausgehenden Befehls zeigen alle Einladungen, Cluster zu klonen, an, einschließlich aller Einladungen, die Sie bereits angenommen oder abgelehnt haben.

  2. (Optional) Filtern Sie die Liste, um nur die Einladungen anzuzeigen, die eine Aktion Ihrerseits erforderlich machen. Fügen Sie dafür den -Parameter hinz --query 'resourceShareInvitations[?status==`PENDING`]'.

Um Einladungen zum Klonen von Clustern zu sehen, die anderen AWS Konten gehören

  1. Rufen Sie den AWS RAM API-Vorgang auf GetResourceShareInvitations. Diese Operation gibt all diese Einladungen zurück, einschließlich derer, die Sie bereits angenommen oder abgelehnt haben.

  2. (Optional) Suchen Sie nur die Einladungen, die eine Aktion Ihrerseits erforderlich machen, indem Sie das Rückgabefeld resourceShareAssociations für den status-Wert PENDING aktivieren.

Annahme von Einladungen zur gemeinsamen Nutzung von Clustern, die anderen AWS Konten gehören

Sie können Einladungen zur gemeinsamen Nutzung von Clustern annehmen, die anderen AWS Konten gehören, die sich in anderen AWS Organisationen befinden. Verwenden Sie die APIs, die AWS RAM und die AWS CLI RDS-APIs oder die AWS RAM Konsole, um mit diesen Einladungen zu arbeiten. Aktuell können Sie dieses Verfahren nicht mithilfe der RDS-Konsole durchführen.

Die Verfahren zur Verwendung von Einladungen in der AWS RAM Konsole finden Sie im AWS RAM Benutzerhandbuch unter Zugreifen auf mit Ihnen geteilte Ressourcen.

So nehmen Sie eine Einladung zur gemeinsamen Nutzung eines Clusters von einem anderen AWS Konto aus an

  1. Suchen Sie den Einladungs-ARN, indem Sie den AWS RAM CLI-Befehl ausführen get-resource-share-invitations, wie oben gezeigt.

  2. Nehmen Sie die Einladung an, indem Sie den AWS RAM CLI-Befehl aufrufen accept-resource-share-invitation, wie im Folgenden gezeigt.

    Für LinuxmacOS, oderUnix:

    aws ram accept-resource-share-invitation \
  --resource-share-invitation-arn invitation_arn \
  --region region

    Windows:

    aws ram accept-resource-share-invitation ^
  --resource-share-invitation-arn invitation_arn ^
  --region region
So nehmen Sie Einladung zur Freigabe eines Clusters, der jemand anderem gehört, an

  1. Suchen Sie den Einladungs-ARN, indem Sie den AWS RAM API-Vorgang aufrufen GetResourceShareInvitations, wie oben gezeigt.

  2. Übergeben Sie diesen ARN als resourceShareInvitationArn Parameter an den RDS-API-Vorgang AcceptResourceShareInvitation.

Einen Aurora-Cluster klonen, der einem anderen AWS Konto gehört

Nachdem Sie die Einladung von dem AWS Konto angenommen haben, dem der DB-Cluster gehört, wie oben gezeigt, können Sie den Cluster klonen.

Um einen Aurora-Cluster zu klonen, der einem anderen AWS Konto gehört

  1. Melden Sie sich bei der Amazon RDS-Konsole an AWS Management Console und öffnen Sie sie unter https://console.aws.amazon.com/rds/.

  2. Wählen Sie im Navigationsbereich Databases (Datenbanken) aus.

    Ganz oben in der Datenbankliste sollten Sie mindestens ein Element mit dem Role (Rolle)-Wert Shared from account #account_id sehen. Aus Sicherheitsgründen können Sie nur eingeschränkte Informationen über die ursprünglichen Cluster sehen. Die Eigenschaften, die Sie sehen können, sind solche wie etwa die Datenbank-Engine und -Version, die in Ihrem geklonten Cluster identisch sein müssen.

  3. Wählen Sie den Cluster aus, den Sie vorhaben zu klonen.

  4. Wählen Sie für Actions (Aktionen) Create clone (Klon erstellen) aus.

  5. Gehen Sie entsprechend dem Verfahren unter Konsole vor, um die Einrichtung des geklonten Clusters durchzuführen.

  6. Aktivieren Sie je nach Bedarf die Verschlüsselung für den geklonten Cluster. Wenn der Cluster, den Sie klonen, verschlüsselt ist, müssen Sie die Verschlüsselung für den geklonten Cluster aktivieren. Das AWS -Konto, das den Cluster für Sie freigegeben hat, muss auch den KMS-Schlüssel freigeben, der zur Verschlüsselung des Clusters verwendet wurde. Sie können denselben KMS-Schlüssel zur Verschlüsselung des Klons verwenden oder Ihren eigenen KMS-Schlüssel. Sie können keinen kontoübergreifenden Klon für einen Cluster erstellen, der mit dem Standard-KMS-Schlüssel verschlüsselt ist.

    Das Konto, dem der Verschlüsselungsschlüssel gehört, muss dem Zielkonto die Berechtigung zur Verwendung des Schlüssels mithilfe einer Schlüsselrichtlinie erteilen. Dieser Vorgang ist ähnlich dem Verfahren, mit dem verschlüsselte Snapshots freigegeben werden, mithilfe einer Schlüsselrichtlinie, die dem Zielkonto die Berechtigung zur Verwendung des Schlüssels gewährt.

Um einen Aurora-Cluster zu klonen, der einem anderen AWS Konto gehört

  1. Nehmen Sie die Einladung von dem AWS Konto an, dem der DB-Cluster gehört, wie oben gezeigt.

  2. Klonen Sie den Cluster, indem Sie den vollständigen ARN des Quell-Clusters im source-db-cluster-identifier-Parameter des RDS-CLI-Befehls restore-db-cluster-to-point-in-time angeben, wie nachfolgend gezeigt.

    Wenn der als source-db-cluster-identifier übergebene ARN nicht freigegeben wurde, wird derselbe Fehler zurückgegeben, wie wenn der angegebene Cluster nicht vorhanden ist.

    Für LinuxmacOS, oderUnix:

    aws rds restore-db-cluster-to-point-in-time \
  --source-db-cluster-identifier=arn:aws:rds:arn_details \
  --db-cluster-identifier=new_cluster_id \
  --restore-type=copy-on-write \
  --use-latest-restorable-time

    Windows:

    aws rds restore-db-cluster-to-point-in-time ^
  --source-db-cluster-identifier=arn:aws:rds:arn_details ^
  --db-cluster-identifier=new_cluster_id ^
  --restore-type=copy-on-write ^
  --use-latest-restorable-time

  3. Wenn der Cluster, den Sie klonen, verschlüsselt ist, verschlüsseln Sie Ihren geklonten Cluster, indem Sie einen kms-key-id-Parameter einfügen. Dieser kms-key-id-Wert kann derselbe sein, der zur Verschlüsselung des ursprünglichen DB-Clusters verwendet wurde, oder Ihr eigener KMS-Schlüssel. Ihr Konto muss über die Berechtigung zum Verwenden dieses Verschlüsselungsschlüssels verfügen.

    Für LinuxmacOS, oderUnix:

    aws rds restore-db-cluster-to-point-in-time \
  --source-db-cluster-identifier=arn:aws:rds:arn_details \
  --db-cluster-identifier=new_cluster_id \
  --restore-type=copy-on-write \
  --use-latest-restorable-time \
  --kms-key-id=arn:aws:kms:arn_details

    Windows:

    aws rds restore-db-cluster-to-point-in-time ^
  --source-db-cluster-identifier=arn:aws:rds:arn_details ^
  --db-cluster-identifier=new_cluster_id ^
  --restore-type=copy-on-write ^
  --use-latest-restorable-time ^
  --kms-key-id=arn:aws:kms:arn_details

    Das Konto, dem der Verschlüsselungsschlüssel gehört, muss dem Zielkonto die Berechtigung zur Verwendung des Schlüssels mithilfe einer Schlüsselrichtlinie erteilen. Dieser Vorgang ist ähnlich dem Verfahren, mit dem verschlüsselte Snapshots freigegeben werden, mithilfe einer Schlüsselrichtlinie, die dem Zielkonto die Berechtigung zur Verwendung des Schlüssels gewährt. Nachfolgend sehen Sie ein Beispiel für eine Schlüsselrichtlinie. 

    {
  "Id": "key-policy-1",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Allow use of the key",
      "Effect": "Allow",
      "Principal": {"AWS": [
        "arn:aws:iam::account_id:user/KeyUser",
        "arn:aws:iam::account_id:root"
      ]},
      "Action": [
        "kms:CreateGrant",
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:ReEncrypt*",
        "kms:GenerateDataKey*",
        "kms:DescribeKey"
      ],
      "Resource": "*"
    },
    {
      "Sid": "Allow attachment of persistent resources",
      "Effect": "Allow",
      "Principal": {"AWS": [
        "arn:aws:iam::account_id:user/KeyUser",
        "arn:aws:iam::account_id:root"
      ]},
      "Action": [
        "kms:CreateGrant",
        "kms:ListGrants",
        "kms:RevokeGrant"
      ],
      "Resource": "*",
      "Condition": {"Bool": {"kms:GrantIsForAWSResource": true}}
    }
  ]
}
Anmerkung

Der AWS -CLI-Befehl restore-db-cluster-to-point-in-time stellt nur das DB-Cluster wieder her, nicht die DB-Instances für dieses DB-Cluster. Um DB-Instances für den wiederhergestellten DB-Cluster zu erstellen, rufen Sie den Befehl create-db-instance auf. Geben Sie die ID des wiederhergestellten DB-Clusters in --db-cluster-identifier an.

Sie können DB-Instances erst dann erstellen, wenn der Befehl restore-db-cluster-to-point-in-time abgeschlossen ist und der DB-Cluster verfügbar ist.

Um einen Aurora-Cluster zu klonen, der einem anderen AWS Konto gehört

  1. Nehmen Sie die Einladung von dem AWS Konto an, dem der DB-Cluster gehört, wie oben gezeigt.

  2. Klonen Sie den Cluster, indem Sie den vollständigen ARN des Quell-Clusters im SourceDBClusterIdentifier-Parameter der RDS-API-Operation RestoreDBClusterToPointInTime angeben.

    Wenn der als SourceDBClusterIdentifier übergebene ARN nicht freigegeben wurde, dann wird derselbe Fehler zurückgegeben, wie wenn der angegebene Cluster nicht vorhanden ist.

  3. Wenn der Cluster, den Sie klonen, verschlüsselt ist, fügen Sie einen KmsKeyId-Parameter ein, um Ihren geklonten Cluster zu verschlüsseln. Dieser kms-key-id-Wert kann derselbe sein, der zur Verschlüsselung des ursprünglichen DB-Clusters verwendet wurde, oder Ihr eigener KMS-Schlüssel. Ihr Konto muss über die Berechtigung zum Verwenden dieses Verschlüsselungsschlüssels verfügen.

    Wenn Sie ein Volume klonen, muss das Zielkonto die Berechtigung haben, den Verschlüsselungsschlüssel zu verwenden, der zum Verschlüsseln des Quellclusters verwendet wird. Aurora verschlüsselt den neuen geklonten Cluster mit dem in KmsKeyId angegebenen Verschlüsselungsschlüssel.

    Das Konto, dem der Verschlüsselungsschlüssel gehört, muss dem Zielkonto die Berechtigung zur Verwendung des Schlüssels mithilfe einer Schlüsselrichtlinie erteilen. Dieser Vorgang ist ähnlich dem Verfahren, mit dem verschlüsselte Snapshots freigegeben werden, mithilfe einer Schlüsselrichtlinie, die dem Zielkonto die Berechtigung zur Verwendung des Schlüssels gewährt. Nachfolgend sehen Sie ein Beispiel für eine Schlüsselrichtlinie. 

    {
  "Id": "key-policy-1",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Allow use of the key",
      "Effect": "Allow",
      "Principal": {"AWS": [
        "arn:aws:iam::account_id:user/KeyUser",
        "arn:aws:iam::account_id:root"
      ]},
      "Action": [
        "kms:CreateGrant",
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:ReEncrypt*",
        "kms:GenerateDataKey*",
        "kms:DescribeKey"
      ],
      "Resource": "*"
    },
    {
      "Sid": "Allow attachment of persistent resources",
      "Effect": "Allow",
      "Principal": {"AWS": [
        "arn:aws:iam::account_id:user/KeyUser",
        "arn:aws:iam::account_id:root"
      ]},
      "Action": [
        "kms:CreateGrant",
        "kms:ListGrants",
        "kms:RevokeGrant"
      ],
      "Resource": "*",
      "Condition": {"Bool": {"kms:GrantIsForAWSResource": true}}
    }
  ]
}
Anmerkung

Der RDS-API-Vorgang RestoreDB ClusterTo PointIn Time stellt nur den DB-Cluster wieder her, nicht die DB-Instances für diesen DB-Cluster. Um DB-Instances für den wiederhergestellten DB-Cluster zu erstellen, rufen Sie die RDS-API-Operation CreateDBInstance auf. Geben Sie die ID des wiederhergestellten DB-Clusters in DBClusterIdentifier an. Sie können DB-Instances erst erstellen, nachdem die Operation RestoreDBClusterToPointInTime abgeschlossen ist und der DB-Cluster verfügbar ist.

Überprüfen, ob ein DB-Cluster ein kontoübergreifender Klon ist

Das DBClusters-Objekt gibt an, ob der jeweilige Cluster ein kontoübergreifender Klon ist. Sie können die Cluster, für die Sie die Berechtigungen zum Klonen haben, anzeigen, indem Sie die include-shared-Option beim Ausführen des RDS-CLI-Befehls describe-db-clusters verwenden. Sie können jedoch die meisten Konfigurationsdetails für solche Cluster nicht anzeigen.

Überprüfen, ob ein DB-Cluster ein kontoübergreifender Klon ist

  • Rufen Sie den RDS-CLI-Befehl auf describe-db-clusters.

    Das folgende Beispiel zeigt, wie tatsächliche oder potenzielle kontoübergreifende Klon-DB-Cluster in der describe-db-clusters-Ausgabe angezeigt werden. Bei vorhandenen Clustern, die Ihrem AWS Konto gehören, gibt das CrossAccountClone Feld an, ob es sich bei dem Cluster um einen Klon eines DB-Clusters handelt, der einem anderen Konto gehört. AWS

    In einigen Fällen kann ein Eintrag in dem DBClusterArn Feld eine andere AWS Kontonummer als Ihre haben. In diesem Fall steht dieser Eintrag für einen Cluster, der einem anderen AWS Konto gehört und den Sie klonen können. Solche Einträge haben wenige andere Felder als DBClusterArn. Wenn Sie einen geklonten Cluster erstellen, geben Sie dieselben StorageEncrypted-, Engine- und EngineVersion-Werte wie im Original-Cluster an. 

    $aws rds describe-db-clusters --include-shared --region us-east-1
{
  "DBClusters": [
      {
          "EarliestRestorableTime": "2023-02-01T21:17:54.106Z",
          "Engine": "aurora-mysql",
          "EngineVersion": "8.0.mysql_aurora.3.02.0",
          "CrossAccountClone": false,
...
      },
      {
          "EarliestRestorableTime": "2023-02-09T16:01:07.398Z",
          "Engine": "aurora-mysql",
          "EngineVersion": "8.0.mysql_aurora.3.02.0",
          "CrossAccountClone": true,
...
      },
      {
          "StorageEncrypted": false,
          "DBClusterArn": "arn:aws:rds:us-east-1:12345678:cluster:cluster-abcdefgh",
          "Engine": "aurora-mysql",
          "EngineVersion": "8.0.mysql_aurora.3.02.0
  ]
}
Überprüfen, ob ein DB-Cluster ein kontoübergreifender Klon ist

  • Rufen Sie die RDS-API-Operation DescribeDBClusters auf.

    Bei vorhandenen Clustern, die Ihrem AWS Konto gehören, gibt das CrossAccountClone Feld an, ob es sich bei dem Cluster um einen Klon eines DB-Clusters handelt, der einem anderen AWS Konto gehört. Einträge mit einer anderen AWS Kontonummer im DBClusterArn Feld stehen für Cluster, die Sie klonen können und die anderen AWS Konten gehören. Diese Einträge haben wenige andere Felder als DBClusterArn. Wenn Sie einen geklonten Cluster erstellen, geben Sie dieselben StorageEncrypted-, Engine- und EngineVersion-Werte wie im Original-Cluster an.

    Das folgende Beispiel zeigt einen Rückgabewert, der sowohl tatsächliche als auch potenzielle geklonte Cluster zeigt. 

    {
  "DBClusters": [
      {
          "EarliestRestorableTime": "2023-02-01T21:17:54.106Z",
          "Engine": "aurora-mysql",
          "EngineVersion": "8.0.mysql_aurora.3.02.0",
          "CrossAccountClone": false,
...
      },
      {
          "EarliestRestorableTime": "2023-02-09T16:01:07.398Z",
          "Engine": "aurora-mysql",
          "EngineVersion": "8.0.mysql_aurora.3.02.0",
          "CrossAccountClone": true,
...
      },
      {
          "StorageEncrypted": false,
          "DBClusterArn": "arn:aws:rds:us-east-1:12345678:cluster:cluster-abcdefgh",
          "Engine": "aurora-mysql",
          "EngineVersion": "8.0.mysql_aurora.3.02.0"
      }
  ]
}