Clonage d'un volume pour un cluster de base de données Amazon Aurora - Amazon Aurora
Présentation du clonage AuroraLimites du clonage AuroraFonctionnement du clonage AuroraCréation d'un clone AuroraClonage intercompte

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

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é.

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 contenant déjà 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 plus d'informations, consultez Clonage entre comptes avec AWS RAM et Amazon Aurora.

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 région AWS différente de celle du cluster de bases 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 virtual private cloud (VPC) différent de celui du cluster de base de données Aurora. Cependant, les sous-réseaux des VPC doivent mapper 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 plus d'informations, consultez 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 plus d'informations, consultez 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 depuis 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é chiffré.

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.

Volume de cluster Amazon Aurora avec 4 pages pour le cluster source, A, et le clone, B

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.

Volume de cluster de base de données Amazon Aurora source et son clone, tous deux avec les modifications.

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.

Volume de cluster de base de données Amazon Aurora source et son clone, tous deux avec les modifications.

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

Lorsque vous supprimez un volume de cluster source auquel un ou plusieurs clones sont associés, ceux-ci ne sont pas affectés. Les clones continuent de pointer vers les pages qui étaient précédemment la propriété du volume de cluster source.

Création d'un clone Amazon Aurora

Vous pouvez créer un clone dans le même compte AWS que celui du cluster de base 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 AWS RAM et Amazon Aurora.

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 résultat de l'AWS Management Console 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 compte AWS que celui qui crée le clone. Si le cluster de bases de données appartient à un compte AWS différent, consultez plutôt Clonage entre comptes avec AWS RAM et Amazon Aurora.

Pour créer un clone d'un cluster de bases de données appartenant à votre compte AWS via AWS Management Console

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

  2. Dans la 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 création d'un clone commence par la sélection de votre cluster de base de données Aurora.

    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 plus d'informations, consultez 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.

      Pour créer un clone provisionné, spécifiez la taille de l'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é.

      Pour créer un clone Serverless à partir d'un cluster de base de données Aurora, spécifiez la 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.

L'utilisation de l'AWS CLI pour cloner votre cluster de base de données Aurora nécessite quelques étapes.

La commande de l'AWS CLI restore-db-cluster-to-point-in-time que vous utilisez produit un cluster de base de données Aurora vide contenant 0 instance de base de données Aurora. Autrement dit, la commande restaure uniquement le cluster de base de données Aurora, pas les instances de base de données pour ce cluster. Vous faites cela séparément une fois le clone disponible. Les deux étapes du processus sont les suivantes :

  1. Créez le clone à l'aide de la commande restore-db-cluster-to- point-in-time CLI. Les paramètres que vous utilisez avec cette commande contrôlent le type de capacité et d'autres détails du cluster (clone) de base de données Aurora vide créé.

  2. Créez l'instance de base de données Aurora pour le clone à l'aide de la commande create-db-instanceCLI pour recréer l'instance de base de données Aurora dans le cluster de base de données Aurora restauré.

Création du clone

Les paramètres spécifiques que vous passez à la commande de la CLI restore-db-cluster-to-point-in-time varient. Ce que vous passez dépend du type de mode moteur du cluster de base de données source (Serverless ou Provisioned) et du type de clone que vous souhaitez créer.

Pour créer un clone du même mode moteur que le cluster de base de données Aurora source

  • Utilisez la commande de la CLI restore-db-cluster-to-point-in-time et spécifiez les valeurs des paramètres suivants :

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

    • --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'objet JSON 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 plus d'informations, consultez Vérification de l'état et obtention des détails du clone.

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

  • Utilisez la commande de la CLI restore-db-cluster-to-point-in-time et spécifiez les valeurs des paramètres suivants :

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

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

    • --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.

    • --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.

    • --engine-mode— (Facultatif) Utilisez ce paramètre uniquement pour créer des clones d'un type différent de celui du cluster de base de données Aurora source. Choisissez la valeur à passer avec --engine-mode comme suit :

      • Utilisez 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.

      • Utilisez serverless pour créer un clone de cluster de base de données Aurora Serverless v1 à partir d'un cluster de base de données Aurora approvisionné. 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 le clone en utilisant les valeurs de capacité par défaut du moteur de base de données.

    • --serverless-v2-scaling-configuration— (Facultatif) Utilisez ce paramètre pour configurer la capacité minimale et maximale d'un Aurora Serverless v2 clone. Si vous n'utilisez 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.

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

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 serverless \
    --scaling-configuration MinCapacity=8,MaxCapacity=64 \
    --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 serverless ^
    --scaling-configuration MinCapacity=8,MaxCapacity=64 ^
    --restore-type copy-on-write ^
    --use-latest-restorable-time

