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:

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 es jedoch auch teilen Aurora Serverless v2 und stellte Aurora-DB-Cluster und -Clones mit anderen AWS Konten bereit. 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:

Funktionsweise des Klonens von Aurora

Das Klonen von Aurora funktioniert auf der Speicherschicht eines Aurora-DB-Clusters. Es verwendet ein copy-on-writeProtokoll, das sowohl schnell als auch platzsparend ist, was die zugrunde liegenden dauerhaften Medien angeht, 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.

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.

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.

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.

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

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

$ aws rds restore-db-cluster-to-point-in-time \
  --source-db-cluster-identifier tpch100g \
  --db-cluster-identifier tpch100g-clone \
  --serverless-v2-scaling-configuration MinCapacity=0.5,MaxCapacity=16 \
  --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.serverless \
  --engine aurora-mysql

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

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

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

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

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

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

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

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

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

aws rds create-db-instance \
    --db-instance-identifier my-new-db \
    --db-cluster-identifier my-clone \
    --db-instance-class db.serverless \
  --engine aurora-postgresql

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

Informationen zu VPC- und kontoübergreifendem Klonen finden Sie in den folgenden Abschnitten.