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

Per creare un clone, Aurora utilizza un protocollo copy-on-write. 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 protocollo copy-on-write, 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.

In caso di creazione di un clone con una configurazione di implementazione diversa da quella di origine, il clone viene creato utilizzando la versione secondaria più recente del motore di database Aurora di origine.

Quando crei cloni dai cluster database Aurora, i cloni vengono creati nell’account AWS, lo stesso account proprietario del cluster database Aurora di origine. Tuttavia, è anche possibile condividere Aurora Serverless v2, i cluster di database Aurora con provisioning e i cloni 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 protocollo copy-on-write, veloce ed efficiente in termini di spazio per il supporto durevole sottostante che supporta il volume di archiviazione Aurora. Per ulteriori informazioni, consulta la sezione relativa ai volumi cluster Aurora in Panoramica dell'archiviazione di Amazon Aurora.

Informazioni sul 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 protocollo copy-on-write 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, puoi un esempio del protocollo copy-on-write in azione utilizzando lo stesso cluster A e il relativo clone, B, come illustrato 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 a partire dal quale 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 metrica VolumeBytesUsed per il volume clone all’inizio ha un valore ridotto, che aumenta solo quando i dati divergono tra il cluster originale e il clone. Per le pagine che sono identiche nel volume di origine e nel 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 cluster di origine a cui sono associati uno o più cloni, i dati nei volumi cluster dei cloni non sono interessati dall’operazione. Aurora conserva le pagine che in precedenza erano di proprietà del volume cluster di origine. Aurora ridistribuisce la fatturazione dello spazio di archiviazione per le pagine che erano di proprietà del cluster eliminato. Supponiamo, ad esempio, che un cluster originale avesse due cloni e che a un certo punto il cluster originale sia stato eliminato. Di conseguenza, la metà delle pagine di dati di proprietà del cluster originale sarebbe di proprietà di un clone, mentre l’altra metà delle pagine sarebbe di proprietà dell’altro clone.

Una volta eliminato 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. Potresti pertanto riscontrare che il valore della metrica VolumeBytesUsed cambia per il volume del cluster di un clone. Il valore della metrica può diminuire man mano che vengono creati altri cloni e la proprietà delle pagine viene distribuita tra più cluster. Inoltre, il valore della metrica può aumentare man mano che i cloni vengono eliminati e la proprietà delle pagine viene assegnata a un numero inferiore di cluster. Per informazioni sull’impatto delle operazioni di scrittura sulle pagine di dati nei volumi clonati, consulta Informazioni sul protocollo copy-on-write.

Quando il cluster originale e i cloni sono di proprietà dello stesso account AWS, tutti i costi di archiviazione per tali cluster si applicano allo stesso account AWS. Se alcuni cluster sono cloni multi-account, l’eliminazione del cluster originale può comportare l’addebito di costi di archiviazione aggiuntivi agli account AWS che possiedono i cloni multi-account.

Supponiamo, ad esempio, che un volume cluster abbia 1.000 pagine di dati utilizzate prima della creazione di uno o più cloni. Quando il cluster viene clonato, 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 del volume principale, che sono rimaste invariate, sono condivise da entrambi i cluster. In questo caso, il cluster principale prevede costi di archiviazione per 1.000 pagine e il volume clone per 100 pagine.

Se il volume di origine viene eliminato, i costi di archiviazione per il clone vanno a includere le 100 pagine modificate più le 900 pagine condivise dal volume originale, per un totale di 1.000 pagine.

Creazione di un clone Amazon Aurora

È possibile creare un clone nello stesso account AWS del cluster database Aurora di origine. A tale scopo, è possibile utilizzare la Console di gestione AWS o la AWS CLI e le procedure riportate di seguito.

Per consentire a un altro account AWS di creare un clone o condividere un clone con un altro account AWS, utilizzare le procedure descritte 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 multi-VPC e multi-account, consulta le seguenti sezioni.