Ces commandes renvoient l'objet JSON 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 commande restore-db-cluster-to- point-in-time AWS CLI 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 devez appeler la create-db-instancecommande pour créer des instances de base de données pour le cluster de base de données restauré, en spécifiant l'identifiant du cluster de base de données restauré dans--db-cluster-identifier. 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.

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 et une instance principale nommée tpch100g-clone-instance 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.

$ aws rds restore-db-cluster-to-point-in-time \
  --source-db-cluster-identifier tpch100g \
  --db-cluster-identifier tpch100g-clone \
  --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.r5.4xlarge \
  --engine aurora-mysql

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

Vous pouvez utiliser la commande suivante pour vérifier l'état de votre cluster de base de données vide nouvellement créé.

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

Ou vous pouvez obtenir l'état et les autres valeurs dont vous avez besoin pour créer l'instance de base de données pour votre clone en utilisant la requête de l'AWS CLI 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 commande create-db-instanceCLI 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.r5.4xlarge \
    --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.r5.4xlarge ^
    --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.

--engine-mode

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 provisionné ou un Aurora Serverless v2 clone à 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

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.
--serverless-v2-scaling-configuration

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, Aurora crée le clone en utilisant les valeurs de capacité par défaut du moteur de base de données.

Clonage entre comptes avec AWS RAM et Amazon Aurora

En utilisant AWS Resource Access Manager (AWS RAM) avec Amazon Aurora, vous pouvez partager des clusters de base de données Aurora et des clones appartenant à votre compte AWS avec un autre compte AWS ou une autre organisation. Un tel clonage entre comptes est beaucoup plus rapide que la création et la restauration d'un instantané de base de données. Vous pouvez créer un clone d'un de vos clusters de base de données Aurora et partager le clone. Vous pouvez également partager votre cluster de base de données Aurora avec un autre compte AWS et laisser le titulaire de celui-ci à créer le clone. L'approche que vous choisissez dépend de votre cas d'utilisation.

Par exemple, il se peut que vous deviez partager régulièrement un clone de votre base de données financière avec l'équipe d'audit interne de votre organisation. Dans ce cas, votre équipe d'audit dispose de son propre compte AWS pour les applications qu'elle utilise. Vous pouvez donner au compte AWS de l'équipe d'audit l'autorisation d'accéder à votre cluster de base de données Aurora et de le cloner si nécessaire.

D'un autre côté, si un fournisseur externe audite vos données financières, vous pouvez créer vous-même le clone. Vous donnez ensuite au fournisseur externe l'accès au clone uniquement.

Vous pouvez également utiliser un clonage entre comptes pour prendre en charge bon nombre des mêmes cas d'utilisation pour le clonage au sein du même compte AWS, tels que le développement et les tests. Par exemple, votre organisation peut utiliser des comptes AWS différents pour la production, le développement, les tests, etc. Pour plus d'informations, consultez Présentation du clonage Aurora.

Par conséquent, vous pouvez partager un clone avec un autre compte AWS ou autoriser un autre compte AWS à créer des clones de vos clusters de base de données Aurora. Dans les deux cas, commencez par utiliser AWS RAM pour créer un objet de partage. Pour obtenir des informations détaillées sur le partage de ressources AWS entre comptes AWS, consultez le Guide de l'utilisateur AWS RAM.

La création d'un clone intercompte requiert des actions depuis le compte AWS propriétaire du cluster original et le compte AWS qui crée le clone. D'abord, le propriétaire du cluster d'origine modifie le cluster pour autoriser un ou plusieurs autres comptes à le cloner. Si l'un des comptes est dans une autre organisation AWS, AWS génère une invitation de partage. L'autre compte doit accepter l'invitation avant de continuer. Ensuite, chaque compte autorisé peut cloner le cluster. À travers ce processus, le cluster est identifié par son unique ARN.

