Clonage d'un volume pour un cluster de base 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é.

Rubriques

• Présentation du clonage Aurora
• Limites du clonage Aurora
• Fonctionnement du clonage Aurora
• Création d'un clone Amazon Aurora
• VPCClonage croisé avec Amazon Aurora
• Clonage entre comptes avec Amazon Aurora AWS RAM et Amazon

Présentation du clonage Aurora

Aurora utilise un copy-on-write protocole pour créer un clone. 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 base de données Aurora source et le nouveau cluster de base 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 base de données Aurora source ou le clone du cluster de base de données Aurora. Pour en savoir plus sur le copy-on-write protocole, voirFonctionnement 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 :

• Expérimentez des changements potentiels (par exemple, des changements de schémas et de groupes de paramètres) pour évaluer tous les impacts.

• Exécutez des opérations imposant une charge de travail élevée, telles que l'exportation de données ou l'exécution de requêtes analytiques sur le clone.

• Créez une copie de votre cluster de base de données de production à des fins de développement, de test ou autres.

Vous pouvez créer plusieurs clones à partir du même cluster de base 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 base 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 base 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 base de données Aurora.

Lorsque vous créez un clone à l'aide d'une configuration de déploiement différente de celle 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 base de données Aurora, les clones sont créés dans votre compte, AWS le même compte qui possède le cluster de base de données Aurora source. Toutefois, vous pouvez également partager Aurora Serverless v2 et provisionner des clusters et des clones de base de données Aurora avec d'autres AWS comptes. Pour de plus amples informations, veuillez consulter 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 :

• Vous pouvez créer autant de clones que vous le souhaitez, jusqu'au nombre maximal de clusters de bases de données autorisés dans la Région AWS.

  Vous pouvez créer les clones à l'aide du copy-on-write protocole ou du protocole de copie intégrale. Le protocole de copie intégrale agit comme une point-in-time restauration.

• Vous ne pouvez pas créer de clone dans une AWS région différente de celle du cluster de base de données Aurora source.

• Vous ne pouvez pas créer un clone à partir d'un cluster de base de données Aurora dépourvu de la fonction de requête parallèle vers un cluster utilisant la fonction de requête parallèle. Pour introduire des données dans un cluster utilisant la fonction de requête parallèle, créez un instantané du cluster d'origine et restaurez-le dans un cluster utilisant la fonction de requête parallèle.

• Vous ne pouvez pas créer de clone à partir d'un cluster de base de données Aurora dépourvu d'instances de base de données. Vous ne pouvez cloner que des clusters de base de données Aurora ayant au moins une instance de base de données.

• Vous pouvez créer un clone dans un cloud privé virtuel (VPC) différent de celui du cluster de base de données Aurora. Dans ce cas, les sous-réseaux de VPCs doivent correspondre aux mêmes zones de disponibilité.

• Vous pouvez créer un clone approvisionné Aurora à partir d'un cluster de base de données Aurora approvisionné.

• Les clusters avec instances Aurora Serverless v2 suivent les mêmes règles que les clusters alloués.

• Dans Aurora Serverless v1 :

  • Vous pouvez créer un clone provisionné à partir d'un Aurora Serverless v1 cluster de base de données.

  • Vous pouvez créer un Aurora Serverless v1 clone à partir d'un cluster de bases de données Aurora Serverless v1 ou d'un cluster de bases de données provisionné.

  • Vous ne pouvez pas créer de Aurora Serverless v1 clone à partir d'un cluster de base de données Aurora provisionné et non chiffré.

  • Actuellement, le clonage entre comptes ne prend pas en charge le clonage de clusters de base de données Aurora Serverless v1. Pour de plus amples informations, veuillez consulter Limites du clonage intercompte.

  • Un cluster de base de données Aurora Serverless v1 cloné a le même comportement et les mêmes limitations que tout cluster de base de données Aurora Serverless v1. Pour de plus amples informations, veuillez consulter Utilisation d'Amazon Aurora Serverless v1.

  • Les clusters de base de données Aurora Serverless v1 sont toujours chiffrés. Lorsque vous clonez un cluster de base de données Aurora Serverless v1 dans un cluster de base de données Aurora approvisionné, le cluster de base de données Aurora approvisionné est chiffré. Vous pouvez choisir la clé de chiffrement, mais pas désactiver le chiffrement. Pour cloner à partir d'un cluster de base de données Aurora provisionné vers unAurora Serverless v1, vous devez commencer par un cluster de base de données Aurora provisionné crypté.

