Restauration d’un cluster à partir d’un instantané - Amazon Redshift

Amazon Redshift ne prendra plus en charge la création de nouvelles fonctions Python définies par l’utilisateur à compter du 1er novembre 2025. Si vous souhaitez utiliser des fonctions Python définies par l’utilisateur, créez-les avant cette date. Les fonctions Python définies par l’utilisateur existantes continueront de fonctionner normalement. Pour plus d’informations, consultez le billet de blog .

Restauration d’un cluster à partir d’un instantané

Un instantané contient des données issues de n’importe quelle base de données exécutée sur votre cluster. Il contient également des informations sur votre cluster, y compris le nombre de nœuds, le type de nœud et le nom de l’administrateur. Si vous restaurez votre cluster à partir d’un instantané, Amazon Redshift utilise les informations du cluster pour en créer un nouveau. Ensuite, il restaure toutes les bases de données à partir des données de l’instantané.

Note

Les tables sans sauvegarde ne sont pas prises en charge pour les clusters RA3 alloués et les groupes de travail Amazon Redshift sans serveur. Une table marquée sans sauvegarde dans un cluster RA3 ou un groupe de travail sans serveur est traitée comme une table permanente qui sera toujours sauvegardée lors de la prise d’un instantané, et toujours restaurée lors de la restauration à partir d’un instantané.

Pour le nouveau cluster créé à partir de l’instantané d’origine, vous pouvez choisir la configuration, par exemple le type de nœud et le nombre de nœuds. Le cluster est restauré dans la même région AWS et la même zone de disponibilité, sauf si vous spécifiez une autre zone de disponibilité dans votre demande. Lorsque vous restaurez un cluster à partir d’un instantané, vous pouvez, si vous le souhaitez, choisir une piste de maintenance compatible pour le nouveau cluster.

Note

Lorsque vous restaurez un instantané dans un cluster avec une configuration différente, l’instantané doit être issu d’un cluster dont la version est 1.0.10013 ou ultérieure.

Lorsqu’une restauration est en cours, les événements sont généralement émis dans l’ordre suivant :

  1. RESTORE_START – REDSHIFT-EVENT-2008 envoyé lorsque le processus de restauration commence.

  2. RESTORE_SUCESS – REDSHIFT-EVENT-3003 envoyé lorsque le nouveau cluster a été créé.

    Le cluster est disponible pour les requêtes.

  3. DATA_TRANSFER_COMPLETED – REDSHIFT-EVENT-3537 envoyé lorsque le transfert de données est terminé.

Note

Les clusters RA3 émettent uniquement des événements RESTORE_START et RESTORE_SUCESS. Il n’y a pas de transfert de données explicite à effectuer après la réussite d’un RESTORE, car les types de nœuds RA3 stockent les données dans le stockage géré par Amazon Redshift. Avec les nœuds RA3, les données sont transférées en continu entre les nœuds RA3 et le stockage géré par Amazon Redshift dans le cadre du traitement normal des requêtes. Les nœuds RA3 mettent en cache les données sensibles localement et conservent automatiquement les blocs moins fréquemment interrogés dans le stockage géré par Amazon Redshift.

Vous pouvez surveiller la progression d’une restauration en appelant l’action d’API DescribeClusters ou en affichant les détails du cluster dans AWS Management Console. Pour une restauration en cours, sont affichées les informations telles que la taille des données de l’instantané, la vitesse de transfert, le temps passé et la durée restante estimée. Pour une description de ces métriques, consultez RestoreStatus.

Vous ne pouvez pas utiliser un instantané pour restaurer l’état antérieur d’un cluster actif.

Note

Lorsque vous restaurez un instantané sur un nouveau cluster, les groupe de sécurité et groupe de paramètres par défaut sont utilisés, sauf si vous spécifiez des valeurs différentes.

Vous pouvez choisir de restaurer un instantané dans un cluster avec une autre configuration pour les raisons suivantes :

  • Lorsqu’un cluster est composé de types de nœud plus petits et que vous souhaitez les regrouper dans un type de nœud plus important avec moins de nœuds.

  • Lorsque vous avez surveillé votre charge de travail et déterminé la nécessité de passer à un type de nœud avec davantage d’UC et de stockage.

  • Lorsque vous souhaitez mesurer les performances des charges de travail de test avec différents types de nœud.

La restauration comporte les contraintes suivantes :

  • La nouvelle configuration de nœud doit inclure suffisamment de stockage pour les données existantes. Même lorsque vous ajoutez des nœuds, votre nouvelle configuration peut manquer de stockage en raison de la manière dont les données sont redistribuées.

  • L’opération de restauration vérifie si l’instantané a été créé sur une version de cluster compatible avec la version du nouveau cluster. Si le nouveau cluster a un niveau de version trop précoce, alors l’opération de restauration échoue et renvoie d’autres informations dans un message d’erreur.

  • Les configurations possibles (nombre de nœuds et type de nœud) par rapport auxquelles vous pouvez effectuer la restauration sont déterminées par le nombre de nœuds dans le cluster d’origine et le type de nœud cible du nouveau cluster. Pour déterminer les configurations possibles disponibles, vous pouvez utiliser la console Amazon Redshift ou la commande describe-node-configuration-options de l’AWS CLI avec action-type restore-cluster. Pour plus d’informations sur la restauration avec la console Amazon Redshift, consultez Restauration d’un cluster à partir d’un instantané.