Comme pour un clonage dans le même compte AWS, l'espace de stockage supplémentaire n'est utilisé que si des modifications sont apportées aux données par la source ou le clone. Des frais de stockage sont alors appliqués. Si le cluster source est supprimé, les coûts de stockage sont répartis également entre les clusters clonés restants.

Limites du clonage intercompte

Le clonage intercompte Aurora présente les limitations suivantes :

  • Vous ne pouvez pas cloner un cluster Aurora Serverless v1 entre comptes AWS.

  • Vous ne pouvez pas afficher ou accepter des invitations à des ressources partagées avec l'AWS Management Console. Utilisez l'AWS CLI, l'API Amazon RDS ou la console AWS RAM pour afficher et accepter des invitations à des ressources partagées.

  • Vous ne pouvez créer qu'un seul nouveau clone à partir d'un clone qui a été partagé avec votre compte AWS.

  • Vous ne pouvez pas partager de ressources (clones ou clusters de base de données Aurora) qui ont été partagées avec votre compte AWS.

  • Vous pouvez créer un maximum de 15 clones entre comptes à partir d'un seul cluster de base de données Aurora.

  • Chacun des 15 clones entre comptes doit être détenu par un compte AWS différent. Autrement dit, vous ne pouvez créer qu'un seul clone entre comptes d'un cluster au sein d'un compte AWS.

  • Après avoir cloné un cluster, le cluster d'origine et son clone sont considérés comme étant les mêmes dans le but d'appliquer les limites sur les clones entre comptes. Vous ne pouvez pas créer des clones entre comptes à la fois du cluster original et du cluster cloné dans le même compte AWS. Le nombre total de clones entre comptes pour le cluster original et n'importe lequel de ses clones ne peut pas dépasser 15.

  • Vous ne pouvez partager un cluster de base de données Aurora avec d'autres comptes AWS que si le cluster est dans un état ACTIVE.

  • Vous ne pouvez pas renommer un cluster de base de données Aurora qui a été partagé avec d'autres comptes AWS.

  • Vous ne pouvez pas créer le clone intercompte d'un cluster chiffré avec la clé RDS par défaut.

  • Vous ne pouvez pas créer de clones non chiffrés dans un compte AWS à partir de clusters de base de données Aurora chiffrés qui ont été partagés par un autre compte AWS. Le propriétaire du cluster doit accorder l'autorisation d'accéder à la AWS KMS key du cluster source. Toutefois, vous pouvez utiliser une autre clé lorsque vous créez le clone.

Autoriser d'autres comptes AWS à cloner votre cluster

Pour autoriser d'autres comptes AWS à cloner un cluster dont vous êtes propriétaire, utilisez AWS RAM pour définir l'autorisation de partage. Cette action envoie aussi une invitation à chacun des autres comptes qui se trouve dans une autre organisation AWS.

Pour que les procédures partagent les ressources dont vous êtes propriétaire dans la console AWS RAM, consultez Partage des ressources dont vous êtes propriétaire dans le Guide de l'utilisateur AWS RAM.

Accorder à d'autres comptes AWS l'autorisation de cloner votre cluster

Si le cluster que vous partagez est chiffré, vous partagez également la AWS KMS key pour le cluster. Vous pouvez autoriser des utilisateurs ou des rôles AWS Identity and Access Management (IAM) dans un compte AWS à utiliser une clé KMS dans un autre compte.

Pour ce faire, vous ajoutez d'abord le compte externe (utilisateur racine) à la politique de clé de la clé KMS via AWS KMS. Vous n'ajoutez pas les utilisateurs ou les rôles à la politique de clé, mais seulement le compte externe qui les possède. Vous ne pouvez partager qu'une clé KMS que vous créez, pas la clé de service RDS par défaut. Pour plus d'informations sur le contrôle d'accès pour les clés KMS, consultez Authentification et contrôle d'accès pour AWS KMS.