Fonctionnement du clonage Aurora

Le clonage Aurora opère au niveau de la couche de stockage d'un cluster de base de données Aurora. Il utilise un copy-on-writeprotocole à la fois rapide et peu encombrant en termes de support durable sous-jacent supportant le volume de stockage Aurora. Pour plus d'informations sur les volumes de cluster Aurora, consultez Présentation du stockage Amazon Aurora.

Comprendre le copy-on-write protocole

Un cluster de base 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 base 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 base 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 base de données Aurora source.

Lors de la création du clone, aucun stockage supplémentaire n'est généralement nécessaire. Le copy-on-write protocole 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.

Dans les diagrammes suivants, vous pouvez trouver un exemple du copy-on-write protocole en action utilisant le même cluster A et son clone, B, comme indiqué ci-dessus. Supposons que vous apportez une modification à votre cluster de base 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 base 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 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 de clonage est uniquement considéré comme le propriétaire des pages créées ou modifiées par le clone. Ainsi, la VolumeBytesUsed métrique du volume de clonage est faible au départ et ne fait qu'augmenter à mesure que les données divergent entre le cluster d'origine et le clone. Pour les pages 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 appartenaient auparavant au volume du cluster source. Aurora redistribue la facturation du stockage pour les pages appartenant au cluster supprimé. Supposons, par exemple, qu'un cluster d'origine comportait deux clones, puis que le cluster d'origine ait été supprimé. La moitié des pages de données appartenant au cluster d'origine appartiendraient désormais à un clone. L'autre moitié des pages appartiendrait à 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. Ainsi, il se peut que la valeur de la VolumeBytesUsed métrique change pour le volume de cluster d'un clone. La valeur de la métrique peut diminuer à mesure que 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 la métrique peut également augmenter à mesure que des clones sont supprimés et que la propriété des pages est attribuée à un plus petit nombre de clusters. Pour plus d'informations sur la façon dont les opérations d'écriture affectent les pages de données sur les volumes clonés, consultezComprendre le copy-on-write protocole.

Lorsque le cluster d'origine et les clones appartiennent au même AWS compte, tous les frais de stockage de ces clusters s'appliquent à ce même AWS compte. 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 AWS comptes propriétaires des clones entre comptes.

Supposons, par exemple, qu'un volume de cluster comporte 1 000 pages de données utilisées avant de créer des clones. Lorsque vous clonez ce cluster, le volume de clonage 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 de clonage et marquées comme utilisées. Les 900 autres pages inchangées 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 de clonage 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 AWS compte que le cluster de base de données Aurora source. Pour ce faire, vous pouvez utiliser le AWS Management Console ou les AWS CLI et les procédures suivantes.

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

Console

La procédure suivante explique comment cloner un cluster de base de données Aurora à l'aide de l' AWS Management Console.

Création d'un clone à l'aide des AWS Management Console résultats dans un cluster de base de données Aurora avec une instance de base de données Aurora.

Ces instructions s'appliquent aux clusters de base de données appartenant au même AWS compte qui crée le clone. Si le cluster de base de données appartient à un autre AWS compte, consultez Clonage entre comptes avec Amazon Aurora AWS RAM et Amazon plutôt.

Pour créer un clone d'un cluster de base de données appartenant à votre AWS compte à l'aide du AWS Management Console

1. Connectez-vous à la RDS console Amazon AWS Management Console et ouvrez-la à l'adresse https://console.aws.amazon.com/rds/.

2. Dans le panneau de navigation, choisissez Databases (Bases de données).

3. Choisissez votre cluster de base de données Aurora dans la liste, puis, pour Actions, choisissez Create clone (Créer un clone).

   

   La page Créer un clone s'ouvre. Vous pouvez y configurer les options Paramètres, Connectivité et d'autres options pour le clone de cluster de bases de données Aurora.

4. Pour Identifiant d'instance de base de données, entrez le nom que vous souhaitez donner à votre cluster de bases de données Aurora cloné.

