Clonazione di un volume per un cluster di database Amazon Aurora

La clonazione di Aurora ti consente di creare un nuovo cluster che abbia inizialmente le stesse pagine di dati dell'originale, ma sia un volume separato e indipendente. Il processo è progettato per essere veloce e conveniente. Il nuovo cluster con il relativo volume di dati associato è noto come clone. La creazione di un clone è più veloce ed efficiente in termini di spazio rispetto alla copia fisica dei dati utilizzando una tecnica diversa, ad esempio con il ripristino di uno snapshot.

Panoramica sulla clonazione Aurora

Aurora utilizza un copy-on-write protocollo per creare un clone. Questo meccanismo utilizza uno spazio aggiuntivo minimo per creare un clone iniziale. Quando il clone viene creato per la prima volta, Aurora conserva una singola copia dei dati utilizzati dal cluster database Aurora di origine e dal nuovo cluster database Aurora (clonato). L'archiviazione aggiuntiva viene allocata solo quando vengono apportate modifiche ai dati (sul volume di archiviazione Aurora) dal cluster database Aurora di origine o dal clone del cluster database Aurora. Per ulteriori informazioni sul copy-on-write protocollo, consulta. Come funziona la clonazione Aurora

La clonazione Aurora è particolarmente utile per configurare rapidamente ambienti di test utilizzando i dati di produzione, senza rischiare il danneggiamento dei dati. È possibile utilizzare i cloni per molti tipi di applicazioni di breve durata, ad esempio:

È possibile creare più di un clone dallo stesso cluster database Aurora. È anche possibile creare più cloni da un altro clone.

Dopo aver creato un clone Aurora, è possibile configurare le istanze database Aurora in modo diverso dal cluster database Aurora di origine. Ad esempio, potrebbe non essere necessario un clone per scopi di sviluppo per soddisfare gli stessi requisiti di alta disponibilità del cluster database Aurora di produzione di origine. In questo caso, è possibile configurare il clone con una singola istanza database Aurora anziché con più istanze database utilizzate dal cluster database Aurora.

Quando si crea un clone utilizzando una configurazione di distribuzione diversa da quella di origine, il clone viene creato utilizzando l'ultima versione secondaria del motore Aurora DB della sorgente.

Quando crei cloni dai tuoi cluster Aurora DB, i cloni vengono creati nel AWS tuo account, lo stesso account che possiede il cluster Aurora DB di origine. Tuttavia, puoi anche condividere Aurora Serverless v2 e ha fornito cluster e cloni Aurora DB con altri account. AWS Per ulteriori informazioni, consulta Clonazione tra account con AWS RAM e Amazon Aurora.

Una volta terminato di utilizzare il clone per test, sviluppo o altri scopi, è possibile eliminarlo.

Limitazioni della clonazione Aurora

La clonazione Aurora presenta le seguenti limitazioni:

Come funziona la clonazione Aurora

La clonazione Aurora funziona a livello di archiviazione di un cluster database Aurora. Utilizza un copy-on-writeprotocollo veloce ed efficiente in termini di supporti durevoli sottostanti che supportano il volume di archiviazione Aurora. Per ulteriori informazioni, consulta la sezione relativa ai volumi cluster Aurora in Panoramica dell'archiviazione di Amazon Aurora.

Comprensione del protocollo copy-on-write

Un cluster database Aurora memorizza i dati nelle pagine del volume di archiviazione Aurora sottostante.

Ad esempio, nel diagramma seguente puoi vedere un cluster database Aurora (A) con quattro pagine dati, 1, 2, 3 e 4. Immagina che un clone, B, venga creato dal cluster database Aurora. Quando viene creato il clone, non viene copiato alcun dato. Piuttosto, il clone punta allo stesso insieme di pagine del cluster database Aurora di origine.

Quando viene creato il clone, in genere non è necessario alcuno spazio di archiviazione aggiuntivo. Il copy-on-write protocollo utilizza lo stesso segmento sul supporto di archiviazione fisico del segmento di origine. Lo spazio di archiviazione aggiuntivo è necessario solo se la capacità del segmento di origine non è sufficiente per l'intero segmento di clone. In questo caso, il segmento di origine viene copiato su un altro dispositivo fisico.