Pour accorder l'autorisation de cloner votre cluster

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

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

  3. Choisissez le cluster de base de données que vous voulez partager pour afficher sa page Details (Détails) et choisissez l'onglet Connectivity & security (Connexion e sécurité.

  4. Dans la section Share DB cluster with other AWS accounts (Partager le cluster de bases de données avec d'autres comptes AWS), saisissez l'ID numérique du compte AWS auquel vous souhaitez accorder l'autorisation de clonage. Pour les ID de compte de la même organisation, vous pouvez commencer la saisie dans la zone, puis choisir dans le menu.

    Important

    Dans certains cas, il se peut que vous souhaitiez qu'un compte qui n'est pas dans la même organisation AWS que votre compte puisse cloner un cluster. Dans ces cas-là, pour des raisons de sécurité, la console ne signale pas qui est le propriétaire de l'ID de compte ou si le compte existe.

    Soyez attentifs lorsque vous spécifiez des numéros de compte qui ne sont pas dans la même organisation AWS que votre compte AWS. Vérifiez immédiatement que vous avez partagé avec le compte prévu.

  5. Sur la page de confirmation, vérifiez que l'ID de compte spécifié est correct. Entrez share dans la zone de confirmation pour confirmer.

    Sur la page Details (Détails), une entrée apparaît, qui montre l'ID de compte AWS spécifié sous Accounts that this DB cluster is shared with (Comptes avec lesquels ce cluster de base de données est partagé). La colone Status (État) affiche initialement l'état Pending.

  6. Contactez le propriétaire de l'autre compte AWS ou connectez-vous à ce compte si vous possédez les deux. Demandez au propriétaire de l'autre compte d'accepter l'invitation de partage et clonez le cluster de base de données, comme décrit ci-après.

Pour accorder l'autorisation de cloner votre cluster

  1. Collectez les informations pour les paramètres requis. Vous avez besoin de l'ARN de votre cluster et de l'ID numérique de l'autre compte AWS.

  2. Exécutez la commande de la CLI AWS RAM create-resource-share.

    Pour LinuxmacOS, ou Unix :

    aws ram create-resource-share --name descriptive_name \
  --region region \
  --resource-arns cluster_arn \
  --principals other_account_ids

    Dans Windows :

    aws ram create-resource-share --name descriptive_name ^
  --region region ^
  --resource-arns cluster_arn ^
  --principals other_account_ids

    Pour inclure plusieurs ID de compte pour le paramètre --principals, séparez les ID par des espaces. Pour spécifier si les ID de compte autorisés peuvent être en dehors de votre organisation AWS, incluez le paramètre --allow-external-principals ou --no-allow-external-principals pour create-resource-share.

Pour accorder l'autorisation de cloner votre cluster

  1. Collectez les informations pour les paramètres requis. Vous avez besoin de l'ARN de votre cluster et de l'ID numérique de l'autre compte AWS.

  2. Appelez l'opération AWS RAM API CreateResourceShareet spécifiez les valeurs suivantes :

    • Spécifiez l'ID de compte d'un ou de plusieurs comptes AWS en tant que paramètre principals.

    • Spécifiez l'ARN d'un ou plusieurs clusters de base de données Aurora comme paramètre resourceArns.

    • Spécifiez si les ID de compte autorisés peuvent être ou non en dehors de votre organisation AWS en incluant une valeur booléenne pour le paramètre allowExternalPrincipals.

Recréation d'un cluster qui utilise la clé RDS par défaut

Si le cluster chiffré que vous prévoyez de partager utilise la clé RDS par défaut, veillez à recréer le cluster. Pour ce faire, créez un instantané manuel de votre cluster de base de données, utilisez une AWS KMS key, puis restaurez le cluster dans un nouveau cluster. Partagez ensuite le nouveau cluster. Pour effectuer ce processus, procédez comme suit.

Pour recréer un cluster chiffré qui utilise la clé RDS par défaut

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

  2. Dans le panneau de navigation, choisissez Snapshots (Instantanés).

  3. Choisissez votre instantané.

  4. Pour Actions (Actions), choisissez Copy Snapshot (Copier un instantané), puis choisissez Enable encryption (Activer le chiffrement).

  5. Pour AWS KMS key, choisissez la nouvelle clé de chiffrement que vous souhaitez utiliser.

  6. Restaurez l'instantané copié. Pour ce faire, suivez la procédure décrite dans Restauration à partir d'un instantané de cluster de base de données. La nouvelle instance de base de données utilise votre nouvelle clé de chiffrement.

  7. (Facultatif) Supprimez l'ancien cluster de base de données si vous n'en n'avez plus besoin. Pour ce faire, suivez la procédure décrite dans Suppression d'un instantané de cluster de base de données. Auparavant, confirmez que votre nouveau cluster a toutes les données nécessaires et que votre application peut y accéder avec succès.

Vérification du partage d'un cluster vous appartenant avec d'autres comptes AWS

Vous pouvez vérifier si d'autres utilisateurs ont l'autorisation de partager un cluster. Procéder ainsi peut vous aider à comprendre si le cluster approche de la limite du nombre maximal de clones intercomptes.

Pour connaître les procédures à suivre pour partager des ressources à l'aide la console AWS RAM, consultez Partage des ressources dont vous êtes propriétaire dans le Guide de l'utilisateur AWS RAM.

Pour vérifier si un cluster qui vous appartient est partagé avec d'autres comptes AWS

  • Appelez la AWS RAMcommande de la CLI RAM list-principals en utilisant votre ID de compte comme propriétaire de la ressource et l'ARN de votre cluster comme ARN de la ressource. Vous pouvez voir tous les partages à l'aide de la commande suivante. Les résultats indiquent les comptes AWS qui sont autorisés à cloner le cluster. 

    aws ram list-principals \
    --resource-arns your_cluster_arn \
    --principals your_aws_id
Pour vérifier si un cluster qui vous appartient est partagé avec d'autres comptes AWS

  • Appelez l'opération de l'API AWS RAM ListPrincipals. Utilisez votre ID de compte comme propriétaire de la ressource et l'ARN de votre cluster comme ARN de la ressource.

Clonage d'un cluster appartenant à autre compte AWS

Pour cloner un cluster détenu par un autre compte AWS, utilisez AWS RAM pour obtenir l'autorisation de créer le clone. Après que vous avez obtenu l'autorisation requise, utilisez la procédure standard pour cloner un cluster Aurora.

Vous pouvez aussi vérifier si un cluster qui vous appartient est un clone d'un cluster détenu par un autre compte AWS.

Pour que les procédures fonctionnent avec des ressources détenues par d'autres utilisateurs dans la console AWS RAM, consultez Accès aux ressources partagées avec vous dans le Guide de l'utilisateur AWS RAM.

Affichage d'invitations à cloner des clusters appartenant à d'autres comptes AWS

Pour gérer les invitations à cloner des clusters détenus par les comptes AWS d'autres organisations AWS, utilisez la AWS CLI, la console AWS RAM ou l'API AWS RAM. Actuellement, vous ne pouvez pas exécuter cette procédure à l'aide de la console Amazon RDS.

Pour que les procédures fonctionnent avec des invitations dans la console AWS RAM, consultez Accès aux ressources partagées avec vous dans le Guide de l'utilisateur AWS RAM.

Pour afficher les invitations à cloner des clusters appartenant à d'autres comptes AWS

  1. Exécutez la commande de la CLI AWS RAM get-resource-share-invitations. 

    aws ram get-resource-share-invitations --region region_name

    Les résultats de la commande précédente affichent toutes les invitations pour cloner les clusters, y compris celles que vous avez déjà acceptées ou refusées.

  2. (Facultatif) Filtrez la liste afin que vous ne puissiez voir que les invitations qui nécessitent une action de votre part. Pour ce faire, ajoutez le paramètre --query 'resourceShareInvitations[?status==`PENDING`]'.

Pour afficher les invitations à cloner des clusters appartenant à d'autres comptes AWS

  1. Appelez l'opération de l'API AWS RAM GetResourceShareInvitations. Cette opération retourne toutes les invitations, y compris celles que vous avez déjà acceptées ou refusées.

  2. (Facultatif) Recherchez uniquement les invitations qui nécessitent une action de votre part en vérifiant le champ de retour resourceShareAssociations pour une valeur status de PENDING.

Accepter des invitations de partage de clusters détenus par d'autres comptes AWS

Vous pouvez accepter les invitations à partager des clusters détenus par d'autres comptes AWS qui se trouvent dans d'autres organisations AWS. Pour exploiter ces invitations, utilisez l'AWS CLI, les API AWS RAM et RDS, ou la console AWS RAM. Actuellement, vous ne pouvez pas exécuter cette procédure avec la console RDS.

Pour que les procédures fonctionnent avec des invitations dans la console AWS RAM, consultez Accès aux ressources partagées avec vous dans le Guide de l'utilisateur AWS RAM.

Pour accepter une invitation à partager un cluster d'un autre compte AWS

  1. Recherchez l'ARN de l'invitation en exécutant la commande de la CLI AWS RAM get-resource-share-invitations, comme illustré précédemment.

  2. Acceptez l'invitation en appelant la commande de la CLI AWS RAM accept-resource-share-invitation, comme illustré précédemment.

    Pour LinuxmacOS, ou Unix :

    aws ram accept-resource-share-invitation \
  --resource-share-invitation-arn invitation_arn \
  --region region

    Dans Windows :

    aws ram accept-resource-share-invitation ^
  --resource-share-invitation-arn invitation_arn ^
  --region region
Pour accepter des invitations à partager le cluster de quelqu'un

  1. Recherchez l'ARN de l'invitation en appelant l'opération de l'API AWS RAM GetResourceShareInvitations, comme illustré précédemment.

  2. Transmettez cet ARN en tant que resourceShareInvitationArn paramètre à l'opération AcceptResourceShareInvitationd'API RDS.

Clonage d'un cluster Aurora appartenant un autre compte AWS

Une fois l'invitation du compte AWS qui possède le cluster de bases de données acceptée, comme illustré précédemment, vous pouvez cloner le cluster.

Pour cloner un cluster Aurora appartenant un autre compte AWS

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

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

    En haut de la liste des bases de données, vous devez voir un ou plusieurs éléments avec une valeur Role (Rôle) égale à Shared from account #account_id. Pour des raisons de sécurité, vous pouvez uniquement afficher des informations limitées sur les clusters d'origine. Les propriétés que vous pouvez voir sont celles telles que le moteur de base de données et la version qui doivent être identiques dans votre cluster cloné.

  3. Choisissez le cluster que vous prévoyez de cloner.

  4. Pour Actions, choisissez Create clone (Créer un clone).

  5. Suivez la procédure dans Console pour terminer la configuration du cluster cloné.

  6. Si nécessaire, activez le chiffrement du cluster cloné. Si le cluster que vous clonez est chiffré, vous devez activer le chiffrement pour le cluster cloné. Le compte AWS avec lequel vous avez partagé le cluster doit aussi partager la clé KMS utilisée pour chiffrer le cluster. Vous pouvez utiliser la même clé KMS pour chiffrer le clone, ou utiliser votre propre clé CMK. Vous ne pouvez pas créer de clone intercompte pour un cluster chiffré avec la clé KMS par défaut.

    Le compte propriétaire de la clé de chiffrement doit accorder au compte de destination l'autorisation d'utiliser la clé à l'aide d'une politique de clé. Ce processus est similaire à la façon dont les instantanés chiffrés sont partagés, à l'aide d'une politique de clé qui accorde au compte d destination l'autorisation d'utiliser la clé.

Pour cloner un cluster Aurora appartenant un autre compte AWS

  1. Acceptez l'invitation du compte AWS qui possède le cluster de bases de données, comme illustré précédemment.

  2. Clonez le cluster en spécifiant l'ARN complet du cluster source dans le paramètre source-db-cluster-identifier de la commande restore-db-cluster-to-point-in-time de CLI RDS, comme illustré ci-après.

    Si l'ARN transmis comme source-db-cluster-identifier n'a pas été partagé, la même erreur est retourné comme si le cluster spécifié n'existait pas.

    Pour LinuxmacOS, ou Unix :

    aws rds restore-db-cluster-to-point-in-time \
  --source-db-cluster-identifier=arn:aws:rds:arn_details \
  --db-cluster-identifier=new_cluster_id \
  --restore-type=copy-on-write \
  --use-latest-restorable-time

    Dans Windows :

    aws rds restore-db-cluster-to-point-in-time ^
  --source-db-cluster-identifier=arn:aws:rds:arn_details ^
  --db-cluster-identifier=new_cluster_id ^
  --restore-type=copy-on-write ^
  --use-latest-restorable-time

  3. Si le cluster que vous clonez est chiffré, chiffrez-le en incluant un paramètre kms-key-id. La valeur kms-key-id peut être la même que celle utilisée pour chiffrer le cluster de base de données d'origine ou votre propre clé KMS. Votre compte doit avoir l'autorisation d'utiliser cette clé de chiffrement.

    Pour LinuxmacOS, ou Unix :

    aws rds restore-db-cluster-to-point-in-time \
  --source-db-cluster-identifier=arn:aws:rds:arn_details \
  --db-cluster-identifier=new_cluster_id \
  --restore-type=copy-on-write \
  --use-latest-restorable-time \
  --kms-key-id=arn:aws:kms:arn_details

    Dans Windows :

    aws rds restore-db-cluster-to-point-in-time ^
  --source-db-cluster-identifier=arn:aws:rds:arn_details ^
  --db-cluster-identifier=new_cluster_id ^
  --restore-type=copy-on-write ^
  --use-latest-restorable-time ^
  --kms-key-id=arn:aws:kms:arn_details

    Le compte propriétaire de la clé de chiffrement doit accorder au compte de destination l'autorisation d'utiliser la clé à l'aide d'une politique de clé. Ce processus est similaire à la façon dont les instantanés chiffrés sont partagés, à l'aide d'une politique de clé qui accorde au compte d destination l'autorisation d'utiliser la clé. Un exemple de politique de clé suit. 

    {
  "Id": "key-policy-1",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Allow use of the key",
      "Effect": "Allow",
      "Principal": {"AWS": [
        "arn:aws:iam::account_id:user/KeyUser",
        "arn:aws:iam::account_id:root"
      ]},
      "Action": [
        "kms:CreateGrant",
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:ReEncrypt*",
        "kms:GenerateDataKey*",
        "kms:DescribeKey"
      ],
      "Resource": "*"
    },
    {
      "Sid": "Allow attachment of persistent resources",
      "Effect": "Allow",
      "Principal": {"AWS": [
        "arn:aws:iam::account_id:user/KeyUser",
        "arn:aws:iam::account_id:root"
      ]},
      "Action": [
        "kms:CreateGrant",
        "kms:ListGrants",
        "kms:RevokeGrant"
      ],
      "Resource": "*",
      "Condition": {"Bool": {"kms:GrantIsForAWSResource": true}}
    }
  ]
}
Note