5. Pour les clusters Aurora Serverless v1 de base de données, choisissez Provisioned ou Serverless pour le type de capacité.

   Vous ne pouvez choisir Serverless (Sans serveur) que si le cluster de base de données Aurora source est un cluster de base de données Aurora Serverless v1 ou un cluster de base de données Aurora approvisionné qui est chiffré.

6. Pour Aurora Serverless v2 ou pour les clusters de base de données provisionnés, choisissez l'un Aurora I/O-Optimizedou l'autre ou Aurora Standardpour la configuration du stockage en cluster.

   Pour de plus amples informations, veuillez consulter Configurations de stockage pour les clusters de bases de données Amazon Aurora.

7. Choisissez la taille de l'instance de base de données ou la capacité du cluster de bases de données :

   • Pour un clone provisionné, choisissez une classe d'instance de base de données.

     

     Vous pouvez accepter le paramètre fourni ou utiliser une autre classe d'instance de base de données différente pour votre clone.

   • Pour un Aurora Serverless v2 clone Aurora Serverless v1 ou un clone, choisissez les paramètres de capacité.

     

     Vous pouvez accepter les paramètres fournis ou les modifier pour votre clone.

8. Choisissez les autres paramètres nécessaires pour votre clone. Pour en savoir plus sur les paramètres de cluster et d'instance de base de données Aurora, consultez Création d'un cluster de base de données Amazon Aurora.

9. Choisissez Créer un clone.

Une fois le clone créé, il est répertorié avec vos autres clusters de base de données Aurora dans la section Bases de données de la console, et affiche son état actuel. Votre clone est prêt à être utilisé quand son état est Disponible.

AWS CLI

L'utilisation du AWS CLI pour cloner votre cluster de base de données Aurora implique des étapes distinctes pour créer le cluster de clones et y ajouter une ou plusieurs instances de base de données.

La restore-db-cluster-to-point-in-time AWS CLI commande que vous utilisez génère un cluster de base de données Aurora avec les mêmes données de stockage que le cluster d'origine, mais aucune instance de base de données Aurora. Vous créez les instances de base de données séparément une fois le clone disponible. Vous pouvez choisir le nombre d'instances de base de données et leurs classes d'instance pour donner au clone une capacité de calcul supérieure ou inférieure à celle du cluster d'origine. Les étapes du processus sont les suivantes :

1. Créez le clone à l'aide de la point-in-time CLI commande restore-db-cluster-to-.

2. Créez l'instance de base de données Writer pour le clone à l'aide de la create-db-instanceCLIcommande.

3. (Facultatif) Exécutez des create-db-instanceCLIcommandes supplémentaires pour ajouter une ou plusieurs instances de lecteur au cluster de clones. L'utilisation d'instances de lecteur permet d'améliorer les aspects de haute disponibilité et d'évolutivité de lecture du clone. Vous pouvez ignorer cette étape si vous avez l'intention d'utiliser le clone uniquement pour le développement et les tests.

Rubriques

• Création du clone
• Vérification de l'état et obtention des détails du clone
• Création de l'instance de base de données Aurora pour votre clone
• Paramètres à utiliser pour le clonage

Création du clone

Utilisez la restore-db-cluster-to-point-in-time CLI commande pour créer le cluster de clones initial.

Pour créer un clone à partir d'un cluster de base de données Aurora source

• Utilisez la restore-db-cluster-to-point-in-time CLI commande. Spécifiez les valeurs des paramètres suivants. Dans ce cas typique, le clone utilise le même mode moteur que le cluster d'origine, qu'il soit provisionné ouAurora Serverless v1.

  • --db-cluster-identifier – Choisissez un nom explicite pour votre clone. Vous nommez le clone lorsque vous utilisez la point-in-time CLI commande restore-db-cluster-to-. Vous transmettez ensuite le nom du clone dans la create-db-instanceCLIcommande.

  • --restore-type – Utilisez la commande copy-on-write pour créer un clone du cluster de base de données source. Sans ce paramètre, la commande restore-db-cluster-to-point-in-time restaure le cluster de base de données Aurora au lieu de créer un clone.

  • --source-db-cluster-identifier – Utilisez le nom du cluster de base de données Aurora source que vous souhaitez cloner.

  • --use-latest-restorable-time— Cette valeur indique les dernières données de volume restaurables pour le cluster de base de données source. Utilisez-le pour créer des clones.