Les étapes suivantes prennent un cluster avec plusieurs nœuds et l’intègre à un type de nœud plus important avec un nombre de nœuds plus petit à l’aide de l’AWS CLI. Pour cet exemple, nous allons commencer par un cluster source composé de 24 nœuds . Dans le cas présent, supposons que nous ayons créé un instantané de ce cluster et que nous souhaitions le restaurer dans un type de nœud plus important.

  1. Exécutez la commande suivante pour obtenir les détails de notre cluster composé de 24 nœuds. 

    aws redshift describe-clusters --region eu-west-1 --cluster-identifier mycluster-123456789012

  2. Exécutez la commande suivante pour obtenir les détails de l’instantané. 

    aws redshift describe-cluster-snapshots --region eu-west-1 --snapshot-identifier mycluster-snapshot

  3. Exécutez la commande suivante afin de décrire les options disponibles pour cet instantané. 

    aws redshift describe-node-configuration-options --snapshot-identifier mycluster-snapshot --region eu-west-1 --action-type restore-cluster

    Cette commande renvoie une liste d’options avec les types de nœud recommandés, le nombre de nœuds et l’utilisation du disque pour chaque option. Dans le cadre de cet exemple, la commande précédente répertorie les configurations de nœud possibles suivantes. Nous choisissons de restaurer dans un cluster composé de trois nœuds.

    {
    "NodeConfigurationOptionList": [
        {
            "EstimatedDiskUtilizationPercent": 65.26134808858235,
            "NodeType": "dc2.large",
            "NumberOfNodes": 24
        },
        {
            "EstimatedDiskUtilizationPercent": 32.630674044291176,
            "NodeType": "dc2.large",
            "NumberOfNodes": 48
        },
        {
            "EstimatedDiskUtilizationPercent": 65.26134808858235,
            "NodeType": "dc2.8xlarge",
            "NumberOfNodes": 3
        },
        {
            "EstimatedDiskUtilizationPercent": 48.94601106643677,
            "NodeType": "dc2.8xlarge",
            "NumberOfNodes": 4
        },
        {
            "EstimatedDiskUtilizationPercent": 39.156808853149414,
            "NodeType": "dc2.8xlarge",
            "NumberOfNodes": 5
        },
        {
            "EstimatedDiskUtilizationPercent": 32.630674044291176,
            "NodeType": "dc2.8xlarge",
            "NumberOfNodes": 6
        }
    ]
}

  4. Exécutez la commande suivante pour restaurer l’instantané dans la configuration de cluster que nous avons choisie. Une fois ce cluster restauré, nous avons le même contenu que le cluster source, mais les données ont été regroupées dans trois nœuds dc2.8xlarge. 

    aws redshift restore-from-cluster-snapshot --region eu-west-1 --snapshot-identifier mycluster-snapshot --cluster-identifier mycluster-123456789012-x --node-type dc2.8xlarge --number-of-nodes 3

Si vous avez des nœuds réservés, par exemple des nœuds réservés DC2, vous pouvez effectuer une mise à niveau vers des nœuds réservés RA3. Vous pouvez le faire lorsque vous effectuez une restauration à partir d’un instantané ou lorsque vous effectuez un redimensionnement élastique. Vous pouvez utiliser la console pour vous guider dans ce processus. Pour plus d’informations sur la mise à niveau vers des nœuds RA3, consultez Mise à niveau vers des types de nœuds RA3.

Pour restaurer le cluster à partir d’un instantané sur la console

  1. Connectez-vous à la AWS Management Console et ouvrez la console Amazon Redshift à l’adresse https://console.aws.amazon.com/redshiftv2/.

  2. Dans le menu de navigation, choisissez Clusters, Instantanés, puis choisissez l’instantané à restaurer.

  3. Choisissez Restaurer à partir d’un instantané pour afficher la Configuration du cluster et les Détails du cluster pour le nouveau cluster à créer à l’aide des informations de l’instantané.

  4. Mettez à niveau les propriétés du nouveau cluster, puis choisissez Restaurer un cluster à partir d’un instantané.

Après avoir restauré l’instantané de votre cluster, l’entrepôt de données restauré est chiffré avec la même clé AWS KMS personnalisée qu’il utilisait au moment de la prise de l’instantané. Si l’instantané ne possédait pas de clé KMS personnalisée, la logique de chiffrement des sauvegardes d’Amazon Redshift dépend des facteurs suivants :

  • Type d’entrepôt des données Amazon Redshift dans lequel vous restaurez l’instantané.

  • Type de chiffrement du cluster au moment de la prise de l’instantané.

Pour savoir comment votre entrepôt de données est chiffré une fois que vous l’avez restauré à partir de votre instantané de cluster, consultez la table suivante :

Type de destination Type de chiffrement de l’instantané Type de chiffrement de destination
Cluster alloué Chiffré avec une Clé gérée par AWS Chiffré avec une Clé gérée par AWS
Cluster alloué Chiffré avec une Clé détenue par AWS Chiffré avec une Clé détenue par AWS
Espace de noms sans serveur Chiffré avec une Clé gérée par AWS Chiffré avec une Clé détenue par AWS
Espace de noms sans serveur Chiffré avec une Clé détenue par AWS Chiffré avec une Clé détenue par AWS

Si AWS Secrets Manager gérait le mot de passe d’administrateur de votre cluster au moment de la prise de l’instantané, vous devez continuer à utiliser AWS Secrets Manager pour gérer le mot de passe d’administrateur. Vous pouvez désactiver l’utilisation d’un secret après avoir restauré le cluster en mettant à jour les informations d’identification d’administrateur du cluster sur la page de détails du cluster.

Si vous avez des nœuds réservés, vous pouvez effectuer une mise à niveau vers des nœuds réservés RA3. Vous pouvez le faire lorsque vous effectuez une restauration à partir d’un instantané ou lorsque vous effectuez un redimensionnement élastique. Vous pouvez utiliser la console pour vous guider dans ce processus. Pour plus d’informations sur la mise à niveau vers des nœuds RA3, consultez Mise à niveau vers des types de nœuds RA3.