La commande restore-db-cluster-to- point-in-time AWS CLI 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. Pour créer des instances de base de données pour le cluster de base de données restauré, appelez la create-db-instancecommande. Spécifiez l'identificateur du cluster de base de données restauré dans --db-cluster-identifier.

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.

Pour cloner un cluster Aurora appartenant un autre compte AWS

  1. Acceptez l'invitation du compte AWS qui possède le cluster de bases de données, comme illustré précédemment.

  2. Clonez le cluster en spécifiant l'ARN complet du cluster source dans le paramètre SourceDBClusterIdentifier de l'opération RestoreDBClusterToPointInTime de l'API RDS.

    Si l'ARN transmis comme SourceDBClusterIdentifier n'a pas été partagé, la même erreur est retournée comme si le cluster spécifié n'existait pas.

  3. Si le cluster que vous clonez est chiffré, incluez un paramètre KmsKeyId pour chiffrer le cluster cloné. La valeur kms-key-id peut être la même que celle utilisée pour chiffrer le cluster de base de données d'origine ou votre propre clé KMS. Votre compte doit avoir l'autorisation d'utiliser cette clé de chiffrement.

    Lors du clonage d'un volume, le compte de destination doit avoir l'autorisation d'utiliser la clé de chiffrement utilisée pour chiffrer le cluster source. Aurora chiffre le nouveau cluster cloné avec la clé de chiffrement spécifiée dans KmsKeyId.

    Le compte propriétaire de la clé de chiffrement doit accorder au compte de destination l'autorisation d'utiliser la clé à l'aide d'une politique de clé. Ce processus est similaire à la façon dont les instantanés chiffrés sont partagés, à l'aide d'une politique de clé qui accorde au compte d destination l'autorisation d'utiliser la clé. Un exemple de politique de clé suit. 

    {
  "Id": "key-policy-1",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Allow use of the key",
      "Effect": "Allow",
      "Principal": {"AWS": [
        "arn:aws:iam::account_id:user/KeyUser",
        "arn:aws:iam::account_id:root"
      ]},
      "Action": [
        "kms:CreateGrant",
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:ReEncrypt*",
        "kms:GenerateDataKey*",
        "kms:DescribeKey"
      ],
      "Resource": "*"
    },
    {
      "Sid": "Allow attachment of persistent resources",
      "Effect": "Allow",
      "Principal": {"AWS": [
        "arn:aws:iam::account_id:user/KeyUser",
        "arn:aws:iam::account_id:root"
      ]},
      "Action": [
        "kms:CreateGrant",
        "kms:ListGrants",
        "kms:RevokeGrant"
      ],
      "Resource": "*",
      "Condition": {"Bool": {"kms:GrantIsForAWSResource": true}}
    }
  ]
}
Note