L'exemple suivant crée un clone nommé my-clone à partir d'un cluster nommé my-source-cluster.

Pour LinuxmacOS, ou Unix :

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

Dans 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

La commande renvoie l'JSONobjet contenant les détails du clone. Vérifiez que votre cluster de base de données cloné est disponible avant d'essayer de créer l'instance de base de données pour votre clone. Pour de plus amples informations, veuillez consulter Vérification de l'état et obtention des détails du clone.

Par exemple, supposons que vous ayez un cluster nommé tpch100g que vous souhaitez cloner. L'exemple Linux suivant crée un cluster cloné nommétpch100g-clone, une instance d'Aurora Serverless v2écriture nommée tpch100g-clone-instance et une instance de lecteur provisionnée nommée tpch100g-clone-instance-2 pour le nouveau cluster.

Vous n'avez pas besoin de fournir certains paramètres, tels que --master-username et --master-user-password. Aurora détermine automatiquement ceux du cluster d'origine. Vous devez spécifier le moteur de base de données à utiliser. Ainsi, l'exemple teste le nouveau cluster pour déterminer la bonne valeur à utiliser pour le paramètre --engine.

Cet exemple inclut également l'--serverless-v2-scaling-configurationoption lors de la création du cluster de clones. Ainsi, vous pouvez ajouter des Aurora Serverless v2 instances au clone même si le cluster d'origine n'a pas été utiliséAurora Serverless v2.

$ 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

Pour créer un clone avec un mode de moteur différent de celui du cluster de base de données Aurora source

• Cette procédure s'applique uniquement aux anciennes versions du moteur compatiblesAurora Serverless v1. Supposons que vous disposiez d'un Aurora Serverless v1 cluster et que vous souhaitiez créer un clone qui soit un cluster provisionné. Dans ce cas, utilisez la restore-db-cluster-to-point-in-time CLI commande et spécifiez des valeurs de paramètres similaires à celles de l'exemple précédent, ainsi que les paramètres supplémentaires suivants :

  • --engine-mode— Utilisez ce paramètre uniquement pour créer des clones dotés d'un mode moteur différent de celui du cluster de base de données Aurora source. Ce paramètre s'applique uniquement aux anciennes versions du moteur compatiblesAurora Serverless v1. Choisissez la valeur à passer avec --engine-mode comme suit :

    • Utilisez --engine-mode provisioned pour créer un clone de cluster de base de données Aurora approvisionné à partir d'un cluster de base de données Aurora Serverless.

      Note

      Si vous avez l'intention de l'utiliser Aurora Serverless v2 avec un cluster à partir duquel vous avez été clonéAurora Serverless v1, vous devez toujours spécifier le mode moteur du clone sous provisioned la forme. Vous devez ensuite effectuer des étapes supplémentaires de mise à niveau et de migration.

    • --engine-mode serverlessÀ utiliser pour créer un Aurora Serverless v1 clone à partir d'un cluster de base de données Aurora provisionné. Lorsque vous spécifiez le mode serverless moteur, vous pouvez également choisir le--scaling-configuration.

  • --scaling-configuration— (Facultatif) Utilisez avec --engine-mode serverless pour configurer la capacité minimale et maximale d'un Aurora Serverless v1 clone. Si vous n'utilisez pas ce paramètre, Aurora crée un Aurora Serverless v1 clone en utilisant les valeurs de Aurora Serverless v1 capacité par défaut du moteur de base de données.

L'exemple suivant crée un clone provisionné nommémy-clone, à partir d'un Aurora Serverless v1 cluster de base de données nommémy-source-cluster.

Pour LinuxmacOS, ou Unix :

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

Dans Windows :

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

Ces commandes renvoient l'JSONobjet contenant les détails du clone dont vous avez besoin pour créer l'instance de base de données. Vous ne pouvez pas faire cela tant que l'état du clone (le cluster de base de données Aurora vide) n'est pas Disponible.

Note

La point-in-time AWS CLI commande restore-db-cluster-to- restaure uniquement le cluster de base de données, pas les instances de base de données pour ce cluster de base de données. Vous exécutez la create-db-instancecommande pour créer des instances de base de données pour le cluster de base de données restauré. Avec cette commande, vous spécifiez l'identifiant du cluster de base de données restauré en tant que --db-cluster-identifier paramètre. Vous pouvez créer des instances de bases de données uniquement après la fin de la commande restore-db-cluster-to-point-in-time et lorsque le cluster de bases de données est disponible.