Nei diagrammi seguenti, è possibile trovare un esempio del copy-on-write protocollo in azione che utilizza lo stesso cluster A e il suo clone, B, come mostrato in precedenza. Supponiamo che si apporti una modifica al cluster database Aurora (A) che si traduce in una modifica ai dati contenuti a pagina 1. Invece di scrivere sulla pagina originale 1, Aurora crea una nuova pagina 1[A]. Il volume del cluster database Aurora per cluster (A) punta ora alla pagina 1[A], 2, 3 e 4, mentre il clone (B) fa ancora riferimento alle pagine originali.

Sul clone, viene apportata una modifica a pagina 4 sul volume di archiviazione. Invece di scrivere sulla pagina originale 4, Aurora crea una nuova pagina 4[B]. Il clone punta ora alle pagine 1, 2, 3 e alla pagina 4[B], mentre il cluster (A) continua a puntare a 1[A], 2, 3 e 4.

Quando nel corso del tempo si verificano altre modifiche sia nel volume del cluster database Aurora di origine che nel clone, avrai bisogno di più spazio di archiviazione per acquisire e archiviare tali modifiche.

Eliminazione di un volume cluster di origine

Inizialmente, il volume clone condivide le stesse pagine di dati del volume originale da cui viene creato il clone. Finché esiste il volume originale, il volume clone viene considerato solo il proprietario delle pagine che il clone ha creato o modificato. Pertanto, la VolumeBytesUsed metrica per il volume clone all'inizio è piccola e cresce solo quando i dati divergono tra il cluster originale e il clone. Per le pagine identiche tra il volume di origine e il clone, i costi di archiviazione si applicano solo al cluster originale. Per ulteriori informazioni sul parametro VolumeBytesUsed, consulta Parametri a livello di cluster per Amazon Aurora.

Quando si elimina un volume del cluster di origine a cui sono associati uno o più cloni, i dati nei volumi del cluster dei cloni non vengono modificati. Aurora conserva le pagine che in precedenza erano di proprietà del volume del cluster di origine. Aurora ridistribuisce la fatturazione dello spazio di archiviazione per le pagine di proprietà del cluster eliminato. Ad esempio, supponiamo che un cluster originale avesse due cloni e che quindi il cluster originale sia stato eliminato. La metà delle pagine di dati di proprietà del cluster originale ora sarebbe di proprietà di un clone. L'altra metà delle pagine sarebbe di proprietà dell'altro clone.

Se elimini il cluster originale, man mano che crei o elimini altri cloni, Aurora continua a ridistribuire la proprietà delle pagine di dati tra tutti i cloni che condividono le stesse pagine. Pertanto, è possibile che il valore della VolumeBytesUsed metrica cambi per il volume del cluster di un clone. Il valore della metrica può diminuire man mano che vengono creati più cloni e la proprietà della pagina viene distribuita su più cluster. Il valore della metrica può inoltre aumentare man mano che i cloni vengono eliminati e la proprietà della pagina viene assegnata a un numero inferiore di cluster. Per informazioni su come le operazioni di scrittura influiscono sulle pagine di dati sui volumi clonati, consulta. Comprensione del protocollo copy-on-write

Quando il cluster originale e i cloni sono di proprietà dello stesso AWS account, tutti i costi di archiviazione per tali cluster si applicano allo stesso account. AWS Se alcuni cluster sono cloni con più account, l'eliminazione del cluster originale può comportare costi di archiviazione aggiuntivi per gli account che possiedono i cloni su più AWS account.

Ad esempio, supponiamo che un volume del cluster contenga 1000 pagine di dati utilizzate prima di creare qualsiasi clone. Quando clonate quel cluster, inizialmente il volume clone ha zero pagine utilizzate. Se il clone apporta modifiche a 100 pagine di dati, solo quelle 100 pagine vengono memorizzate nel volume clone e contrassegnate come utilizzate. Le altre 900 pagine invariate del volume principale sono condivise da entrambi i cluster. In questo caso, il cluster principale prevede costi di archiviazione per 1000 pagine e il volume clone per 100 pagine.

Se si elimina il volume di origine, i costi di archiviazione per il clone includono le 100 pagine modificate, più le 900 pagine condivise del volume originale, per un totale di 1000 pagine.

Creazione di un clone Amazon Aurora

È possibile creare un clone nello stesso AWS account del cluster Aurora DB di origine. A tale scopo, è possibile utilizzare AWS Management Console o AWS CLI le procedure seguenti.

Per consentire a un altro AWS account di creare un clone o di condividere un clone con un altro AWS account, utilizzare le procedure riportate in. Clonazione tra account con AWS RAM e 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

Per informazioni sulla clonazione tra VPC e più account, consulta le seguenti sezioni.