Clonage d’un volume pour un cluster de bases de données Amazon Aurora

Le clonage Aurora vous permet de créer un nouveau cluster qui partage les mêmes pages de données que l’original, mais qui est un volume distinct et indépendant. Le processus est conçu pour être rapide et rentable. Le nouveau cluster avec son volume de données associé est appelé clone. La création d’un clone est plus rapide et plus économe en espace que la copie physique des données à l’aide d’autres techniques telles que la restauration d’instantané.

Présentation du clonage Aurora

Pour créer un clone, Aurora utilise un protocole de copie sur écriture. Ce mécanisme utilise un espace supplémentaire minimal pour créer un clone initial. Lors de la création du premier clone, Aurora conserve une seule copie des données qu’utilisent le cluster de bases de données Aurora source et le nouveau cluster de bases de données Aurora (cloné). Un stockage supplémentaire n’est alloué que quand des modifications sont apportées aux données (sur le volume de stockage Aurora) par le cluster de bases de données Aurora source ou le clone du cluster de bases de données Aurora. Pour en savoir plus sur le protocole de copie sur écriture, consultez Fonctionnement du clonage Aurora.

Le clonage Aurora est particulièrement utile pour configurer rapidement des environnements de test à l’aide de vos données de production, sans risque de corruption des données. Vous pouvez utiliser des clones pour de nombreux types d’applications, telles que les suivantes :

Vous pouvez créer plusieurs clones à partir du même cluster de bases de données Aurora. Vous pouvez également créer plusieurs clones à partir d’un autre clone.

Après avoir créé un clone Aurora, vous pouvez configurer les instances de base de données Aurora différemment du cluster de bases de données Aurora source. Par exemple, il se peut que vous n’ayez pas besoin d’un clone à des fins de développement pour répondre aux mêmes exigences de haute disponibilité que le cluster de bases de données Aurora de production source. Dans ce cas, vous pouvez configurer le clone avec une seule instance de base de données Aurora plutôt que les multiples instances de base de données qu’utilise le cluster de bases de données Aurora.

Lorsque vous créez un clone à l’aide d’une configuration de déploiement différente de la source, le clone est créé à l’aide de la dernière version mineure du moteur de base de données Aurora de la source.

Lorsque vous créez des clones à partir de vos clusters de bases de données Aurora, les clones sont créés dans votre compte AWS contenant déjà le cluster de bases de données Aurora source. Toutefois, vous pouvez également partager des clusters de bases de données Aurora provisionnés et Aurora Serverless v2 et des clones avec d’autres comptes AWS. Pour plus d’informations, consultez Clonage entre comptes avec Amazon Aurora AWS RAM et Amazon.

Lorsque vous avez fini d’utiliser le clone à des fins de test, de développement ou autres, vous pouvez le supprimer.

Limites du clonage Aurora

Le clonage Aurora présente actuellement les limitations suivantes :

Fonctionnement du clonage Aurora

Le clonage Aurora opère au niveau de la couche de stockage d’un cluster de bases de données Aurora. Il utilise un protocole de copie sur écriture à la fois rapide et économe en espace s’agissant du support durable sous-jacent du volume de stockage Aurora. Pour plus d’informations sur les volumes de cluster Aurora, consultez Présentation du stockage Amazon Aurora.

Présentation du protocole de copie sur écriture

Un cluster de bases de données Aurora stocke des données dans des pages du volume de stockage Aurora sous-jacent.

Par exemple, le diagramme suivant montre un cluster de bases de données Aurora (A) comptant quatre pages de données, 1, 2, 3 et 4. Imaginez qu’un clone, B, soit créé à partir du cluster de bases de données Aurora. Lors de la création du clone, aucune donnée n’est copiée. Au contraire, le clone pointe vers le même ensemble de pages que le cluster de bases de données Aurora source.

Lors de la création du clone, aucun stockage supplémentaire n’est généralement nécessaire. Le protocole de copie sur écriture utilise le même segment sur le support de stockage physique que le segment source. Un stockage supplémentaire n’est requis que si la capacité du segment source n’est pas suffisante pour le segment de clone entier. Dans ce cas, le segment source est copié sur un autre périphérique physique.

Les diagrammes suivants présentent un exemple de protocole de copie sur écriture en action utilisant les cluster A et clone B que ceux montrés précédemment. Supposons que vous apportez une modification à votre cluster de bases de données Aurora (A) qui entraîne un changement des données conservées sur la page 1. Au lieu d’écrire sur la page 1 d’origine, Aurora crée une nouvelle page 1[A]. Le volume de cluster de bases de données Aurora pour le cluster (A) pointe désormais vers les pages 1[A], 2, 3 et 4, tandis que le clone (B) continue de référencer les pages d’origine.