Supposons que vous commenciez par un Aurora Serverless v1 cluster et que vous avez l'intention de le migrer vers un Aurora Serverless v2 cluster. Vous créez un clone provisionné du Aurora Serverless v1 cluster comme première étape de la migration. Pour la procédure complète, y compris les mises à niveau de version requises, voirMise à niveau d'un cluster Aurora Serverless v1 vers Aurora Serverless v2.

Vérification de l'état et obtention des détails du clone

Vous pouvez utiliser la commande suivante pour vérifier l'état du cluster de clones que vous venez de créer.

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

Vous pouvez également obtenir le statut et les autres valeurs dont vous avez besoin pour créer l'instance de base de données pour votre clone à l'aide de la AWS CLI requête suivante.

Pour LinuxmacOS, ou Unix :

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

Dans Windows :

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

Cette requête retourne une sortie similaire à la suivante.

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

Création de l'instance de base de données Aurora pour votre clone

Utilisez la create-db-instanceCLIcommande pour créer l'instance de base de données pour votre clone Aurora Serverless v2 ou pour le clone provisionné. Vous ne créez pas d'instance de base de données pour un Aurora Serverless v1 clone.

L'instance de base de données hérite des --master-user-password propriétés --master-username et du cluster de base de données source.

L'exemple suivant crée une instance de base de données pour un clone provisionné.

Pour LinuxmacOS, ou Unix :

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

Dans Windows :

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

L'exemple suivant crée une Aurora Serverless v2 instance de base de données, pour un clone qui utilise une version de moteur compatibleAurora Serverless v2.

Pour LinuxmacOS, ou Unix :

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

Dans Windows :

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

Paramètres à utiliser pour le clonage

Le tableau suivant récapitule les différents paramètres utilisés avec la commande restore-db-cluster-to-point-in-time pour cloner des clusters de base de données Aurora.

Paramètre	Description
--source-db-cluster-identifier	Utilisez le nom du cluster de base de données Aurora source que vous souhaitez cloner.
--db-cluster-identifier	Choisissez un nom significatif pour votre clone lorsque vous le créez à l'aide de la restore-db-cluster-to-point-in-time commande. Ensuite, vous passez ce nom à la commande create-db-instance.
--restore-type	Spécifiez copy-on-write en tant que --restore-type pour créer un clone du cluster de base de données source au lieu de restaurer le cluster de base de données Aurora source.
--use-latest-restorable-time	Cette valeur indique les dernières données de volume restaurables pour le cluster de base de données source. Utilisez-le pour créer des clones.
--serverless-v2-scaling-configuration	(Versions plus récentes compatiblesAurora Serverless v2) Utilisez ce paramètre pour configurer la capacité minimale et maximale d'un Aurora Serverless v2 clone. Si vous ne spécifiez pas ce paramètre, vous ne pouvez créer aucune Aurora Serverless v2 instance dans le cluster de clones tant que vous n'avez pas modifié le cluster pour ajouter cet attribut.
--engine-mode	(Anciennes versions compatibles Aurora Serverless v1 uniquement) Utilisez ce paramètre pour créer des clones d'un type différent de celui du cluster de base de données Aurora source, avec l'une des valeurs suivantes : provisionedÀ utiliser pour créer un clone provisionné à partir d'un Aurora Serverless v1 cluster de base de données. serverlessÀ utiliser pour créer un Aurora Serverless v1 clone à partir d'un cluster provisionné ou d'un Aurora Serverless v2 cluster de base de données. Lorsque vous spécifiez le mode serverless moteur, vous pouvez également choisir le--scaling-configuration.
--scaling-configuration	(Anciennes versions compatibles Aurora Serverless v1 uniquement) Utilisez ce paramètre pour configurer la capacité minimale et maximale d'un Aurora Serverless v1 clone. Si vous ne spécifiez pas ce paramètre, Aurora crée le clone en utilisant les valeurs de capacité par défaut du moteur de base de données.

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

Rubriques

• VPCClonage croisé avec Amazon Aurora
• Clonage entre comptes avec Amazon Aurora AWS RAM et Amazon