L'opération d'API ClusterToPointInTime RDS RestoreDB 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. Pour créer des instances de base de données pour le cluster de base de données restauré, appelez l'opération de l'API RDS CreateDBInstance. Spécifiez l'identificateur du cluster de base de données restauré dans DBClusterIdentifier. Vous pouvez créer des instances de base de données une fois seulement l'opération RestoreDBClusterToPointInTime terminée et le cluster de bases de données disponible.

Vérification pour savoir si un cluster de base de données est un clone intercompte

L'objet DBClusters identifie si chaque cluster est un clone intercompte. Vous pouvez voir les clusters que vous avez l'autorisation de cloner en utilisant l'option include-shared lorsque vous exécutez la commande describe-db-clusters de CLI RDS. Cependant, vous ne pouvez pas voir la plupart des détails de configuration de tels clusters.

Pour vérifier si un cluster de base de données est un clone entre comptes

  • Appelez la commande de CLI RDS describe-db-clusters.

    L'exemple suivant montre comment les clusters de base de données de clone intercompte actuel ou potentiel apparaissent dans la sortie describe-db-clusters. Pour les clusters existants détenus par votre compte AWS, le champ CrossAccountClone indique si le cluster est un clone d'un cluster de bases de données détenu par un autre compte AWS.

    Dans certains cas, une entrée peut avoir un numéro de compte AWS différent de celui du vôtre dans le champ DBClusterArn. Dans ce cas, cette entrée représente un cluster détenu par un autre compte AWS et que vous pouvez cloner. De telles entrées ont quelques champs autres que DBClusterArn. Lors de la création du cluster cloné, spécifiez les mêmes valeurs StorageEncrypted, Engine et EngineVersion que dans le cluster d'origine. 

    $aws rds describe-db-clusters --include-shared --region us-east-1
{
  "DBClusters": [
      {
          "EarliestRestorableTime": "2023-02-01T21:17:54.106Z",
          "Engine": "aurora-mysql",
          "EngineVersion": "8.0.mysql_aurora.3.02.0",
          "CrossAccountClone": false,
...
      },
      {
          "EarliestRestorableTime": "2023-02-09T16:01:07.398Z",
          "Engine": "aurora-mysql",
          "EngineVersion": "8.0.mysql_aurora.3.02.0",
          "CrossAccountClone": true,
...
      },
      {
          "StorageEncrypted": false,
          "DBClusterArn": "arn:aws:rds:us-east-1:12345678:cluster:cluster-abcdefgh",
          "Engine": "aurora-mysql",
          "EngineVersion": "8.0.mysql_aurora.3.02.0
  ]
}
Pour vérifier si un cluster de base de données est un clone entre comptes

  • Appelez l'opération d'API RDS DescribeDBClusters.

    Pour les clusters existants détenus par votre compte AWS, le champ CrossAccountClone indique si le cluster est un clone d'un cluster de bases de données détenu par un autre compte AWS. Les entrées avec un autre numéro de compte AWS dans le champ DBClusterArn représentent les clusters que vous pouvez cloner et qui sont détenus par d'autres comptes AWS. Ces entrées ont quelques champs autres que DBClusterArn. Lors de la création du cluster cloné, spécifiez les mêmes valeurs StorageEncrypted, Engine et EngineVersion que dans le cluster d'origine.

    L'exemple suivant montre une valeur de retour qui illustre les clusters clonés réels et potentiels. 

    {
  "DBClusters": [
      {
          "EarliestRestorableTime": "2023-02-01T21:17:54.106Z",
          "Engine": "aurora-mysql",
          "EngineVersion": "8.0.mysql_aurora.3.02.0",
          "CrossAccountClone": false,
...
      },
      {
          "EarliestRestorableTime": "2023-02-09T16:01:07.398Z",
          "Engine": "aurora-mysql",
          "EngineVersion": "8.0.mysql_aurora.3.02.0",
          "CrossAccountClone": true,
...
      },
      {
          "StorageEncrypted": false,
          "DBClusterArn": "arn:aws:rds:us-east-1:12345678:cluster:cluster-abcdefgh",
          "Engine": "aurora-mysql",
          "EngineVersion": "8.0.mysql_aurora.3.02.0"
      }
  ]
}