Sur le clone, une modification est apportée à la page 4 sur le volume de stockage. Au lieu d’écrire sur la page 4 d’origine, Aurora crée une nouvelle page 1[B]. Le clone pointe maintenant vers les pages 1, 2, 3 et 4[B], tandis que le cluster (A) continue de pointer vers les pages 1[A], 2, 3 et 4.

A mesure que des modifications supplémentaires sont apportées tant au volume de cluster Aurora source qu’au clone, plus de stockage est nécessaire pour capturer et stocker les modifications.

Suppression d’un volume de cluster source

Au départ, le volume du clone partage les mêmes pages de données que le volume d’origine à partir duquel le clone est créé. Tant que le volume d’origine existe, le volume du clone est uniquement considéré comme le propriétaire des pages créées ou modifiées par ce clone. La métrique VolumeBytesUsed du volume du clone est donc faible au départ et augmente uniquement à mesure que les données divergent entre le cluster d’origine et le clone. Pour les pages qui sont identiques entre le volume source et le clone, les frais de stockage s’appliquent uniquement au cluster d’origine. Pour plus d’informations sur la métrique VolumeBytesUsed, consultez Métriques de niveau cluster pour Amazon Aurora.

Lorsque vous supprimez un volume de cluster source auquel un ou plusieurs clones sont associés, les données des volumes de cluster des clones ne sont pas modifiées. Aurora préserve les pages qui étaient précédemment la propriété du volume de cluster source. Aurora redistribue la facturation du stockage pour les pages qui appartenaient au cluster supprimé. Supposons, par exemple, qu’un cluster d’origine associé à deux clones soit supprimé. La moitié des pages de données qui étaient la propriété du cluster d’origine appartiennent maintenant à un clone. L’autre moitié des pages appartient à l’autre clone.

Si vous supprimez le cluster d’origine, au fur et à mesure que vous créez ou supprimez d’autres clones, Aurora continue de redistribuer la propriété des pages de données entre tous les clones partageant les mêmes pages. Il se peut donc que la valeur de la métrique VolumeBytesUsed change pour le volume de cluster d’un clone. La valeur de cette métrique peut diminuer lorsque de nouveaux clones sont créés et que la propriété des pages est répartie sur un plus grand nombre de clusters. La valeur de cette métrique peut également augmenter lorsque des clones sont supprimés et que la propriété des pages est attribuée à un plus petit nombre de clusters. Pour en savoir plus sur l’impact des opérations d’écriture sur les pages de données des volumes des clones, consultez Présentation du protocole de copie sur écriture.

Lorsque le cluster d’origine et les clones appartiennent au même compte AWS, tous les frais de stockage de ces clusters s’appliquent à ce même compte AWS. Si certains clusters sont des clones entre comptes, la suppression du cluster d’origine peut entraîner des frais de stockage supplémentaires pour les comptes AWS propriétaires des clones entre comptes.

Supposons, par exemple, qu’un volume de cluster compte 1 000 pages de données utilisées avant de créer des clones. Lorsque vous clonez ce cluster, le volume du clone ne contient initialement aucune page utilisée. Si le clone apporte des modifications à 100 pages de données, seules ces 100 pages sont stockées sur le volume du clone et marquées comme utilisées. Les 900 pages inchangées restantes du volume parent sont partagées par les deux clusters. Dans ce cas, le cluster parent facture des frais de stockage pour 1 000 pages et le volume du clone pour 100 pages.

Si vous supprimez le volume source, les frais de stockage pour le clone incluent les 100 pages modifiées, plus les 900 pages partagées du volume d’origine, pour un total de 1 000 pages.

Création d’un clone Amazon Aurora

Vous pouvez créer un clone dans le même compte AWS que celui du cluster de bases de données Aurora source. Pour ce faire, vous pouvez utiliser l’AWS Management Console ou l’AWS CLI et les procédures suivantes.

Pour autoriser un autre compte AWS à créer un clone, ou pour partager un clone avec un autre compte AWS, suivez les procédures décrites dans Clonage entre comptes avec Amazon Aurora AWS RAM et Amazon.

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

Pour plus d’informations sur le clonage entre VPC et entre comptes, consultez les sections suivantes.