Amazon Redshift ne prendra plus en charge la création de nouveaux Python à UDFs partir du patch 198. UDFs Le Python existant continuera de fonctionner jusqu'au 30 juin 2026. Pour plus d’informations, consultez le [ billet de blog ](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/).
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.
# Opérations de cluster
Après avoir créé un cluster, vous pouvez effectuer des opérations de cluster pour optimiser les performances, contrôler les coûts et garantir une haute disponibilité. Les opérations de cluster vous permettent de redimensionner, de suspendre, de reprendre ou même de recréer des clusters en fonction de l’évolution de vos besoins en matière d’entreposage de données.
Les cas d’utilisation courants incluent la mise à l’échelle de la capacité de calcul pour les pics de charge de travail, la suspension des clusters pendant les périodes d’inactivité pour réduire les coûts et la recréation de clusters avec différentes configurations ou dans différentes zones de disponibilité pour la reprise après sinistre. Les sections suivantes décrivent en détail l’exécution de diverses opérations de cluster pour gérer efficacement votre environnement Amazon Redshift.
# Création d’un cluster
Avec Amazon Redshift, vous pouvez créer un cluster alloué pour lancer un nouvel entrepôt de données. Un cluster alloué est un ensemble de ressources informatiques appelées nœuds, qui sont organisées en un seul système MPP (Massively Parallel Processing).
Avant de créer un cluster, listez [Clusters Amazon Redshift provisionnés](working-with-clusters.md) et [Clusters et nœuds dans Amazon Redshift](working-with-clusters.md#rs-about-clusters-and-nodes).
**Pour créer un cluster**
1. Connectez-vous à la console Amazon Redshift AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/)
1. Dans le menu de navigation, choisissez **Clusters**. Les clusters associés à votre compte dans la AWS région actuelle sont répertoriés. Un sous-ensemble des propriétés de chaque cluster s’affiche dans les colonnes de la liste.
1. Choisissez **Créer un cluster** pour créer un cluster.
1. Suivez les instructions sur la page de la console pour entrer les propriétés dans **Configuration du cluster**.
L'étape suivante décrit une console Amazon Redshift qui s'exécute dans un environnement qui prend en charge les Région AWS types de RA3 nœuds. Pour obtenir la liste des types de RA3 nœuds Régions AWS compatibles, consultez la section [Présentation des types de RA3 nœuds](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html#rs-ra3-node-types) dans le guide de *gestion Amazon Redshift*.
Si vous ne savez pas quelle taille donner à votre cluster, choisissez **Help me choose (Aidez-moi à choisir)**. Cette opération lance un calculateur de dimensionnement qui vous pose des questions sur la taille et les caractéristiques d’interrogation des données que vous prévoyez de stocker dans votre entrepôt des données. Si vous connaissez la taille requise de votre cluster (c’est-à-dire le type et le nombre de nœuds), choisissez **I’ll choose (Je vais choisir)**. Choisissez ensuite le **Node type (Type de nœud)** et le nombre de **Nodes (Nœuds)** pour dimensionner votre cluster pour la preuve de concept.
**Note**
Si votre organisation est éligible et que votre cluster est créé dans une Région AWS où Amazon Redshift sans serveur n’est pas disponible, vous pourrez peut-être créer un cluster dans le cadre du programme d’essai gratuit d’Amazon Redshift. Choisissez **Production** ou **Essai gratuit** pour répondre à la question **Quelle est l’utilisation prévue de ce cluster ?** Lorsque vous choisissez **Essai gratuit**, vous créez une configuration avec le type de nœud dc2.large. Pour plus d’informations sur le choix d’un essai gratuit, consultez [Essai gratuit d’Amazon Redshift](https://aws.amazon.com/redshift/free-trial/). Pour obtenir la liste des Régions AWS endroits où Amazon Redshift Serverless est disponible, consultez les points de terminaison répertoriés pour l'API [Redshift](https://docs.aws.amazon.com/general/latest/gr/redshift-service.html) Serverless dans le. *Référence générale d'Amazon Web Services*
1. Dans la section **Configuration de la base de données**, spécifiez une valeur pour **Nom de l’utilisateur administrateur**. Pour **Mot de passe administrateur**, choisissez l’une des options suivantes :
+ **Générez un mot de passe** : utilisez un mot de passe généré par Amazon Redshift.
+ **Ajouter manuellement un mot de passe d’administrateur** : utilisez votre propre mot de passe.
+ **Gérez les informations d'identification d'administrateur dans AWS Secrets Manager** : Amazon Redshift les utilise AWS Secrets Manager pour générer et gérer votre mot de passe d'administrateur. L'utilisation AWS Secrets Manager pour générer et gérer le secret de votre mot de passe entraîne des frais. Pour plus d'informations sur AWS Secrets Manager les tarifs, consultez la section [AWS Secrets Manager Tarification](https://aws.amazon.com/secrets-manager/pricing/).
1. (Facultatif) Suivez les instructions sur la page de la console pour entrer les propriétés dans **Autorisations du cluster**. Fournissez des autorisations de cluster si votre cluster a besoin d'accéder à d'autres AWS services pour vous, par exemple pour charger des données depuis Amazon S3.
1. Choisissez **Créer un cluster** pour créer le cluster. Le cluster peut prendre plusieurs minutes pour être prêt à être utilisé.
## Configurations supplémentaires
Lorsque vous créez un cluster, vous pouvez spécifier des propriétés supplémentaires afin de le personnaliser. Vous trouverez plus de détails sur certaines de ces propriétés dans la liste suivante.
**Type d’adresse IP**
Choisissez le type d’adresse IP de votre cluster. Vous pouvez choisir de faire en sorte que vos ressources communiquent uniquement via le protocole d' IPv4 adressage ou de choisir le mode double pile, qui permet à vos ressources de communiquer via les deux protocoles IPv4 et IPv6. Cette fonctionnalité n'est disponible que dans les AWS GovCloud régions (USA Est) et AWS GovCloud (USA Ouest). Pour plus d'informations sur AWS les régions, voir [Régions et zones de disponibilité](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/).
**Cloud privé virtuel (VPC)**
Choisissez un VPC qui possède un groupe de sous-réseaux de cluster. Une fois que le cluster a été créé, le groupe de sous-réseaux de cluster ne peut pas être modifié.
**Groupes de paramètres**
Choisissez un groupe de paramètres de cluster à associer au cluster. Si vous n’en choisissez pas, le cluster utilise le groupe de paramètres par défaut.
**Chiffrement**
Choisissez si vous voulez chiffrer toutes les données au sein du cluster et ses instantanés. Si vous laissez le paramètre par défaut, **Aucun**, le chiffrement n’est pas activé. Si vous souhaitez activer le chiffrement, choisissez d'utiliser AWS Key Management Service (AWS KMS) ou un module de sécurité matériel (HSM), puis configurez les paramètres associés. Pour plus d’informations sur le chiffrement dans Amazon Redshift, consultez [Chiffrement de base de données Amazon Redshift](working-with-db-encryption.md).
+ **KMS**
Choisissez **Utiliser AWS Key Management Service (AWS KMS)** si vous souhaitez activer le chiffrement et l'utiliser AWS KMS pour gérer votre clé de chiffrement. Sélectionnez également la clé à utiliser. Vous pouvez sélectionner une clé par défaut, une clé issue du compte actuel ou une clé issue d’un autre compte.
**Note**
Si vous souhaitez utiliser une clé d'un autre AWS compte, entrez le nom de ressource Amazon (ARN) correspondant à la clé à utiliser. Vous devez avoir l’autorisation d’utiliser la clé. Pour plus d'informations sur l'accès aux clés AWS KMS, consultez la section [Contrôle de l'accès à vos clés](https://docs.aws.amazon.com/kms/latest/developerguide/control-access.html) dans le *Guide du AWS Key Management Service développeur*.
Pour plus d'informations sur l'utilisation des clés de AWS KMS chiffrement dans Amazon Redshift, consultez. [Chiffrement en utilisant AWS KMS](working-with-db-encryption.md#working-with-aws-kms)
+ **HSM**
Choisissez **HSM** si vous voulez activer le chiffrement et utiliser un module de sécurité matérielle (HSM) pour gérer votre clé de chiffrement.
Si vous choisissez **HSM**, choisissez les valeurs de **Connexion HSM** et **Certificat de client HSM**. Ces valeurs sont requises pour Amazon Redshift et le module HSM de façon à former une connexion approuvée au travers de laquelle la clé de cluster peut être transmise. La connexion et le certificat de client HSM doivent être configurés dans Amazon Redshift avant que vous ne lanciez un cluster. Pour plus d’informations sur la configuration des connexions et des certificats de clients HSM, consultez [Chiffrement à l’aide de modules de sécurité matérielle](working-with-db-encryption.md#working-with-HSM).
**Suivi de maintenance**
Vous pouvez choisir si la version de cluster utilisée doit être **Actuelle**, **Finale** ou parfois **Préliminaire**.
**Surveillance**
Vous pouvez choisir de créer ou non des CloudWatch alarmes.
**Configurer un instantané inter-région**
Vous pouvez choisir d’activer des instantanés inter-régions.
**Période de conservation de l’instantané automatique**
Vous pouvez choisir le nombre de jours de conservation de ces instantanés dans un délai maximum de 35 jours. Si le type de nœud est DC2, vous pouvez choisir zéro (0) jour pour ne pas créer de snapshots automatisés.
**Période de conservation de l’instantané manuel**
Vous pouvez choisir le nombre de jours ou l’option `Indefinitely` pour conserver ces instantanés.
**Ressources de calcul supplémentaires pour des optimisations automatiques**
Vous pouvez choisir d'allouer des ressources de calcul supplémentaires pour effectuer des optimisations automatiques, même pendant les périodes d'utilisation intensive. Pour plus d'informations, consultez la section [Allocation de ressources de calcul supplémentaires pour l'optimisation automatique des bases](https://docs.aws.amazon.com/redshift/latest/dg/t_extra-compute-autonomics.html) de données dans le manuel *Amazon Redshift Database* Developer Guide.
# Création d’une alarme d’espace disque
Vous pouvez surveiller l’utilisation de l’espace disque et définir des alarmes pour être averti lorsque l’espace disque dépasse un seuil spécifié pour un cluster. La création d’une alarme d’utilisation de l’espace disque vous permet de gérer de manière proactive la capacité de stockage et d’éviter les problèmes liés à un espace disque insuffisant, tels que les échecs de requêtes ou les erreurs d’ingestion de données. La procédure suivante vous guide au cours du processus de création d’une alarme d’utilisation de l’espace disque.
**Pour créer une alarme relative à l’utilisation de l’espace disque pour un cluster**
1. Connectez-vous à la console Amazon Redshift AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/)
1. Dans le menu de navigation, choisissez **Alarmes**.
1. Pour **Actions**, choisissez **Créer une alarme**. La page **Créer une alarme** apparaît.
1. Suivez les instructions indiquées sur la page.
1. Sélectionnez **Créer une alerte**.
# Affichage d’un cluster
L’affichage d’un cluster vous permet de surveiller et de gérer la configuration, l’état et les indicateurs de performance de votre cluster. En consultant les détails du cluster, vous pouvez obtenir des informations sur l’utilisation des ressources, les temps d’exécution des requêtes et l’état du système. La procédure suivante illustre comment accéder aux informations de cluster.
**Pour afficher un cluster**
1. Connectez-vous à la console Amazon Redshift AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/)
1. Dans le menu de navigation, choisissez **Clusters**. Les clusters associés à votre compte dans la AWS région actuelle sont répertoriés. Un sous-ensemble des propriétés de chaque cluster s’affiche dans les colonnes de la liste. Si vous n’avez pas de clusters, choisissez **Créer un cluster** pour en créer un.
1. Choisissez le nom du cluster dans la liste pour afficher plus de détails sur un cluster.
# Modification d’un cluster
Lorsque vous modifiez un cluster, les modifications apportées aux options suivantes sont appliquées immédiatement :
+ **Groupes de sécurité VPC**
+ **Accessible publiquement**
+ **Mot de passe d’utilisateur administrateur**
+ **Connexion HSM**
+ **Certificat de client HSM**
+ **Détails de maintenance**
+ **Snapshot preferences (Préférences d’instantané)**
Les modifications apportées aux options suivantes ne prennent effet qu’après le redémarrage du cluster :
+ **Identifiant du cluster**
Amazon Redshift redémarre le cluster automatiquement lorsque vous modifiez le champ **Cluster identifier (Identifiant du cluster)**.
+ **Routage VPC amélioré**
Amazon Redshift redémarre le cluster automatiquement lorsque vous modifiez le champ **Enhanced VPC routing (Routage VPC amélioré)**.
+ **Groupe de paramètres du cluster**
+ **Type d’adresse IP**
Cette fonctionnalité n'est disponible que dans les AWS GovCloud régions (USA Est) et AWS GovCloud (USA Ouest). Pour plus d'informations sur AWS les régions, voir [Régions et zones de disponibilité](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/).
Si vous diminuez la période de conservation des instantanés automatiques, ceux existants dont les paramètres tombent en dehors de la nouvelle période de conservation sont supprimés. Pour plus d’informations, consultez [Instantanés et sauvegardes Amazon Redshift](working-with-snapshots.md).
Pour obtenir plus d’informations sur les propriétés des clusters, consultez [Configurations supplémentaires](create-cluster.md#cluster-create-console-configuration).
**Pour modifier un cluster**
1. Connectez-vous à la console Amazon Redshift AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/)
1. Dans le menu de navigation, choisissez **Clusters**.
1. Choisissez le cluster à modifier.
1. Choisissez **Modifier**. La page **Edit cluster (Modifier le cluster)** s’affiche.
1. Mettez à jour les propriétés du cluster. Vous pouvez modifier notamment les propriétés suivantes :
+ Identifiant du cluster
+ Conservation des instantanés
+ Relocalisation du cluster
Pour modifier les paramètres de **Réseau et sécurité**, **Maintenance** et **Configurations de base de données**, la console fournit des liens vers l’onglet de détails de cluster approprié.
1. Sélectionnez **Enregistrer les modifications**.
# Redimensionnement d’un cluster
Au fur et à mesure que vos performances et capacités d’entrepôt des données changent, vous pouvez redimensionner votre cluster pour tirer le meilleur parti des options de calcul et de stockage d’Amazon Redshift.
Lorsque vous redimensionnez un cluster, vous spécifiez un certain nombre de nœuds ou un type de nœud différent de la configuration actuelle du cluster. Pendant le redimensionnement du cluster, vous ne pouvez exécuter aucune écriture ni aucune read/write requête sur le cluster ; vous ne pouvez exécuter que des requêtes de lecture.
Pour plus d’informations sur le redimensionnement des clusters, y compris à travers le processus de redimensionnement des clusters à l’aide de différentes approches, consultez [Redimensionnement d’un cluster](#resizing-cluster).
**Pour redimensionner un cluster**
1. Connectez-vous à la console Amazon Redshift AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/)
1. Dans le menu de navigation, choisissez **Clusters**.
1. Choisissez le cluster à redimensionner.
1. Pour **Actions**, choisissez **Redimensionner**. La page **Redimensionner le cluster** s’affiche.
1. Suivez les instructions indiquées sur la page. Vous pouvez redimensionner le cluster maintenant, une fois à un moment donné, ou augmenter et diminuer sa taille selon un programme.
1. Selon vos choix, choisissez **Resize now (Redimensionner maintenant)** ou **Schedule resize (Planifier le redimensionnement)**.
Si vous avez des nœuds réservés, vous pouvez passer à des nœuds RA3 réservés. Vous pouvez le faire lorsque vous utilisez la console pour effectuer une restauration à partir d’un instantané ou pour effectuer un redimensionnement Elastic. Vous pouvez utiliser la console pour vous guider dans ce processus. Pour plus d'informations sur la mise à niveau vers RA3 des nœuds, consultez la section [Mise à niveau vers des types de RA3 nœuds](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html#rs-upgrading-to-ra3).
Lorsque vous effectuez une opération de redimensionnement pour passer d'un type de nœud DC2 .large à un type de nœud RA3 .large, Amazon Redshift convertit automatiquement les clés de tri entrelacées en clés de tri composées. Cette conversion permet d’accéder à la fonctionnalité de mise à l’échelle de la simultanéité, qui ne prend pas en charge les requêtes sur les tables avec des clés de tri entrelacées. Bien que cette conversion automatique garantisse la compatibilité avec les RA3 fonctionnalités, elle peut avoir un impact sur les modèles de performances de vos requêtes existants.
Si vous souhaitez conserver les clés de tri entrelacées après la mise à niveau vers les RA3 nœuds, vous pouvez recréer vos tables avec la configuration de clé de tri souhaitée une fois l'opération de redimensionnement terminée. Cependant, le choix de cette option signifie que vous ne pourrez pas utiliser la mise à l’échelle de la simultanéité pour ces tables.
Une opération de redimensionnement se décline en deux types :
+ **Elastic resize** (Redimensionnement élastique) : vous pouvez ajouter ou supprimer des nœuds de votre cluster. Vous pouvez également modifier le type de nœud, par exemple de DC2 nœuds en RA3 nœuds. Un redimensionnement élastique s’effectue généralement rapidement, en dix minutes en moyenne. C’est pourquoi nous le recommandons en tant que première option. Lorsque vous effectuez un redimensionnement élastique, cela redistribue les tranches de données. Les tranches de données sont des partitions auxquelles de la mémoire et de l’espace disque sont alloués dans chaque nœud. Le redimensionnement élastique est approprié pour :
+ *Add or reduce nodes in an existing cluster, but you don’t change the node type* (Ajouter ou réduire des nœuds dans un cluster existant, mais sans modifier le type de nœud) : ceci est généralement appelé un redimensionnement *sur place*. Lorsque vous effectuez ce type de redimensionnement, certaines requêtes en cours d’exécution se terminent, mais d’autres peuvent être supprimées dans le cadre de l’opération.
+ *Change the node type for a cluster* (Modifier le type de nœud d’un cluster) : lorsque vous modifiez le type de nœud, un instantané est créé et les données sont redistribuées à partir du cluster source vers un cluster composé du nouveau type de nœud. Au terme de cette opération, les requêtes en cours d’exécution sont supprimées. Tout comme le redimensionnement *sur place*, cette opération se termine rapidement.
+ **Classic resize** (Redimensionnement classique) : vous pouvez changer le type de nœud, le nombre de nœuds ou les deux, de manière similaire au redimensionnement élastique. Le redimensionnement classique prend plus de temps, mais il peut être utile dans les cas où la modification du nombre de nœuds ou du type de nœud vers lequel migrer ne correspond pas aux limites du redimensionnement élastique. Cela peut par exemple s’appliquer lorsque la modification du nombre de nœuds est vraiment importante.
**Topics**
+ [Elastic resize (Redimensionnement élastique)](#elastic-resize)
+ [Classic resize (Redimensionnement Classic)](#classic-resize-faster)
## Elastic resize (Redimensionnement élastique)
Lorsque vous ajoutez ou supprimez des nœuds du même type, une opération de redimensionnement élastique se déroule selon les étapes suivantes :
1. Le redimensionnement élastique prend un instantané du cluster. Les tables sans sauvegarde ne sont prises en charge que pour les DC2 nœuds. Pour tous les autres types de clusters, les tables sans sauvegarde sont incluses dans l’instantané. Pour plus d’informations, consultez [Exclusion des tables des instantanés](working-with-snapshots.md#snapshots-no-backup-tables). Si votre cluster ne dispose pas d’instantané récent, car vous avez désactivé les instantanés automatiques, l’opération de sauvegarde peut prendre plus de temps. (Pour réduire au maximum le temps avant le début de l’opération de redimensionnement, nous vous recommandons d’activer les instantanés automatiques ou de créer un instantané manuel avant de démarrer le redimensionnement.) Lorsque vous démarrez un redimensionnement élastique et qu’une opération d’instantané est en cours, le redimensionnement élastique peut échouer si l’opération d’instantané ne se termine pas en quelques minutes. Pour plus d’informations, consultez [Instantanés et sauvegardes Amazon Redshift](working-with-snapshots.md).
1. L’opération fait migrer les métadonnées du cluster. Le cluster n’est pas disponible pendant quelques minutes. La majorité des requêtes sont temporairement interrompues et les connexions restent ouvertes. Il est toutefois possible que certaines requêtes soient supprimées. Cette étape est courte.
1. Les connexions de séance sont réactivées et les requêtes reprennent leur exécution.
1. Le redimensionnement élastique redistribue les données vers les tranches de nœuds en arrière-plan. Le cluster est disponible pour les opérations de lecture et d’écriture, mais certaines requêtes peuvent prendre plus de temps à s’exécuter.
1. Une fois l’opération terminée, Amazon Redshift envoie une notification d’événement.
Lorsque vous utilisez le redimensionnement élastique pour modifier le type de nœud, cela fonctionne de la même manière que lorsque vous ajoutez ou retirez des nœuds du même type. Tout d’abord, un instantané est créé. Un nouveau cluster cible est provisionné avec les dernières données de l’instantané, et les données sont transférées vers le nouveau cluster en arrière-plan. Pendant cette période, les données sont en lecture seule. Lorsque le redimensionnement est presque terminé, Amazon Redshift met à jour le point de terminaison pour désigner le nouveau cluster, et toutes les connexions au cluster source sont supprimées.
Il est peu probable qu’un redimensionnement élastique échoue. Cependant, en cas de panne, la restauration se fait automatiquement dans la majorité des cas sans intervention manuelle.
Si vous avez des nœuds réservés, par exemple des nœuds DC2 réservés, vous pouvez passer à des nœuds RA3 réservés lorsque vous effectuez un redimensionnement. Vous pouvez le faire lorsque vous effectuez un redimensionnement élastique ou lorsque vous utilisez la console pour effectuer une restauration à partir d’un instantané. Cette console vous guide tout au long de ce processus. Pour plus d'informations sur la mise à niveau vers RA3 des nœuds, consultez la section [Mise à niveau vers des types de RA3 nœuds](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html#rs-upgrading-to-ra3).
Le redimensionnement élastique ne trie pas les tables ni ne récupère l’espace disque, et n’est donc pas un substitut d’une opération VACUUM. Pour plus d’informations, consultez [Exécution de l’opération VACUUM sur les tables](https://docs.aws.amazon.com/redshift/latest/dg/t_Reclaiming_storage_space202.html).
Le redimensionnement élastique présente les contraintes suivantes :
+ *Clusters de redimensionnement élastique et de partage de données* – Lorsque vous ajoutez ou supprimez des nœuds sur un cluster qui est un producteur pour le partage de données, vous ne pouvez pas vous y connecter à partir des consommateurs pendant qu’Amazon Redshift migre les métadonnées du cluster. De même, si vous effectuez un redimensionnement élastique et que vous choisissez un nouveau type de nœud, le partage des données est indisponible pendant que les connexions sont supprimées et transférées vers le nouveau cluster cible. Dans les deux types de redimensionnement élastique, le producteur est indisponible pendant plusieurs minutes.
+ *Data transfer from a shared snapshot* (Transfert de données à partir d’un instantané partagé) : pour exécuter un redimensionnement élastique sur un cluster qui transfère des données à partir d’un instantané partagé, au moins une sauvegarde doit être disponible pour le cluster. Vous pouvez afficher vos sauvegardes dans la liste des instantanés de la console Amazon Redshift, la commande de la CLI `describe-cluster-snapshots` ou l’opération d’API `DescribeClusterSnapshots`.
+ *Platform restriction* (Restriction de plateforme) : le redimensionnement élastique est disponible uniquement pour les clusters qui utilisent la plateforme EC2-VPC. Pour plus d’informations, consultez [Utiliser EC2 pour créer votre cluster](working-with-clusters.md#cluster-platforms).
+ *Storage considerations* (Considérations en matière de stockage) : assurez-vous que votre nouvelle configuration de nœuds dispose de suffisamment de stockage pour les données existantes. Vous devrez peut-être ajouter des nœuds supplémentaires ou modifier la configuration.
+ *Source vs target cluster size* (Taille de cluster source vs cible) : le nombre et le type de nœuds que vous pouvez redimensionner avec le redimensionnement élastique sont déterminées par le nombre de nœuds du cluster source et le type de nœud choisi pour le cluster redimensionné. Pour déterminer les configurations potentielles disponibles, vous pouvez utiliser la console. Ou vous pouvez utiliser la `describe-node-configuration-options` AWS CLI commande avec l'`action-type resize-cluster`option. Pour en savoir plus sur la modification des métadonnées à l’aide de la console Amazon Redshift, consultez [Redimensionnement d’un cluster](#resizing-cluster).
L’exemple de commande de CLI suivant décrit les options de configuration disponibles. Dans cet exemple, le cluster nommé `mycluster` est un cluster `dc2.large` à 8 nœuds.
```
aws redshift describe-node-configuration-options --cluster-identifier mycluster --region eu-west-1 --action-type resize-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. Les configurations renvoyées peuvent varier selon le cluster d’entrée spécifique. Vous pouvez choisir l’une de ces configurations lorsque vous spécifiez les options de la commande CLI `resize-cluster`.
+ *Ceiling on additional nodes* (Plafond sur les nœuds supplémentaires) : le redimensionnement élastique a des limites sur les nœuds que vous pouvez ajouter à un cluster. Par exemple, un cluster dc2 prend en charge le redimensionnement élastique jusqu’au double du nombre de nœuds. Pour illustrer cela, vous pouvez ajouter un nœud à un cluster dc2.8xlarge à 4 nœuds pour en faire un cluster à cinq nœuds, ou ajouter d’autres nœuds jusqu’à atteindre huit nœuds.
**Note**
Les limites de croissance et de réduction sont basées sur le type de nœud d’origine et le nombre de nœuds du cluster d’origine ou de son dernier redimensionnement classique. Si un redimensionnement élastique dépasse les limites de croissance ou de réduction, utilisez un redimensionnement classique.
Avec certains types de nœuds ra3, vous pouvez augmenter le nombre de nœuds jusqu’à quatre fois le nombre existant. Concrètement, supposons que votre cluster se compose de nœuds ra3.4xlarge ou ra3.16xlarge. Vous pouvez utiliser le redimensionnement élastique pour augmenter à 32 le nombre de nœuds dans un cluster à 8 nœuds. Sinon, vous pouvez choisir une valeur en dessous de la limite. (Gardez à l’esprit que la possibilité de quadrupler le cluster dépend de la taille du cluster source.) Si votre cluster a des nœuds ra3.xlplus, la limite est le double.
Tous les types de nœuds ra3 prennent en charge une diminution du nombre de nœuds à un quart du nombre existant. Par exemple, vous pouvez réduire la taille d’un cluster avec des nœuds ra3.4xlarge de 12 nœuds à 3, ou à un nombre au-dessus du minimum.
Le tableau suivant répertorie les limites d’augmentation et de réduction pour chaque type de nœud prenant en charge le redimensionnement élastique.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/redshift/latest/mgmt/resizing-cluster.html)
**Note**
**Choix des types de nœuds existants lorsque vous redimensionnez un RA3 cluster** : si vous tentez de redimensionner un cluster contenant des RA3 nœuds vers un autre type de nœud, par exemple DC2, un message d'avertissement de validation apparaît dans la console et l'opération de redimensionnement ne sera pas terminée. En effet, le redimensionnement vers des types de nœuds existants n’est pas pris en charge. Cela vise à empêcher un client d’effectuer un redimensionnement vers un type de nœud obsolète ou sur le point de l’être. Cela s’applique à la fois au redimensionnement élastique et au redimensionnement classique.
## Classic resize (Redimensionnement Classic)
Le redimensionnement classique gère les cas où la modification de la taille du cluster ou du type de nœud n’est pas conforme au redimensionnement élastique. Lorsque vous effectuez un redimensionnement classique, Amazon Redshift crée un cluster cible et y migre vos données et métadonnées depuis le cluster source.
### Redimensionnement classique pour RA3 une meilleure disponibilité
Le redimensionnement classique a été amélioré lorsque le type de nœud cible est RA3. Pour ce faire, utilisez une opération de sauvegarde et de restauration entre le cluster source et le cluster cible. Lorsque le redimensionnement commence, le cluster source redémarre et est indisponible pendant quelques minutes. Le cluster est ensuite disponible pour des opérations de lecture et d’écriture pendant que le redimensionnement continue en arrière-plan.
#### Vérification de votre cluster
Pour garantir les meilleures performances et les meilleurs résultats lorsque vous effectuez un redimensionnement classique sur un RA3 cluster, complétez cette liste de contrôle. Si vous ne suivez pas la liste de contrôle, vous risquez de ne pas bénéficier de certains des avantages du redimensionnement classique avec des RA3 nœuds, tels que la possibilité d'effectuer des opérations de lecture et d'écriture.
1. La taille des données doit être inférieure à 2 pétaoctets. (Un pétaoctet équivaut à 1 000 téraoctets.) Pour valider la taille de vos données, créez un instantané et vérifiez sa taille. Vous pouvez également exécuter la requête suivante pour vérifier la taille :
```
SELECT
sum(case when lower(diststyle) like ('%key%') then size else 0 end) distkey_blocks,
sum(size) as total_blocks,
((distkey_blocks/(total_blocks*1.00)))*100 as Blocks_need_redist
FROM svv_table_info;
```
La table `svv_table_info` n’est visible que par les super-utilisateurs.
1. Avant de lancer un redimensionnement classique, assurez-vous de disposer d’un instantané manuel qui ne date pas de plus de 10 heures. Si ce n’est pas le cas, prenez un instantané.
1. L’instantané utilisé pour effectuer le redimensionnement classique ne peut pas être utilisé à des fins de restauration de table ou autres.
1. Le cluster doit se trouver dans un VPC.
#### Opérations de tri et de distribution résultant du redimensionnement classique vers RA3
Lors du redimensionnement classique vers RA3, les tables avec une distribution KEY qui sont migrées en tant que distribution EVEN sont reconverties dans leur style de distribution d'origine. La durée de cette opération dépend de la taille des données et de l’activité de votre cluster. Les charges de travail liées aux requêtes sont traitées en priorité par rapport à la migration des données. Pour plus d’informations, consultez [Styles de distribution](https://docs.aws.amazon.com/redshift/latest/dg/c_choosing_dist_sort.html). Les lectures et les écritures dans la base de données fonctionnent au cours de ce processus de migration, mais le traitement des requêtes peut prendre plus de temps. Toutefois, la mise à l’échelle de la simultanéité peut améliorer les performances dans cette période en ajoutant des ressources pour les charges de travail liées aux requêtes. Vous pouvez voir la progression de la migration des données en consultant les résultats dans les vues [SYS\$1RESTORE\$1STATE](https://docs.aws.amazon.com/redshift/latest/dg/SYS_RESTORE_STATE.html) et [SYS\$1RESTORE\$1LOG](https://docs.aws.amazon.com/redshift/latest/dg/SYS_RESTORE_LOG.html). Vous trouverez plus d’informations sur la surveillance ci-dessous.
Une fois le cluster entièrement redimensionné, le comportement de tri suivant se produit :
+ Si le redimensionnement entraîne la présence d’un plus grand nombre de tranches dans le cluster, les tables de distribution KEY ne sont partiellement pas triées, mais les tables EVEN restent triées. De plus, les informations relatives à la quantité de données triées peuvent ne pas être à jour, directement après le redimensionnement. Après avoir récupéré les clés, l’opération automatic vacuum trie la table au fil du temps.
+ Si le redimensionnement entraîne moins de tranches dans le cluster, les tables de distribution KEY ne partiellement non triées. L’opération automatic vacuum trie la table au fil du temps.
Pour plus d’informations sur l’opérations automatic table vacuum, consultez [Exécution de l’opération VACUUM sur les tables](https://docs.aws.amazon.com/redshift/latest/dg/t_Reclaiming_storage_space202.html). Pour plus d’informations sur les tranches dans les nœuds de calcul, consultez [Architecture système de l’entrepôt des données](https://docs.aws.amazon.com/redshift/latest/dg/c_high_level_system_architecture.html).
#### Étapes de redimensionnement classiques lorsque le cluster cible est RA3
Le redimensionnement classique comprend les étapes suivantes, lorsque le type de cluster cible est le suivant RA3 et que vous répondez aux conditions requises détaillées dans la section précédente.
1. Migration initiée du cluster source vers le cluster cible. Lorsque le nouveau cluster cible est provisionné, Amazon Redshift envoie une notification d’événement indiquant que le redimensionnement a commencé. Il redémarre votre cluster existant, ce qui ferme toutes les connexions. Si votre cluster existant est un cluster producteur d’unités de partage des données, les connexions avec les clusters consommateur sont également fermées. Le redémarrage prend quelques minutes.
1. Après le redémarrage, la base de données est disponible en lecture et en écriture. De plus, le partage de données reprend, ce qui prend quelques minutes supplémentaires.
1. Les données sont migrées vers le cluster cible. Lorsque le type de nœud cible est RA3, les lectures et les écritures sont disponibles pendant la migration des données.
1. Lorsque le processus de redimensionnement est presque terminé, Amazon Redshift met à jour le point de terminaison vers le cluster cible et toutes les connexions sont supprimées. Le cluster cible devient le producteur pour le partage des données.
1. Le redimensionnement se termine. Amazon Redshift envoie une notification d’événement.
Vous pouvez afficher la progression du redimensionnement dans la console Amazon Redshift. Le temps nécessaire au redimensionnement d’un cluster dépend de la quantité de données.
**Note**
**Choix des types de nœuds existants lorsque vous redimensionnez un RA3 cluster** : si vous tentez de redimensionner un cluster contenant des RA3 nœuds vers un autre type de nœud, par exemple DC2, un message d'avertissement de validation apparaît dans la console et l'opération de redimensionnement ne sera pas terminée. En effet, le redimensionnement vers des types de nœuds existants n’est pas pris en charge. Cela vise à empêcher un client d’effectuer un redimensionnement vers un type de nœud obsolète ou sur le point de l’être. Cela s’applique à la fois au redimensionnement élastique et au redimensionnement classique.
#### Surveillance d'un redimensionnement classique lorsque le cluster cible est RA3
Pour surveiller un redimensionnement classique d’un cluster provisionné en cours, y compris la distribution KEY, utilisez [SYS\$1RESTORE\$1STATE](https://docs.aws.amazon.com/redshift/latest/dg/SYS_RESTORE_STATE.html). Il indique le pourcentage d’achèvement de la table en cours de conversion. Vous devez être un super-utilisateur pour accéder aux données.
Supprimez les tables dont vous n’avez pas besoin lorsque vous effectuez un redimensionnement classique. Ainsi, les tables existantes peuvent être distribuées plus rapidement.
### Étapes de redimensionnement classiques lorsque le cluster cible ne l'est pas RA3
Le redimensionnement classique consiste en ce qui suit, lorsque le type de nœud cible est autre chose que RA3, par exemple DC2, par exemple.
1. Migration initiée du cluster source vers le cluster cible. Lorsque le nouveau cluster cible est provisionné, Amazon Redshift envoie une notification d’événement indiquant que le redimensionnement a commencé. Il redémarre votre cluster existant, ce qui ferme toutes les connexions. Si votre cluster existant est un cluster producteur d’unités de partage des données, les connexions avec les clusters consommateur sont également fermées. Le redémarrage prend quelques minutes.
Notez que toute relation de base de données, telle qu’une table ou une vue matérialisée, créée avec `BACKUP NO` n’est pas conservée lors du redimensionnement classique. Pour plus d’informations, consultez [CREATE MATERIALIZED VIEW](https://docs.aws.amazon.com/redshift/latest/dg/materialized-view-create-sql-command.html).
1. Après le redémarrage, la base de données est disponible en lecture seule. Le partage de données reprend, ce qui prend quelques minutes supplémentaires.
1. Les données sont migrées vers le cluster cible. La base de données reste en lecture seule.
1. Lorsque le processus de redimensionnement est presque terminé, Amazon Redshift met à jour le point de terminaison vers le cluster cible et toutes les connexions sont supprimées. Le cluster cible devient le producteur pour le partage des données.
1. Le redimensionnement se termine. Amazon Redshift envoie une notification d’événement.
Vous pouvez afficher la progression du redimensionnement dans la console Amazon Redshift. Le temps nécessaire au redimensionnement d’un cluster dépend de la quantité de données.
**Note**
Le redimensionnement d'un cluster contenant une grande quantité de données peut prendre des jours, voire des semaines RA3, lorsque le cluster cible ne l'est pas ou s'il ne répond pas aux conditions requises pour un cluster RA3 cible détaillées dans la section précédente.
Notez également que la capacité de stockage utilisée pour le cluster peut augmenter après un redimensionnement classique. Il s’agit d’un comportement normal du système lorsque le cluster dispose de tranches de données supplémentaires à la suite du redimensionnement classique. Cette utilisation de capacité supplémentaire peut se produire même lorsque le nombre de nœuds du cluster est inchangé.
### Redimensionnement élastique vs redimensionnement classique
La table suivante compare le comportement entre les deux types de redimensionnement.
| Comportement | Elastic resize (Redimensionnement élastique) | Classic resize (Redimensionnement Classic) | Commentaires |
| --- | --- | --- | --- |
| Conservation des données système | Le redimensionnement élastique conserve les données des journaux système. | Le redimensionnement classique ne conserve pas les tables et les données système. | Si la journalisation des audits est activée dans votre cluster source, vous pouvez continuer à accéder aux journaux dans Amazon S3 ou dans Amazon S3 CloudWatch, après un redimensionnement. Vous pouvez conserver ou supprimer ces journaux, selon ce que vos stratégies de données spécifient. |
| Modification des types de nœuds | Pour le redimensionnement élastique, lorsque le type de nœud ne change pas : le redimensionnement sur place, et la plupart des requêtes sont conservées. Pour le redimensionnement élastique, avec un nouveau type de nœud sélectionné : un nouveau cluster est créé. Les requêtes sont supprimées à la fin du processus de redimensionnement. | Pour le redimensionnement classique : un nouveau cluster est créé. Les requêtes sont supprimées lors du processus de redimensionnement. | |
| Conservation des sessions et des requêtes | Le redimensionnement élastique conserve les sessions et les requêtes lorsque le type de nœud est identique dans le cluster source et le cluster cible. Si vous choisissez un nouveau type de nœud, les requêtes sont supprimées. | Le redimensionnement classique ne conserve pas les sessions et les requêtes. Les requêtes sont supprimées. | Lorsque des requêtes sont supprimées, une dégradation des performances est possible. Il est préférable d’effectuer une opération de redimensionnement pendant une période de faible utilisation. |
| Annulation d’une opération de redimensionnement | Il n’est pas possible d’annuler un redimensionnement élastique. | Vous pouvez annuler une opération de redimensionnement avant qu’elle se termine. Pour ce faire, choisissez **Cancel resize (Annuler le redimensionnement)** dans les détails du cluster de la console Amazon Redshift. | Le temps nécessaire pour annuler un redimensionnement dépend de la phase de l’opération de redimensionnement où vous vous trouvez quand vous annulez. Lorsque vous faites cela, le cluster n’est pas disponible tant que l’opération d’annulation n’est pas terminée. Si l’opération de redimensionnement est en phase finale, vous ne pouvez pas l’annuler. Pour le redimensionnement classique vers un RA3 cluster, vous ne pouvez pas annuler. |
### Planification d’un redimensionnement
Vous pouvez planifier des opérations de redimensionnement pour votre cluster afin de l’augmenter pour anticiper une utilisation élevée ou de le réduire pour diminuer les coûts. La planification fonctionne à la fois pour le redimensionnement élastique et le redimensionnement classique. Vous pouvez configurer une planification dans la console Amazon Redshift. Pour plus d’informations, consulte [Redimensionnement d’un cluster](#resizing-cluster) dans la section **Gestion des clusters à l’aide de la console**. Vous pouvez également utiliser AWS CLI les opérations de l'API Amazon Redshift pour planifier un redimensionnement. Pour plus d'informations, consultez [create-scheduled-action](https://docs.aws.amazon.com/cli/latest/reference/redshift/create-scheduled-action.html)la *référence des AWS CLI commandes* ou [CreateScheduledAction](https://docs.aws.amazon.com/redshift/latest/APIReference/API_CreateScheduledAction.html)la référence des *API Amazon Redshift*.
### Capture instantanée, restauration et redimensionnement
Le [redimensionnement élastique](#elastic-resize) est la méthode la plus rapide pour redimensionner un cluster Amazon Redshift. Si le redimensionnement élastique n’est pas une option et que vous avez besoin d’un accès quasiment constant en écriture à votre cluster, utilisez les opérations de capture instantanée et de restauration décrites dans la section suivante. Cette approche requiert que les données écrites sur le cluster source une fois que l’instantané a été pris soient copiées manuellement sur le cluster cible après le basculement. En fonction de la durée de la copie, vous devrez peut-être répéter l’opération plusieurs fois jusqu’à ce que vous ayez les mêmes données dans les deux clusters. Ensuite, vous pourrez effectuer le basculement vers le cluster cible. Ce processus peut avoir un impact négatif sur les requêtes existantes jusqu’à ce que l’ensemble complet des données soit disponible dans le cluster cible. Toutefois, il réduit au maximum le temps pendant lequel vous ne pouvez pas écrire dans la base de données.
L’approche via les instantanés, la restauration et le redimensionnement Classic utilise le processus suivant :
1. Prenez un instantané de votre cluster existant. Le cluster existant est le cluster source.
1. Notez l’heure de prise de l’instantané. Cette opération signifie que vous pourrez identifier plus tard le point où vous devrez reprendre les processus d’extraction, de transformation et de chargement (ETL) pour charger les éventuelles données post-instantané dans la base de données cible.
1. Restaurez l’instantané dans un nouveau cluster. Ce nouveau cluster est le cluster cible. Vérifiez que l’exemple de données existe dans le cluster cible.
1. Redimensionnez le cluster cible. Choisissez les nouveaux type de nœud, nombre de nœuds et autres paramètres du cluster cible.
1. Passez en revue les charges de vos processus ETL qui se sont produits après que vous avez pris un instantané du cluster source. Veillez à recharger les mêmes données, dans le même ordre, dans le cluster cible. Si vous avez des charges de données en cours, répétez ce processus plusieurs fois jusqu’à ce que les données soient les mêmes dans les clusters source et cible.
1. Arrêtez toutes les requêtes en cours d’exécution sur le cluster source. Pour ce faire, vous pouvez redémarrer le cluster, ou vous connecter en tant que super-utilisateur et utiliser les commandes [PG\$1CANCEL\$1BACKEND](https://docs.aws.amazon.com/redshift/latest/dg/PG_CANCEL_BACKEND.html) et [PG\$1TERMINATE\$1BACKEND](https://docs.aws.amazon.com/redshift/latest/dg/PG_TERMINATE_BACKEND.html). Le redémarrage du cluster est la solution la plus simple pour vous assurer que le cluster n’est pas disponible.
1. Renommez le cluster source. Par exemple, renommez-le de `examplecluster` en `examplecluster-source`.
1. Renommez le cluster cible afin d’utiliser le nom du cluster source avant de le renommer. Par exemple, renommez le cluster cible en `examplecluster`. À partir de cet instant, toutes les applications qui utilisent le point de terminaison contenant `examplecluster` se connectent au cluster cible.
1. Supprimez le cluster source après que vous avez basculé sur le cluster cible et vérifiez que tous les processus fonctionnent comme prévu.
Sinon, vous pouvez renommer les clusters source et cible avant de recharger les données dans le cluster cible. Cette approche fonctionne si vous n’êtes pas soumis à une exigence selon laquelle tous les systèmes et rapports dépendants doivent être immédiatement à jour avec ceux du cluster cible. Dans ce cas, l’étape 6 est déplacée à la fin du processus décrit précédemment.
Le processus consistant à renommer le cluster n’est nécessaire que si vous voulez que les applications continuent à utiliser le même point de terminaison pour se connecter au cluster. S’il ne s’agit pas de l’une de vos exigences, vous pouvez à la place mettre à jour toutes les applications qui se connectent au cluster afin d’utiliser le point de terminaison du cluster cible sans modifier le nom du cluster.
La réutilisation d’un nom de cluster présente deux avantages. Premièrement, vous n’avez pas besoin de mettre à jour les chaînes de connexion d’application, car le point de terminaison ne change pas, même si le cluster sous-jacent change. Ensuite, les éléments connexes tels que les CloudWatch alarmes Amazon et les notifications Amazon Simple Notification Service (Amazon SNS) sont liés au nom du cluster. Ce lien signifie que vous pouvez continuer à utiliser les mêmes alarmes et notifications que celles que vous avez configurées pour le cluster. Cette poursuite de l’utilisation est principalement une préoccupation dans les environnements de production où vous voulez avoir la possibilité de redimensionner le cluster sans avoir à reconfigurer les éléments connexes, tels que les alarmes et les notifications.
# Renommer un cluster
Vous pouvez renommer un cluster si vous souhaitez que le cluster utilise un autre nom. Comme le point de terminaison de votre cluster inclut le nom du cluster (également appelé *identificateur de cluster*), le point de terminaison se met à utiliser le nouveau nom une fois que l’opération de modification du nom se termine. Par exemple, si vous avez un cluster nommé `examplecluster` et que vous le renommez `newcluster`, le point de terminaison utilisera l’identificateur `newcluster`. Toutes les applications qui se connectent au cluster doivent être mises à jour avec le nouveau point de terminaison.
Vous pouvez renommer un cluster si vous voulez modifier le cluster auquel se connectent vos applications sans devoir changer le point de terminaison de ces applications. Dans ce cas, vous devez d’abord renommer le cluster d’origine, puis modifier le deuxième cluster pour réutiliser le nom du cluster d’origine avant de le renommer. Cela est nécessaire, car l’identifiant de cluster doit être unique au sein de votre compte et de la région (le cluster d’origine et le second cluster ne peuvent pas avoir le même nom). Vous pouvez agir ainsi si vous restaurez un cluster à partir d’un instantané et ne voulez pas modifier les propriétés de connexion d’applications dépendantes.
**Note**
Si vous supprimez le cluster d’origine, vous êtes responsable de la suppression des instantanés de cluster indésirables.
Lorsque vous renommez un cluster, l’état du cluster devient `renaming` jusqu’à la fin du processus. L’ancien nom DNS qui a été utilisé par le cluster est immédiatement supprimé, même s’il peut demeurer mis en cache pendant quelques minutes. Le nouveau nom DNS du cluster renommé devient effectif au bout de 10 minutes environ. Le cluster renommé n’est pas disponible jusqu’à ce que le nouveau nom ne devienne effectif. Le cluster est redémarré et toutes les connexions existantes au cluster sont supprimées. Une fois l’opération terminée, le point de terminaison est modifié pour utiliser le nouveau nom. Pour cette raison, vous devez arrêter l’exécution des requêtes avant de démarrer la définition du nouveau nom et la redémarrer une fois le nouveau nom créé.
Les instantanés de cluster sont conservés, et tous les instantanés associés à un cluster demeurent associés à ce cluster après qu’il a été renommé. Supposons que vous disposiez d’un cluster qui dessert votre base de données de production et que ce cluster ait plusieurs instantanés. Si vous renommez le cluster, puis le remplacez dans l’environnement de production par un instantané, le cluster que vous avez renommé continue de conserver les instantanés existants qui lui sont associés.
CloudWatch Les alarmes Amazon et les notifications d'événements Amazon Simple Notification Service (Amazon SNS) sont associées au nom du cluster. Si vous renommez le cluster, vous devez mettre à jour ces informations en conséquence. **Vous pouvez mettre à jour les CloudWatch alarmes dans la CloudWatch console, et vous pouvez mettre à jour les notifications d'événements Amazon SNS dans la console Amazon Redshift dans le volet Événements.** Les données de charge et de requête du cluster continuent d’afficher les données antérieures et postérieures à l’attribution du nouveau nom. Cependant, les données de performance sont réinitialisées une fois le processus d’attribution de nouveau nom terminé.
Pour plus d’informations, consultez [Modification d’un cluster](modify-cluster.md).
# Mise à niveau de la version d’un cluster
Vous pouvez effectuer une mise à niveau de la version de maintenance d’un cluster qui a une valeur de **Statut de publication** de **Nouvelle version disponible**. Lorsque vous mettez à niveau la version de maintenance, vous pouvez choisir de mettre à niveau immédiatement ou la mise à niveau lors de la prochaine fenêtre de maintenance.
**Important**
Si vous mettez à niveau immédiatement, votre cluster sera hors ligne jusqu’à ce que la mise à niveau soit terminée.
**Pour vous mettre à niveau vers une nouvelle version de cluster**
1. Connectez-vous à la console Amazon Redshift AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/)
1. Dans le menu de navigation, choisissez **Clusters**.
1. Choisissez le cluster à mettre à niveau.
1. Pour **Actions**, choisissez **Mettre à niveau la version du cluster**. La page **Mettre à niveau la version du cluster**.
1. Suivez les instructions indiquées sur la page.
1. Choisissez **Mettre à niveau la version du cluster**.
# Suspension et reprise d’un cluster
Si vous disposez d’un cluster qui ne doit être disponible qu’à des moments spécifiques, vous pouvez le mettre en pause et le reprendre ultérieurement. Pendant que le cluster est suspendu, la facturation à la demande est suspendue. Seul le stockage du cluster entraîne des frais. Pour plus d’informations sur la tarification, consultez la [Page de tarification Amazon Redshift](https://aws.amazon.com/redshift/pricing/).
Lorsque vous mettez en pause un cluster, Amazon Redshift crée un instantané, commence à mettre fin aux requêtes et met le cluster en pause. Si vous supprimez un cluster suspendu sans demander un instantané final, vous ne pouvez pas restaurer le cluster. Vous ne pouvez pas annuler ou restaurer après une pause ou reprendre une opération après son lancement.
Vous pouvez suspendre et reprendre un cluster sur la console Amazon Redshift, avec ou avec les opérations AWS CLI d'API Amazon Redshift.
Vous pouvez planifier des actions pour interrompre et reprendre un cluster. Lorsque vous utilisez la nouvelle console Amazon Redshift pour créer une planification périodique pour interrompre et reprendre, deux actions planifiées sont créées pour la plage de dates que vous choisissez. Les noms d’actions planifiées sont suffixés par `-pause` et `-resume`. La longueur totale du nom doit correspondre à la taille maximale d’un nom d’action planifiée.
Vous ne pouvez pas mettre en pause les types de clusters suivants :
+ Clusters EC2-Classic.
+ Clusters qui ne sont pas actifs, par exemple un cluster en cours de modification.
+ Clusters du module de sécurité matériel (HSM)
+ Clusters dont les instantanés automatisés sont désactivés.
Lorsque vous décidez de mettre un cluster en pause, tenez compte des éléments suivants :
+ Les connexions ou requêtes au cluster ne sont pas disponibles.
+ Vous ne pouvez pas voir les informations de surveillance des requêtes d’un cluster mis en pause sur la console Amazon Redshift.
+ Vous ne pouvez pas modifier un cluster suspendu. Les actions planifiées sur le cluster ne sont pas effectuées. Il s’agit notamment de créer des instantanés, de redimensionner les clusters et d’effectuer des opérations de maintenance de cluster.
+ Les métriques matérielles ne sont pas créées. Mettez à jour vos CloudWatch alarmes si vous avez défini des alarmes en fonction de mesures manquantes.
+ Vous ne pouvez pas copier les derniers instantanés automatisés d’un cluster suspendu vers des instantanés manuels.
+ Pendant qu’un cluster est en pause, il ne peut pas être repris tant que l’opération de pause n’est pas terminée.
+ Lorsque vous mettez en pause un cluster, la facturation est suspendue. Toutefois, l’opération de pause se termine généralement en 15 minutes, selon la taille du cluster.
+ Les journaux d’audit sont archivés et ne sont pas restaurés à la reprise.
+ Après la suspension d’un cluster, les traces et les journaux peuvent ne pas être disponibles pour résoudre les problèmes survenus avant la suspension.
+ Si vous gérez vos informations d'identification d'administrateur à l'aide de votre cluster AWS Secrets Manager et que vous le suspendez, le secret de votre cluster ne sera pas supprimé et vous continuerez à être facturé pour ce secret. Pour plus d'informations sur la gestion de votre mot de passe administrateur Redshift avec AWS Secrets Manager, consultez. [Gestion des mots de passe d'administration Amazon Redshift à l'aide de AWS Secrets Manager](redshift-secrets-manager-integration.md)
+ Les tables non sauvegardées du cluster sont restaurées lors de la reprise pour les types d' RA3 instance. Ils ne sont pas restaurés lors du CV, pour les types d' DC2 instances. Pour plus d’informations sur les tables sans sauvegarde, consultez [Exclusion des tables des instantanés](working-with-snapshots.md#snapshots-no-backup-tables).
Lorsque vous reprenez un cluster, tenez compte des éléments suivants :
+ La version de cluster du cluster repris est mise à jour vers la version de maintenance basée sur la fenêtre de maintenance du cluster.
+ Si vous supprimez le sous-réseau associé à un cluster en pause, vous pouvez avoir un réseau incompatible. Dans ce cas, restaurez votre cluster à partir du dernier instantané.
+ Si vous supprimez une adresse IP élastique pendant que le cluster est suspendu, une nouvelle adresse IP élastique est demandée.
+ Si Amazon Redshift ne parvient pas à reprendre le cluster avec son interface réseau Elastic précédente, Amazon Redshift essaie d’en allouer un nouveau.
+ Lorsque vous reprenez un cluster, les adresses IP de votre nœud peuvent changer. Vous devrez peut-être mettre à jour vos paramètres VPC pour prendre en charge ces nouvelles adresses IP pour des fonctionnalités telles que COPY depuis Secure Shell (SSH) ou COPY depuis Amazon EMR.
+ Si vous essayez de reprendre un cluster qui n’est pas suspendu, l’opération de reprise renvoie une erreur. Si l’opération de reprise fait partie d’une action planifiée, modifiez ou supprimez l’action planifiée pour éviter les erreurs futures.
+ Selon la taille du cluster, la reprise d’un cluster peut prendre plusieurs minutes avant que les requêtes puissent être traitées. En outre, les performances de la requête peuvent être affectées pendant un certain temps pendant que le cluster est réhydraté une fois la reprise terminée.
# Redémarrage d’un cluster
Le redémarrage d’un cluster est une opération de cluster qui redémarre le cluster avec la même configuration qu’avant le redémarrage. Vous pouvez redémarrer un cluster pour appliquer les mises à jour de maintenance en attente, réinitialiser les modifications de configuration, résoudre certains problèmes ou résoudre les problèmes du cluster. Le redémarrage d’un cluster peut contribuer à garantir des performances, une sécurité et une stabilité optimales de l’environnement Amazon Redshift. La procédure suivante fournit des étapes détaillées pour redémarrer un cluster Amazon Redshift.
Lorsque vous redémarrez un cluster, l’état du cluster est défini sur `rebooting` et un événement de cluster est créé lorsque le redémarrage est terminé. Toute modification du cluster en attente est appliquée à ce redémarrage.
**Pour redémarrer un cluster**
1. Connectez-vous à la console Amazon Redshift AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/)
1. Dans le menu de navigation, choisissez **Clusters**.
1. Choisissez le cluster à redémarrer.
1. Pour **Actions**, choisissez **Redémarrer le cluster**. La page **Redémarrer le cluster** s’affiche.
1. Choisissez **Redémarrer le cluster**.
# Relocalisation d’un cluster
Avec l’option de *relocation* (relocalisation) dans Amazon Redshift vous autorisez Amazon Redshift à déplacer un cluster vers une autre zone de disponibilité (AZ) sans perdre de données ni modifier vos applications. Avec la relocalisation, vous pouvez continuer les opérations en cas d’interruption de service sur votre cluster avec un impact minimal.
Lorsque la relocalisation des clusters est activée, Amazon Redshift peut relocaliser les clusters dans certaines situations. Cela se produit notamment lorsque des problèmes dans la zone de disponibilité empêchent le fonctionnement optimal du cluster, ou pour améliorer la disponibilité du service. Vous pouvez également appeler la fonction de relocalisation lorsque les contraintes de ressources dans une zone de disponibilité donnée perturbent les opérations du cluster. Vous pouvez, par exemple, reprendre ou redimensionner un cluster. Amazon Redshift propose la fonction de relocalisation sans frais supplémentaires.
Lorsqu’un cluster Amazon Redshift est déplacé vers une nouvelle zone de disponibilité, le nouveau cluster a le même point de terminaison que le cluster d’origine. Vos applications peuvent se reconnecter au point de terminaison et poursuivre les opérations sans modifications ni perte de données. Cependant, la relocalisation n’est pas toujours possible à cause des contraintes de ressources potentielles d’une zone de disponibilité.
La relocalisation de clusters Amazon Redshift n'est prise en charge que pour les types d' RA3 instances. RA3 les types d'instance utilisent le Redshift Managed Storage (RMS) comme couche de stockage durable. La dernière copie des données d'un cluster est toujours disponible dans les autres zones de disponibilité d'une AWS région. En d’autres termes, vous pouvez déplacer un cluster Amazon Redshift vers une autre zone de disponibilité sans aucune perte de données.
Lorsque vous activez la relocalisation pour votre cluster, Amazon Redshift migre votre cluster derrière un proxy. Cela permet un accès indépendant de l’emplacement aux ressources de calcul d’un cluster. Une migration provoque le redémarrage du cluster. Lorsqu’un cluster est déplacé vers une autre zone de disponibilité, le service est interrompu le temps que le nouveau cluster soit remis en ligne dans la nouvelle zone. Cependant, vous n’avez pas besoin d’apporter de modifications à vos applications car le point de terminaison du cluster reste inchangé, même après son déplacement dans la nouvelle zone de disponibilité.
La relocalisation de clusters est activée par défaut sur les RA3 clusters nouvellement créés ou restaurés dont le groupe de sous-réseaux inclut plusieurs zones de disponibilité. Amazon Redshift attribue le port 5439 par défaut lors de la création d’un cluster alloué. Vous pouvez passer à un autre port dans la plage de ports 5431-5455 ou 8191-8215. (Ne passez pas à un port situé en dehors des plages. Cela entraîne une erreur.) Pour modifier le port par défaut d'un cluster provisionné, utilisez la console AWS CLI Amazon Redshift ou l'API Amazon Redshift. Pour modifier le port par défaut d'un groupe de travail sans serveur, utilisez l'API sans serveur Amazon Redshift AWS CLI ou l'API Amazon Redshift.
Si vous activez la relocalisation et que vous utilisez l’adresse IP du nœud principal pour accéder à votre cluster ou routage VPC amélioré, assurez-vous de modifier cet accès. À la place, utilisez l’adresse IP associée au point de terminaison de cloud privé virtuel (VPC) du cluster. Pour trouver l’adresse IP du cluster, recherchez et utilisez le point de terminaison du VPC dans la section **Network and security (Réseau et sécurité)** de la page de détails du cluster. Pour obtenir plus de détails sur le point de terminaison du VPC, connectez-vous à la console Amazon VPC.
Vous pouvez également utiliser la commande AWS Command Line Interface (AWS CLI) `describe-vpc-endpoints` pour obtenir l'interface Elastic Network associée au point de terminaison. Vous pouvez utiliser la commande `describe-network-interfaces` pour obtenir l’adresse IP associée. Pour plus d'informations sur les commandes Amazon Redshift, consultez la section AWS CLI Commandes [disponibles dans le manuel de référence des *AWS CLI commandes*](https://docs.aws.amazon.com/cli/latest/reference/redshift/index.html).
## Limitations
Lorsque vous utilisez l’option de relocalisation d’Amazon Redshift, tenez compte des limitations suivantes :
+ Il est possible que la relocalisation des clusters ne fonctionne pas dans certains cas suite aux limitations potentielles des ressources dans une zone de disponibilité donnée. Le cas échéant, Amazon Redshift ne modifie pas le cluster d’origine.
+ La relocalisation n'est pas prise en charge sur les familles d' DC2 instances de produits.
+ Vous ne pouvez pas effectuer de relocalisation d'une AWS région à l'autre.
+ La relocalisation d’Amazon Redshift utilise par défaut le numéro de port 5439. Vous pouvez également passer à un autre port situé dans la plage 5431-5455 ou 8191-8215.
## Gestion des déplacements à l’aide de la console
Vous pouvez gérer les paramètres de relocalisation des clusters à l’aide de la console Amazon Redshift.
### Désactivation de la relocalisation lors de la création d’un cluster
Procédez comme suit pour désactiver la relocalisation lors de la création d’un cluster.
**Pour désactiver la relocalisation d’un cluster**
1. Connectez-vous à la console Amazon Redshift AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/)
1. Dans le menu de navigation, choisissez **Clusters**.
1. Choisissez l’option **Create cluster (Créer un cluster)** pour créer un cluster. Pour plus d’informations sur la création d’un cluster, consultez [Commencer avec les entrepôts de données alloués Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/gsg/new-user.html) dans le *Guide de démarrage Amazon Redshift*.
1. Sous **Sauvegarde**, choisissez **Activer** pour **Relocalisation du cluster**. La relocalisation est activée par défaut.
1. Choisissez **Créer un cluster**.
### Modification du déplacement d’un cluster existant
Procédez comme suit pour modifier le paramètre de relocalisation d’un cluster existant.
**Pour modifier le paramètre de relocalisation d’un cluster existant**
1. Connectez-vous à la console Amazon Redshift AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/)
1. Dans le menu de navigation, choisissez **Clusters**. Les clusters associés à votre compte dans la AWS région actuelle sont répertoriés. Un sous-ensemble des propriétés de chaque cluster s’affiche dans les colonnes de la liste.
1. Dans la liste des clusters, choisissez le nom du cluster que vous souhaitez modifier. La page des détails du cluster s'affiche.
1. Cliquez sur l’onglet **Maintenance** et choisissez **Edit (Modifier)** dans la section **Backup details (Détails de la sauvegarde)**.
1. Sous **Sauvegarde**, choisissez **Activé**. La relocalisation est activée par défaut.
1. Choisissez **Modifier le cluster**.
### Relocalisation d’un cluster
Utilisez la procédure suivante pour relocaliser manuellement un cluster vers une autre zone de disponibilité. Cela est particulièrement utile lorsque vous souhaitez tester votre configuration réseau dans des zones de disponibilité secondaires ou lorsque vous rencontrez des contraintes de ressources dans la zone de disponibilité actuelle.
**Pour relocaliser un cluster vers une autre zone de disponibilité**
1. Connectez-vous à la console Amazon Redshift AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/)
1. Dans le menu de navigation, choisissez **Clusters**. Les clusters associés à votre compte dans la AWS région actuelle sont répertoriés. Un sous-ensemble des propriétés de chaque cluster s’affiche dans les colonnes de la liste.
1. Choisissez le nom du cluster que vous souhaitez relocaliser dans la liste. La page des détails du cluster s'affiche.
1. Pour **Actions**, choisissez **Relocate (Relocaliser)**. La page **Relocate cluster (Relocaliser le cluster)** s’affiche.
1. Vous pouvez également choisir une **Availability Zone (Zone de disponibilité)**. Si vous ne choisissez pas de zone de disponibilité, Amazon Redshift en choisit une pour vous.
Amazon Redshift démarre la relocalisation et indique le cluster comme étant relocalisé. Une fois la relocalisation terminée, le statut du cluster devient Available (Disponible).
## Gestion de la réinstallation à l’aide de la CLI Amazon Redshift
Vous pouvez gérer les paramètres de relocalisation du cluster à l’aide de l’interface de ligne de commande (CLI) AWS .
Avec la AWS CLI, l'exemple de commande suivant crée un cluster Amazon Redshift nommé **mycluster** dont la relocalisation est activée.
```
aws redshift create-cluster --cluster-identifier mycluster --number-of-nodes 2 --master-username enter a username --master-user-password enter a password --node-type ra3.4xlarge --port 5439 --no-availability-zone-relocation
```
Si votre cluster actuel utilise un port différent, vous devez le modifier de sorte qu’il utilise un port compris dans la plage de ports 5431-5455 ou 8191-8215 avant de le modifier pour activer la relocalisation. La valeur par défaut est 5439. L’exemple de commande suivant modifie le port si celui qu’utilise votre cluster n’est pas compris dans la plage donnée.
```
aws redshift modify-cluster --cluster-identifier mycluster --port 5439
```
L'exemple de commande suivant inclut le availability-zone-relocation paramètre sur le cluster Amazon Redshift.
```
aws redshift modify-cluster --cluster-identifier mycluster --availability-zone-relocation
```
L'exemple de commande suivant désactive le availability-zone-relocation paramètre sur le cluster Amazon Redshift.
```
aws redshift modify-cluster --cluster-identifier mycluster --no-availability-zone-relocation
```
L’exemple de commande suivant invoque la relocalisation du cluster Amazon Redshift.
```
aws redshift modify-cluster --cluster-identifier mycluster --availability-zone us-east-1b
```
# Définition d'une limite d'utilisation sur un cluster
Vous pouvez ajouter jusqu'à quatre limites d'utilisation pour contrôler l'utilisation de chacun des éléments suivants :
+ Mise à l’échelle de la simultanéité
+ Optimisations automatiques exécutées à l'aide de ressources de calcul supplémentaires
+ Utilisation de Redshift Spectrum
+ Partage de données entre régions
## Définition d'une limite d'utilisation pour un cluster provisionné
Voici la procédure à suivre pour définir une limite d'utilisation sur un cluster provisionné :
**Pour définir une limite d'utilisation pour un cluster**
1. Connectez-vous à la console Amazon Redshift AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/)
1. Accédez au cluster provisionné pour lequel vous souhaitez définir une limite.
1. Sur la page de détails du cluster, sélectionnez **Gérer la limite d'utilisation** dans le menu déroulant **Actions**. Vous pouvez également sélectionner l'onglet **Maintenance d'**un cluster, puis faire défiler l'écran vers le bas et sélectionner **Créer des limites d'utilisation**.
1. Sélectionnez **Ajouter une limite** pour la limite d'utilisation que vous souhaitez définir. Vous pouvez ajouter jusqu'à 4 limites pour une fonctionnalité donnée.
1. Définissez une **période** pour la limite d'utilisation, qui est **quotidienne**, **hebdomadaire** ou **mensuelle**.
1. Définissez une **limite d'utilisation**.
+ Pour le dimensionnement simultané et les optimisations automatiques exécutées en utilisant des limites de ressources de calcul supplémentaires, la limite d'utilisation est le temps passé par Amazon Redshift à utiliser la fonctionnalité au cours de la période donnée. Dans ce cas, la limite d'utilisation est définie en heures et en minutes.
+ Pour Redshift Spectrum, la limite d'utilisation est la quantité de données numérisées depuis Amazon S3. Dans ce cas, la limite d'utilisation est définie en téraoctets (To).
+ Pour le partage de données entre régions, la limite d'utilisation est la quantité de données transférées de la région productrice vers les régions consommatrices que les consommateurs peuvent interroger. Dans ce cas, la limite d'utilisation est définie en téraoctets (To).
1. Définissez l'**action** à exécuter par Amazon Redshift lorsque votre cluster atteint la limite. Les actions sont les suivantes :
+ **Connectez-vous à la table système** ‐ Ajoute un enregistrement à la vue système [SYS\$1QUERY\$1HISTORY](https://docs.aws.amazon.com/redshift/latest/dg/SYS_QUERY_HISTORY.html). Vous pouvez interroger la colonne usage\$1limit dans cette vue pour déterminer si une requête a dépassé la limite.
+ **Alerte** ‐ Utilise Amazon SNS pour configurer les abonnements aux notifications et envoyer des notifications en cas de dépassement d'une limite. Vous pouvez choisir une rubrique Amazon SNS existante, créer une nouvelle rubrique ou continuer sans rubrique.
+ **Désactiver la fonctionnalité** ‐ Désactive la fonctionnalité. Vous pouvez également choisir d'utiliser Amazon SNS pour envoyer une notification. Les utilisateurs peuvent continuer à utiliser le cluster pour d'autres tâches.
Les deux premières actions sont informatives, mais la dernière désactive l'utilisation de la fonctionnalité.
1. En bas de la page, choisissez **Enregistrer les modifications** pour enregistrer cette limite. Si vous définissez plusieurs limites à la fois, **Enregistrer les modifications** les enregistrera toutes en même temps.
# Arrêt et suppression d’un cluster
Vous pouvez arrêter votre cluster si vous voulez qu’il cesse de s’exécuter et d’entraîner des frais. Lorsque vous l’arrêtez, vous pouvez, le cas échéant, créer un instantané final. Si vous créez un instantané final, Amazon Redshift crée un instantané manuel de votre cluster avant de l’arrêter. Si vous envisagez de mettre en service un nouveau cluster avec les données et la configuration de celui que vous supprimez, vous avez besoin d’un instantané manuel. En utilisant un instantané manuel, vous pouvez restaurer l’instantané ultérieurement et reprendre l’utilisation du cluster.
Si vous n’avez plus besoin du cluster et de ses données, vous pouvez l’arrêter sans créer un instantané final. Dans ce cas, le cluster et les données sont supprimés définitivement.
Que vous arrêtiez ou pas votre cluster avec un instantané manuel final, tous les instantanés automatiques associés au cluster sont supprimés une fois que le cluster est arrêté. Les instantanés manuels associés au cluster sont conservés. Les instantanés manuels qui sont conservés, y compris l’instantané final facultatif, sont facturés au prix de stockage Amazon Simple Storage Service si vous n’avez pas d’autres clusters en cours d’exécution lorsque vous arrêtez le cluster ou si vous dépasserez le stockage gratuit disponible qui est fourni à vos clusters Amazon Redshift en cours d’exécution. Pour plus d’informations sur les frais de stockage des instantanés, consultez la [page de tarification Amazon Redshift](https://aws.amazon.com/redshift/pricing/).
La suppression d'un cluster entraîne également la suppression de tous les AWS Secrets Manager secrets associés.
**Pour supprimer un cluster**
1. Connectez-vous à la console Amazon Redshift AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/)
1. Dans le menu de navigation, choisissez **Clusters**.
1. Choisissez le cluster à supprimer.
1. Pour **Actions**, choisissez **Supprimer**. La page **Supprimer un cluster** s’affiche.
1. Choisissez **Supprimer le cluster**.
**Note**
Lorsque vous supprimez un cluster et que vous choisissez de créer un instantané final, Amazon Redshift arrête la demande de suppression si une opération de restauration est en cours sur le cluster. Dans ce cas, vous pouvez supprimer le cluster sans instantané final, ou vous pouvez le supprimer avec un instantané final une fois la restauration terminée.
# Instantanés et sauvegardes Amazon Redshift
Les snapshots sont point-in-time des sauvegardes d'un cluster. Il existe deux types d’instantanés : *automatisé* et *manuel*. Amazon Redshift stocke ces instantanés en interne dans Amazon S3 en utilisant une connexion SSL (Secure Sockets Layer) chiffrée.
Amazon Redshift prend automatiquement des instantanés incrémentaux qui effectuent le suivi des modifications du cluster depuis l’instantané automatique précédent. Les instantanés automatiques conservent toutes les données requises pour restaurer un cluster à partir d’un instantané. Vous pouvez créer une planification d’instantané pour contrôler le moment où les instantanés automatiques sont créés, ou vous pouvez créer un instantané manuel à tout moment.
Lorsque vous restaurez à partir d’un instantané, Amazon Redshift crée un nouveau cluster et le rend disponible avant que toutes les données ne soient chargées ; en conséquence, vous pouvez commencer à interroger le nouveau cluster immédiatement. Le cluster diffuse les données à la demande à partir de l’instantané en réponse aux requêtes actives, puis charge le reste des données à l’arrière-plan.
Lorsque vous lancez un cluster, vous pouvez définir la période de conservation des instantanés automatiques et manuels. Vous pouvez modifier la période de conservation par défaut des instantanés automatiques et manuels en modifiant le cluster. Vous pouvez modifier la période de conservation d’un instantané manuel lorsque vous créez l’instantané ou en modifiant l’instantané.
Vous pouvez suivre la progression des instantanés en consultant les détails des instantanés dans l'action CLI ou [DescribeClusterSnapshots](https://docs.aws.amazon.com/redshift/latest/APIReference/API_DescribeClusterSnapshots.html)API AWS Management Console, ou [describe-cluster-snapshots](https://docs.aws.amazon.com/cli/latest/reference/redshift/describe-cluster-snapshots.html)en appelant celle-ci. Pour un instantané en cours, sont affichées les informations telles que la taille de l’instantané incrémentiel, la vitesse de transfert, le temps passé et la durée restante estimée.
Pour vous assurer que vos sauvegardes sont toujours disponibles pour votre cluster, Amazon Redshift stocke les instantanés dans un compartiment Amazon S3 géré en interne par Amazon Redshift. Pour gérer les frais de stockage, évaluez combien de jours vous devez conserver les instantanés automatisés et configurez leur période de conservation en conséquence. Supprimez tous instantanés manuels dont vous n’avez plus besoin. Pour de plus amples informations sur les coûts de stockage des sauvegardes, consultez la page [Tarification Amazon Redshift](https://aws.amazon.com/redshift/pricing/).
Vous pouvez également créer et restaurer des instantanés à l'aide AWS Backup d'un service entièrement géré qui vous aide à centraliser et à automatiser la protection des données dans l'ensemble AWS des services, dans le cloud et sur site. Pour de plus amples informations, veuillez consulter [AWS Backup intégration avec Amazon Redshift](managing-aws-backup.md). Pour plus d'informations AWS Backup, voir [Qu'est-ce que c'est AWS Backup ?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) dans le *Guide AWS Backup du développeur*.
## Utilisation des instantanés et des sauvegardes dans Amazon Redshift sans serveur
Amazon Redshift Serverless, comme un cluster provisionné, vous permet d'effectuer une sauvegarde en tant que point-in-time représentation des objets et des données de l'espace de noms. Il existe deux types de sauvegardes dans Amazon Redshift sans serveur : les instantanés créés manuellement et les points de récupération qu’Amazon Redshift sans serveur crée automatiquement. Vous trouverez plus d’informations sur l’utilisation des instantanés pour Amazon Redshift sans serveur sur [Instantanés et points de récupération](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-snapshots-recovery-points.html).
Vous pouvez également restaurer un instantané de cluster alloué dans un espace de noms sans serveur. Pour plus d’informations, consultez [Restauration d’un espace de noms sans serveur à partir d’un instantané](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-snapshot-restore.html).
## Instantanés automatiques
Lorsque les instantanés automatiques sont activés pour un cluster, Amazon Redshift prend régulièrement des instantanés de ce cluster. Par défaut, Amazon Redshift prend un instantané environ toutes les 8 heures ou tous les 5 Go par nœud de modifications de données, selon la première de ces deux éventualités. Si vos données sont supérieures à 5 Go \$1 le nombre de nœuds, le délai le plus court entre deux créations automatiques d’instantanés est de 15 minutes. Vous pouvez également créer une planification d’instantané pour contrôler le moment où les instantanés automatiques sont créés. Si vous utilisez des programmations personnalisées, le délai minimum entre deux instantanés automatisés est d’une heure. Les instantanés automatiques sont activés par défaut lorsque vous créez un cluster.
Les instantanés automatiques sont supprimés après une période de conservation. La période de conservation par défaut est d’un jour, mais vous pouvez la modifier en utilisant la console Amazon Redshift ou par programmation en utilisant la CLI ou l’API Amazon Redshift.
Pour désactiver les instantanés automatiques, définissez la période de conservation sur zéro. Si vous désactivez les instantanés automatiques, Amazon Redshift cesse de prendre des instantanés et supprime les instantanés automatiques existants pour le cluster. Vous ne pouvez pas désactiver les instantanés automatiques pour les types de RA3 nœuds. Vous pouvez définir une période de rétention automatique pour un type de RA3 nœud comprise entre 1 et 35 jours.
Seul Amazon Redshift peut supprimer un instantané automatisé ; vous ne pouvez pas les supprimer manuellement. Amazon Redshift supprime les instantanés automatisés à la fin de leur période de conservation, lorsque vous désactivez les instantanés automatisés pour le cluster ou lorsque vous supprimez le cluster. *Amazon Redshift conserve le dernier instantané automatisé jusqu’à ce que vous désactiviez les instantanés automatisés ou supprimiez le cluster.*
Si vous souhaitez conserver un instantané automatique pendant une période plus longue, vous pouvez en créer une copie en tant qu’instantané manuel. L’instantané automatique et conserver jusqu’à la fin de la période de conservation, mais l’instantané manuel correspondant est conservé jusqu’à ce que vous le supprimiez manuellement ou jusqu’à la fin de la période de conservation.
## Planifications d’un instantané automatique
Pour contrôler précisément le moment où les instantanés sont pris, vous pouvez créer une planification d’instantané et attacher celle-ci à un ou plusieurs clusters. Lorsque vous modifiez une planification d’instantané, la planification est modifiée pour tous les clusters associés. Si aucune planification d’instantané n’est attachée à un cluster, ce dernier utilise la planification d’instantané automatisé par défaut.
Une *planification d’instantané* est un ensemble de règles de planification. Vous pouvez définir une règle de planification simple basée sur un intervalle spécifié, par exemple, toutes les 8 heures ou toutes les 12 heures. Vous pouvez également ajouter des règles pour prendre des instantanés certains jours de la semaine, à des heures spécifiques ou pendant des périodes spécifiques. Les règles peuvent également être définies à l’aide d’expressions cron de type Unix.
## Format de la planification d’instantané
Sur la console Amazon Redshift, vous pouvez créer une planification d’instantané. Ensuite, vous pouvez attacher une planification à un cluster pour déclencher la création d’un instantané système. Une planification peut être attachée à plusieurs clusters et vous pouvez créer plusieurs définitions cron dans une planification pour déclencher un instantané.
Vous pouvez définir une planification pour vos instantanés en utilisant une syntaxe cron. La définition de ces planifications utilise une syntaxe [cron](http://en.wikipedia.org/wiki/Cron) de type Unix modifiée. Vous spécifiez l’heure en [heure UTC (temps universel coordonné)](http://en.wikipedia.org/wiki/Coordinated_Universal_Time). Vous pouvez créer des planifications avec une fréquence maximum d’une heure et une précision minimum d’une minute.
Les expressions cron modifiées Amazon Redshift se composent de 3 champs obligatoires, séparés par des espaces.
**Syntaxe**
```
cron(Minutes Hours Day-of-month Month Day-of-week Year)
```
| **Champs** | **Valeurs** | **Caractères génériques** |
| --- | --- | --- |
| Minutes | 0–59 | , - \$1 / |
| Heures | 0 – 23 | , - \$1 / |
| D ay-of-month | 1–31 | , - \$1 ? / L W |
| Mois | 1–12 ou JAN–DEC | , - \$1 / |
| D ay-of-week | 1–7 ou dim.–sam. | , - \$1 ? L \$1 |
| Année | 1970-2199 | , - \$1 / |
**Caractères génériques**
+ Le caractère générique **,** (virgule) inclut des valeurs supplémentaires. Dans le champ `Day-of-week`, `MON,WED,FRI` correspond à lundi, mercredi et vendredi. Le nombre total de valeurs est limité à 24 par champ.
+ Le caractère générique **-** (tiret) spécifie des plages. Dans le champ `Hour`, 1–15 correspond aux heures 1 à 15 du jour spécifié.
+ Le caractère générique **\$1** (astérisque) inclut toutes les valeurs du champ. Dans le champ `Hours`, **\$1** inclut chaque heure.
+ Le caractère générique **/** (barre oblique) spécifie les incréments. Dans le champ `Hours`, vous pouvez saisir **1/10** pour spécifier toutes les 10 heures à partir de la première heure de la journée (par exemple, 01 h 00, 11 h 00 et 21 h 00).
+ Le caractère générique **?** (point d’interrogation) indique l’un ou l’autre. Dans le `Day-of-month` champ, tu pouvais saisir **7**, et si tu ne te souciais pas du jour de la semaine le septième, tu pourrais entrer **?** sur le Day-of-week terrain.
+ Le caractère générique **L** dans les champs ou spécifie le dernier jour du mois ou de la semaine.`Day-of-month``Day-of-week`
+ Le caractère générique **W** dans le champ spécifie un jour de la semaine. `Day-of-month` Dans le champ `Day-of-month`, `3W` spécifie le jour le plus proche du troisième jour de semaine du mois.
+ Le caractère générique **\$1** dans le Day-of-week champ indique une certaine instance du jour de la semaine spécifié dans un délai d'un mois. Par exemple, 3\$12 correspond au deuxième mardi du mois : le 3 fait référence à mardi, car c’est le troisième jour de chaque semaine, et le 2 fait référence à la deuxième journée de ce type dans le mois.
**Note**
Si vous utilisez un caractère « \$1 », vous ne pouvez définir qu'une seule expression dans le day-of-week champ. Par exemple, « 3\$11,6\$13 » n’est pas valide, car il est interprété comme deux expressions.
**Restrictions**
+ Vous ne pouvez pas spécifier les champs `Day-of-month` et `Day-of-week` de la même expression cron. Si vous spécifiez une valeur dans l’un de ces champs, vous devez utiliser un signe **?** (point d’interrogation) dans l’autre.
+ Les programmes d’instantanés ne prennent pas en charge les fréquences suivantes :
+ Instantanés programmés à une fréquence supérieure à 1 par heure.
+ Instantanés programmés à une fréquence inférieure à 1 par jour (24 heures).
Si des planifications se chevauchent et entraînent la planification de plusieurs instantanés dans une fenêtre d’une heure, une erreur de validation se produit.
Lors de la création d’une planification, vous pouvez utiliser les exemples de chaînes cron suivants.
| Minutes | Heures | Jour de la semaine | Signification |
| --- | --- | --- | --- |
| 0 | 14-20/1 | TUE | Mardi, toutes les heures entre 14 h 00 et 20 h 00. |
| 0 | 21 | MON-FRI | Tous les soirs à 21 h 00 du lundi au vendredi. |
| 30 | 0/6 | SAT-SUN | Le samedi et le dimanche, toutes les 6 heures, 30 minutes après minuit (00 h 30). Le résultat est un instantané chaque jour à 00 h 30, 06 h 30, 12 h 30 et 18 h 30. |
| 30 | 12/4 | \$1 | Tous les jours, toutes les 4 heures à partir de 12 h 30. Cela équivaut à 12 h 30, 16 h 30, 20 h 30. |
Par exemple, pour une exécution quotidienne toutes les 2 heures à partir de 15 h 15. Cela équivaut à 15 h 15, 17 h 15, 19 h 15, 21 h 15, 23 h 15, spécifiez :
```
cron(15 15/2 *)
```
Vous pourrez créer plusieurs définitions de planification cron dans une planification. Par exemple, la AWS CLI commande suivante contient deux programmes cron dans un seul programme.
```
create-snapshot-schedule --schedule-identifier "my-test" --schedule-definition "cron(0 17 SAT,SUN)" "cron(0 9,17 MON-FRI)"
```
## Instantanés manuels
Vous pouvez prendre un instantané manuel à tout moment. Par défaut, les instantanés manuels sont conservés indéfiniment, même après la suppression de votre cluster. Vous pouvez spécifier la période de conservation lorsque vous créez un instantané manuel ou vous pouvez changer la période de conservation en modifiant l’instantané. Pour plus d’informations sur la modification de la durée de conservation, consultez [Modification de la période de conservation d’un instantané manuel](snapshot-manual-retention-period.md).
Si un instantané est supprimé, vous ne pouvez pas démarrer de nouvelles opérations qui référencent cet instantané. Cependant, si une opération de restauration est en cours, elle s’exécute intégralement.
Amazon Redshift dispose d'un quota qui limite le nombre total de clichés manuels que vous pouvez créer ; ce quota est fixé par AWS compte et par région. AWS Le quota par défaut est répertorié dans [Quotas et limites d’Amazon Redshift](amazon-redshift-limits.md).
## Stockage d’instantanés
Comme les instantanés entraînent des frais de stockage, il est important que vous les supprimiez lorsque vous n’en avez plus besoin. Amazon Redshift supprime les instantanés automatisés et manuels à la fin de leurs périodes de conservation respectives. Vous pouvez également supprimer des instantanés manuels à l'aide de la commande AWS Management Console ou de la [batch-delete-cluster-snapshots](https://docs.aws.amazon.com/cli/latest/reference/redshift/batch-delete-cluster-snapshots.html)CLI.
Vous pouvez modifier la période de conservation d’un instantané manuel en modifiant ses paramètres.
Vous pouvez obtenir des informations sur la quantité de stockage consommée par vos instantanés à l’aide de la console Amazon Redshift ou de la commande [describe-storage](https://docs.aws.amazon.com/cli/latest/reference/redshift/describe-storage.html) de la CLI.
## Exclusion des tables des instantanés
Par défaut, toutes les tables permanentes définies par l’utilisateur sont incluses dans les instantanés. Si une table, par exemple une table intermédiaire, n’a pas besoin d’être sauvegardée, vous pouvez réduire considérablement le temps nécessaire à la création d’instantanés et à la restauration à partir d’instantanés. Vous réduisez également l’espace de stockage sur Amazon S3 à l’aide d’une table sans sauvegarde. Pour créer une table sans sauvegarde, incluez le paramètre BACKUP NO lorsque vous créez la table. Pour plus d’informations, consultez [CREATE TABLE](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_TABLE_NEW.html) et [CREATE TABLE AS](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_TABLE_AS.html) dans le *Manuel du développeur de base de données Amazon Redshift*.
**Note**
Les tables sans sauvegarde ne sont pas prises en charge pour les clusters RA3 provisionnés et les groupes de travail Amazon Redshift Serverless. Une table marquée comme non sauvegardée dans un RA3 cluster 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 éviter les coûts liés aux instantanés pour les tables sans sauvegarde, tronquez-les avant de prendre un instantané.
# Création d’un instantané manuel
Vous pouvez créer un instantané manuel d’un cluster dans la liste des instantanés comme suit. Sinon, vous pouvez effectuer un instantané d’un cluster dans le volet de configuration du cluster. Pour de plus amples informations, veuillez consulter [Instantanés et sauvegardes Amazon Redshift](working-with-snapshots.md).
**Note**
Les tables sans sauvegarde ne sont pas prises en charge pour les clusters RA3 provisionnés et les groupes de travail Amazon Redshift Serverless. Une table marquée comme non sauvegardée dans un RA3 cluster 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 éviter les coûts liés aux instantanés pour les tables sans sauvegarde, tronquez-les avant de prendre un instantané.
**Pour créer un snapshot manuel**
1. Connectez-vous à la console Amazon Redshift AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/)
1. Dans le menu de navigation, choisissez **Clusters**, **Snapshots (Instantanés)**, puis choisissez l’onglet **Create snapshot (Créer un instantané)**. La page d’instantané permettant de créer un instantané manuel s’affiche.
1. Entrez les propriétés de la définition de l’instantané, puis choisissez **Create snapshot (Créer un instantané)**. L’instantané n’est pas toujours disponible immédiatement.
# Création d’une planification d’instantané
Amazon Redshift effectue régulièrement des instantanés incrémentiels automatiques de vos données et les enregistre dans Amazon S3. De plus, vous pouvez effectuer des instantanés manuels de vos données quand vous le souhaitez.
Toutes les tâches d’instantanés dans la console Amazon Redshift démarrent à partir de la liste des instantanés. Vous pouvez filtrer la liste en fonction d’une plage de temps, du type d’instantané et du cluster associé à l’instantané. De plus, vous pouvez trier la liste par date, taille et type d’instantané. Selon le type d’instantané que vous sélectionnez, il est possible que vous puissiez choisir parmi différentes options pour utiliser l’instantané.
Pour contrôler précisément le moment où les instantanés sont pris, vous pouvez créer une planification d’instantané et attacher celle-ci à un ou plusieurs clusters. Vous pouvez attacher une planification lorsque vous créez un cluster ou en modifiant le cluster existant. Pour plus d’informations, consultez [Planifications d’un instantané automatique](working-with-snapshots.md#automated-snapshot-schedules).
**Pour créer une planification d’instantané**
1. Connectez-vous à la console Amazon Redshift AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/)
1. Dans le menu de navigation, choisissez **Clusters**, **Snapshots (Instantanés)**, puis choisissez l’onglet **Snapshot schedules (Planifications d’instantanés)**. Les planifications d’instantanés sont affichées.
1. Choisissez **Add schedule (Ajouter une planification)** pour afficher la page permettant d’ajouter une planification.
1. Entrez les propriétés de la définition de la planification, puis choisissez **Add schedule (Ajouter une planification)**.
1. Sur la page qui apparaît, vous pouvez attacher des clusters à votre nouvelle planification d’instantané, puis choisir **OK**.
# Partage d’un instantané
Vous pouvez partager un instantané manuel existant avec d'autres comptes AWS clients en autorisant l'accès à l'instantané. Vous pouvez en autoriser jusqu'à 20 pour chaque instantané et 100 pour chaque clé AWS Key Management Service (AWS KMS). En d'autres termes, si vous avez 10 instantanés chiffrés à l'aide d'une seule clé KMS, vous pouvez autoriser 10 AWS comptes à restaurer chaque instantané, ou d'autres combinaisons qui ajoutent jusqu'à 100 comptes et ne dépassent pas 20 comptes pour chaque instantané. Une personne connectée comme utilisateur dans l’un des comptes autorisés peut alors décrire l’instantané ou le restaurer pour créer un nouveau cluster Amazon Redshift sous son compte. Par exemple, si vous utilisez des comptes AWS clients distincts pour la production et les tests, un utilisateur peut se connecter à l'aide du compte de production et partager un instantané avec les utilisateurs du compte de test. Une personne connectée comme utilisateur d’un compte tests peut alors restaurer l’instantané pour créer un nouveau cluster, détenu par le compte tests, à des fins de tests ou de diagnostic.
Un instantané manuel appartient en permanence au compte AWS client sous lequel il a été créé. Seuls les utilisateurs du compte détenteurs de l’instantané peuvent autoriser d’autres comptes à accéder à l’instantané ou à révoquer les autorisations. Les utilisateurs des comptes autorisés peuvent uniquement décrire ou restaurer un instantané qu’ils ont partagé ; ils ne peuvent pas copier ou supprimer des instantanés qu’ils ont partagés. Une autorisation reste en vigueur jusqu’à ce que le propriétaire de l’instantané la révoque. Si une autorisation est révoquée, l’utilisateur précédemment autorisé perd la visibilité de l’instantané et ne peut pas lancer de nouvelles actions faisant référence à l’instantané. Si le compte est en train de restaurer l’instantané lorsque l’accès est révoqué, la restauration s’exécute jusqu’à la fin. Vous ne pouvez pas supprimer un instantané pendant qu’il a des autorisations actives ; vous devez d’abord révoquer toutes les autorisations.
AWS les comptes clients sont toujours autorisés à accéder aux instantanés détenus par le compte. Les tentatives d’autorisation ou de révocation de l’accès au compte propriétaire entraînent une erreur. Vous ne pouvez pas restaurer ou décrire un instantané appartenant à un compte AWS client inactif.
Une fois que vous avez autorisé l'accès à un compte AWS client, aucun utilisateur de ce compte ne peut effectuer d'action sur l'instantané, sauf s'il assume un rôle dans le cadre de politiques le permettant.
+ Les utilisateurs du compte propriétaire de l’instantané ne peuvent autoriser et révoquer l’accès à un instantané que s’ils assument un rôle avec une politique IAM qui leur permet d’exécuter ces actions avec une spécification de ressource incluant l’instantané. Par exemple, la politique suivante permet à un utilisateur ou à un rôle dans le AWS compte `012345678912` d'autoriser d'autres comptes à accéder à un instantané nommé `my-snapshot20130829` :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"redshift:AuthorizeSnapshotAccess",
"redshift:RevokeSnapshotAccess"
],
"Resource":[
"arn:aws:redshift:us-east-1:012345678912:snapshot:*/my-snapshot20130829"
]
}
]
}
```
------
+ Les utilisateurs d'un AWS compte avec lequel un instantané a été partagé ne peuvent pas effectuer d'actions sur cet instantané s'ils ne disposent pas des autorisations les autorisant. Vous pouvez le faire en attribuant la politique à un rôle et en assumant ce rôle.
+ Pour afficher ou décrire un instantané, ils doivent avoir une politique IAM autorisant l’action `DescribeClusterSnapshots`. Le code suivant en présente un exemple :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"redshift:DescribeClusterSnapshots"
],
"Resource":[
"*"
]
}
]
}
```
------
+ Pour restaurer un instantané, un utilisateur doit assumer un rôle avec une politique IAM permettant l’action `RestoreFromClusterSnapshot` et ayant un élément de ressource qui couvre à la fois le cluster qu’il crée et l’instantané. Par exemple, si un utilisateur du compte `012345678912` a partagé l’instantané `my-snapshot20130829` avec le compte `219876543210`, pour pouvoir créer un cluster en restaurant l’instantané, un utilisateur du compte `219876543210` doit assumer un rôle avec un politique telle que la suivante :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"redshift:RestoreFromClusterSnapshot"
],
"Resource":[
"arn:aws:redshift:us-east-1:012345678912:snapshot:*/my-snapshot20130829",
"arn:aws:redshift:us-east-1:219876543210:cluster:from-another-account"
]
}
]
}
```
------
+ Une fois que l'accès à un instantané a été révoqué depuis un AWS compte, aucun utilisateur de ce compte ne peut accéder à l'instantané. Cela s’applique même si ces comptes ont des politiques IAM qui autorisent des actions sur la ressource d’instantané précédemment partagée.
## Partage d’un instantané de cluster à l’aide de la console
Sur la console, vous pouvez autoriser d’autres utilisateurs à accéder à un instantané manuel que vous possédez et vous pouvez révoquer ultérieurement cet accès, lorsqu’il n’est plus nécessaire.
**Pour partager un instantané avec un autre compte**
1. Connectez-vous à la console Amazon Redshift AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/)
1. Dans le menu de navigation, choisissez **Clusters**, **Instantanés**, puis choisissez l’instantané manuel à partager.
1. Pour **Actions**, choisissez **Manual snapshot settings (Paramètres d’instantané manuel)** pour afficher les propriétés de l’instantané manuel.
1. Entrez le ou les comptes à partager dans la section **Gérer l’accès**, puis choisissez **Enregistrer**.
## Considérations en matière de sécurité pour le partage d’instantanés chiffrés
Lorsque vous donnez accès à un instantané chiffré, Redshift exige que la clé gérée par le client KMS d’ AWS utilisée pour créer l’instantané soit partagée avec le ou les comptes qui effectuent la restauration. Si la clé n’est pas partagée, la tentative de restauration de l’instantané entraîne une erreur d’accès refusé. Le compte récepteur n’a pas besoin d’autorisations supplémentaires pour restaurer un instantané partagé. Lorsque vous autorisez l’accès aux instantanés et que vous partagez la clé, l’identité autorisant l’accès doit avoir les autorisations `kms:DescribeKey` sur la clé qui a été utilisée pour chiffrer l’instantané. Cette autorisation est décrite plus en détail dans [Autorisations AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html). Pour plus d'informations, consultez [DescribeKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_DescribeKey.html)la documentation de référence de l'API Amazon Redshift.
La stratégie de clé gérée par le client peut être mise à jour par programme ou dans la console AWS Key Management Service .
**Note**
Si vous utilisez une clé KMS par défaut, vous n’avez pas besoin d’effectuer des actions ou de modifier quoi que ce soit dans AWS KMS pour partager un instantané.
### Autoriser l'accès à la clé AWS KMS pour un instantané chiffré
Pour partager la clé gérée par le client AWS KMS pour un instantané chiffré, mettez à jour la politique en matière de clés en effectuant les étapes suivantes :
1. Mettez à jour la stratégie de clé KMS avec l’Amazon Resource Name (ARN) du compte AWS que vous partagez en tant que `Principal` dans la stratégie de clé KMS.
1. Autoriser l’action `kms:Decrypt`.
Dans l’exemple de stratégie de clé suivant, l’utilisateur `111122223333` est le propriétaire de la clé KMS et l’utilisateur `444455556666` est le compte avec lequel la clé est partagée. Cette politique clé permet au AWS compte d'accéder à l'exemple de clé KMS en incluant l'ARN pour l'identité du AWS compte racine de l'utilisateur en `444455556666` tant `Principal` que politique, et en autorisant l'`kms:Decrypt`action.
------
#### [ JSON ]
****
```
{
"Id": "key-policy-1",
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Allow use of the key",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:user/KeyUser",
"arn:aws:iam::444455556666:root"
]
},
"Action": [
"kms:Decrypt"
],
"Resource": "*"
}
]
}
```
------
Une fois que l'accès à la clé KMS gérée par le client est accordé, le compte qui restaure le snapshot chiffré doit créer un rôle Gestion des identités et des accès AWS (IAM), ou un utilisateur, s'il n'en possède pas déjà un. En outre, ce AWS compte doit également associer une politique IAM à ce rôle ou à cet utilisateur IAM qui lui permet de restaurer un instantané de base de données chiffré à l'aide de votre clé KMS.
Pour plus d'informations sur l'octroi d'accès à une AWS KMS clé, voir [Autoriser les utilisateurs d'autres comptes à utiliser une clé KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html#cross-account-console) dans le guide du AWS Key Management Service développeur.
Pour un aperçu des principales politiques, consultez [Comment Amazon Redshift](https://docs.aws.amazon.com/kms/latest/developerguide/services-redshift.html) les utilise. AWS KMS
# Copie d’un instantané automatique
Les instantanés automatiques sont supprimés automatiquement à l’expiration de leur période de conservation, lorsque vous désactivez les instantanés automatiques ou lorsque vous supprimez un cluster. Si vous souhaitez conserver un instantané automatique, vous pouvez le copier dans un instantané manuel.
**Pour copier un instantané automatique**
1. Connectez-vous à la console Amazon Redshift AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/)
1. Dans le menu de navigation, choisissez **Clusters**, **Instantanés**, puis choisissez l’instantané à copier.
1. Pour **Actions**, choisissez **Copier un instantané automatisé** pour copier l’instantané.
1. Mettez à jour les propriétés du nouvel instantané, puis choisissez **Copier**.
# Copier un instantané dans une autre AWS région
Vous pouvez configurer Amazon Redshift pour copier automatiquement les instantanés (automatisés ou manuels) d'un cluster vers une autre région. AWS Lorsqu'un instantané est créé dans la AWS région principale du cluster, il est copié dans une AWS région secondaire. Les deux AWS régions sont connues respectivement sous le nom de * AWS région source* et * AWS région de destination*. Si vous stockez une copie de vos instantanés dans une autre AWS région, vous pouvez restaurer votre cluster à partir de données récentes si quelque chose affecte la AWS région principale. Vous pouvez configurer votre cluster pour copier des instantanés dans une seule AWS région de destination à la fois. Pour obtenir une liste des régions Amazon Redshift, reportez-vous à [Régions et points de terminaison](https://docs.aws.amazon.com/general/latest/gr/rande.html) dans *Référence générale d'Amazon Web Services*.
Lorsque vous autorisez Amazon Redshift à copier automatiquement des instantanés vers une autre AWS région, vous spécifiez la région de destination AWS dans laquelle les instantanés seront copiés. Pour les instantanés automatisés, vous pouvez également spécifier la période de conservation pour les conserver dans la AWS région de destination. Une fois qu'un instantané automatique est copié dans la AWS région de destination et qu'il atteint la période de conservation de cette région, il est supprimé de la AWS région de destination. Cela permet de limiter l’utilisation des instantanés. Pour conserver les instantanés automatisés plus ou moins longtemps dans la AWS région de destination, modifiez cette période de conservation.
La période de conservation que vous définissez pour les instantanés automatisés copiés dans la AWS région de destination est distincte de la période de conservation des instantanés automatiques dans la région source AWS . La période de conservation par défaut pour les instantanés copiés est de 7 jours. Cette période de sept jours s’applique uniquement aux instantanés automatiques. Dans les AWS régions source et de destination, les instantanés manuels sont supprimés à la fin de la période de conservation des instantanés ou lorsque vous les supprimez manuellement.
Vous pouvez désactiver la copie d’instantané automatique d’un cluster à tout moment. Lorsque vous désactivez cette fonctionnalité, les instantanés ne sont plus copiés de la AWS région source vers la région de destination AWS . Tous les instantanés automatisés copiés dans la AWS région de destination sont supprimés lorsqu'ils atteignent la limite de durée de conservation, sauf si vous en créez manuellement des copies instantanées. Ces instantanés manuels, ainsi que tous les instantanés manuels copiés depuis la région de destination, sont conservés dans AWS la région de destination AWS jusqu'à ce que vous les supprimiez manuellement.
Pour modifier la AWS région de destination dans laquelle vous copiez les instantanés, désactivez d'abord la fonction de copie automatique. Réactivez-la ensuite, en spécifiant la nouvelle région AWS de destination.
Une fois qu'un instantané est copié dans la AWS région de destination, il devient actif et disponible à des fins de restauration.
Pour copier des instantanés de clusters AWS KMS chiffrés vers une autre AWS région, créez une autorisation permettant à Amazon Redshift d'utiliser une clé gérée par le client dans la région de destination. AWS Choisissez ensuite cette autorisation lorsque vous activez la copie des instantanés dans la AWS région source. Pour plus d’informations sur la configuration des autorisations de copie d’instantané, consultez [Copier des instantanés AWS KMS chiffrés vers un autre Région AWS](working-with-db-encryption.md#configure-snapshot-copy-grant).
# 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 provisionnés et les groupes de travail Amazon Redshift Serverless. Une table marquée comme non sauvegardée dans un RA3 cluster 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\$1START – REDSHIFT-EVENT-2008 envoyé lorsque le processus de restauration commence.
1. RESTORE\$1SUCESS – REDSHIFT-EVENT-3003 envoyé lorsque le nouveau cluster a été créé.
Le cluster est disponible pour les requêtes.
1. DATA\$1TRANSFER\$1COMPLETED – REDSHIFT-EVENT-3537 envoyé lorsque le transfert de données est terminé.
**Note**
RA3 les clusters émettent uniquement les événements RESTORE\$1STARTED et RESTORE\$1SUCCEDED. Aucun transfert de données explicite ne doit être effectué après la réussite d'une restauration, car les types de RA3 nœuds stockent les données dans le stockage géré par Amazon Redshift. Avec RA3 les nœuds, les données sont transférées en continu entre les RA3 nœuds et le stockage géré par Amazon Redshift dans le cadre du traitement normal des requêtes. RA3 les nœuds mettent en cache les données sensibles localement et conservent automatiquement les blocs les moins fréquemment demandés dans le stockage géré Amazon Redshift.
Vous pouvez suivre la progression d'une restauration en appelant l'opération [DescribeClusters](https://docs.aws.amazon.com/redshift/latest/APIReference/API_DescribeClusters.html)API ou en consultant les détails du cluster dans le 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 mesures, voir [RestoreStatus](https://docs.aws.amazon.com/redshift/latest/APIReference/API_RestoreStatus.html).
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 `describe-node-configuration-options` AWS CLI commande 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é](#working-with-snapshot-restore-cluster-from-snapshot).
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
```
1. 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
```
1. 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
}
]
}
```
1. 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 DC2 réservés, vous pouvez passer à des nœuds RA3 réservés. 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 RA3 des nœuds, consultez la section [Mise à niveau vers des types de RA3 nœuds](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html#rs-upgrading-to-ra3).
**Pour restaurer le cluster à partir d’un instantané sur la console**
1. Connectez-vous à la console Amazon Redshift AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/)
1. Dans le menu de navigation, choisissez **Clusters**, **Instantanés**, puis choisissez l’instantané à restaurer.
1. 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é.
1. 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 un Clé gérée par AWS | Chiffré avec un Clé gérée par AWS |
| Cluster alloué | Chiffré avec un Clé détenue par AWS | Chiffré avec un Clé détenue par AWS |
| Espace de noms sans serveur | Chiffré avec un Clé gérée par AWS | Chiffré avec un Clé détenue par AWS |
| Espace de noms sans serveur | Chiffré avec un Clé détenue par AWS | Chiffré avec un Clé détenue par AWS |
Si vous avez AWS Secrets Manager géré le mot de passe administrateur de votre cluster au moment où l'instantané a été pris, vous devez continuer AWS Secrets Manager à l'utiliser pour gérer le mot de passe 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 passer à des nœuds RA3 réservés. 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 RA3 des nœuds, consultez la section [Mise à niveau vers des types de RA3 nœuds](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html#rs-upgrading-to-ra3).
# Restauration d’une table à partir d’un instantané
Vous pouvez restaurer une table à partir d’un instantané au lieu de restaurer l’intégralité du cluster. Lorsque vous restaurez une table unique à partir d’un instantané, vous indiquez l’instantané source, la base de données, le schéma et le nom de la table, ainsi que la base de données cible, le schéma et un nouveau nom de table pour la table restaurée.
**Note**
Les tables sans sauvegarde ne sont pas prises en charge pour les clusters RA3 provisionnés et les groupes de travail Amazon Redshift Serverless. Une table marquée comme non sauvegardée dans un RA3 cluster 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é. Cependant, la restauration sélective de tables sans sauvegarde n’est pas prise en charge.
Le nouveau nom de table ne peut pas être le nom d’une table existante. Pour remplacer une table existante par une table restaurée à partir d’un instantané, renommez ou supprimez la table existante avant de restaurer la table à partir de l’instantané.
La table cible est créée à l’aide des définitions de colonne de la table source, des attributs de table et des attributs de colonne à l’exception des clés étrangères. Pour éviter les conflits liés aux dépendances, la table cible n’hérite pas les clés étrangères de la table source. Toutes les dépendances, telles que les vues ou les autorisations accordées sur la table source, ne sont pas appliquées à la table cible.
Si le propriétaire de la table source existe, l’utilisateur de la base de données est le propriétaire de la table restaurée, à condition que l’utilisateur dispose des autorisations suffisantes pour devenir le propriétaire d’une relation du schéma et de la base de données spécifiés. Sinon, la table restaurée appartient à l’administrateur qui a été créé lorsque le cluster a été lancé.
La table restaurée retourne à l’état où elle était au moment de la sauvegarde. Cela inclut les règles de visibilité des transactions, définies par l’adhésion d’Amazon Redshift au principe d’[isolement sérialisable](https://docs.aws.amazon.com/redshift/latest/dg/c_serial_isolation.html), qui signifie que les données sont immédiatement visibles des transactions en cours démarrées après la sauvegarde.
La restauration d’une table à partir d’un instantané présente les limitations suivantes :
+ Vous ne pouvez restaurer une table que sur le cluster actif en cours d’exécution, et à partir d’un instantané de ce cluster.
+ Vous ne pouvez restaurer qu’une seule table à la fois.
+ Vous ne pouvez pas restaurer une table à partir d’un instantané de cluster pris avant un redimensionnement. Néanmoins, vous pouvez restaurer une table après un redimensionnement élastique si le type de nœud n’a pas changé.
+ Toutes les dépendances, telles que les vues ou les autorisations accordées sur la table source, ne sont pas appliquées à la table cible.
+ Si la sécurité au niveau des lignes est activée pour une table en cours de restauration, Amazon Redshift restaure la table dans les mêmes conditions, avec la sécurité au niveau des lignes activée.
**Pour restaurer une table à partir d’un instantané**
1. Connectez-vous à la console Amazon Redshift AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/)
1. Dans le menu de navigation, choisissez **Clusters**, puis choisissez le cluster que vous souhaitez utiliser pour restaurer une table.
1. Pour **Actions**, choisissez **Restaurer une table** pour afficher la page **Restaurer une table**.
1. Entrez les informations sur l’instantané, la table source et la table cible à utiliser, puis choisissez **Restaurer la table**.
**Example Exemple : restauration d'une table à partir d'un instantané à l'aide du AWS CLI**
L'exemple suivant utilise la `restore-table-from-cluster-snapshot` AWS CLI commande pour restaurer la `my-source-table` table à partir du `sample-database` schéma du`my-snapshot-id`. Vous pouvez utiliser cette AWS CLI commande `describe-table-restore-status` pour vérifier l'état de votre opération de restauration. L’exemple restaure l’instantané sur le cluster `mycluster-example` avec le nouveau nom de table `my-new-table`.
```
aws redshift restore-table-from-cluster-snapshot --cluster-identifier mycluster-example
--new-table-name my-new-table
--snapshot-identifier my-snapshot-id
--source-database-name sample-database
--source-table-name my-source-table
```
# Restauration d’un espace de noms sans serveur à partir d’un instantané
La restauration d’un espace de noms sans serveur à partir d’un instantané remplace toutes les bases de données de l’espace de noms par les bases de données de l’instantané. Pour plus d’informations sur les instantanés sans serveur, consultez [Instantanés et points de récupération](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-snapshots-recovery-points.html). Amazon Redshift convertit automatiquement les tables avec des clés entrelacées en clés composées lorsque vous restaurez un instantané de cluster alloué dans un espace de noms Amazon Redshift sans serveur. Pour plus d’informations sur les clés de tri, consultez [Utilisation des clés de tri](https://docs.aws.amazon.com/redshift/latest/dg/t_Sorting_data.html).
Pour restaurer un instantané de votre cluster provisionné vers votre espace de noms sans serveur.
1. Connectez-vous à la console Amazon Redshift AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/)
1. Dans le menu de navigation, choisissez **Clusters**, **Snapshots** (Instantanés), puis choisissez l’instantané à utiliser.
1. Choisissez **Restore from snapshot** (Restaurer à partir d’un instantané), **Restore to serverless namespace** (Restaurer vers un espace de noms sans serveur).
1. Choisissez l’espace de noms vers lequel vous souhaitez restaurer.
1. Confirmez que vous souhaitez effectuer une restauration à partir de votre instantané. Choisissez **restore** (restaurer). Cette action remplace toutes les bases de données de l’espace noms sans serveur par les données de votre cluster provisionné.
# Configuration d’une copie d’instantané entre régions pour un cluster non chiffré
Vous pouvez configurer Amazon Redshift pour copier les instantanés d'un cluster vers une autre région. AWS Pour configurer la copie d'instantanés entre régions, vous devez activer cette fonctionnalité de copie pour chaque cluster et configurer l'emplacement de copie des instantanés et la durée de conservation des instantanés automatisés ou manuels copiés dans la région de destination. AWS Lorsque la copie entre régions est activée pour un cluster, tous les nouveaux instantanés manuels et automatisés sont copiés dans la région spécifiée AWS . Les noms d’instantané copiés sont préfixés par **copy:**.
**Pour configurer un instantané inter-région**
1. Connectez-vous à la console Amazon Redshift AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/)
1. Dans le menu de navigation, choisissez **Clusters**, puis le cluster dont vous souhaitez déplacer les instantanés.
1. Pour **Actions**, choisissez **Configure cross-region snapshot (Configurer un instantané entre régions)**.
La boîte de dialogue Configure cross-Region (Configurer entre régions) apparaît.
1. Pour **Copy snapshots (Copier les instantanés)**, choisissez **Yes (Oui)**.
1. Dans ** AWS Région de destination**, choisissez la AWS région dans laquelle vous souhaitez copier les instantanés.
1. Dans **Période de conservation automatique des instantanés (jours)**, choisissez le nombre de jours pendant lesquels vous souhaitez que les instantanés automatisés soient conservés dans la AWS région de destination avant leur suppression.
1. Dans **Période de conservation manuelle des instantanés**, choisissez la valeur qui représente le nombre de jours pendant lesquels vous souhaitez que les instantanés manuels soient conservés dans la AWS région de destination avant leur suppression. Si vous choisissez **Custom value (Valeur personnalisée)**, la période de conservation doit être comprise entre 1 et 3 653 jours.
1. Choisissez **Enregistrer**.
# Configuration de la copie instantanée entre régions pour un cluster AWS KMS chiffré
Lorsque vous lancez un cluster Amazon Redshift, vous pouvez configurer une autorisation de copie des instantanés pour une clé racine de votre compte dans la Région AWS de destination. Si vous ne configurez pas de subvention, les instantanés de la région de destination sont chiffrés à l'aide d'une clé AWS détenue par défaut. Vous permettez ainsi à Amazon Redshift d’effectuer des opérations de chiffrement dans la région AWS de destination.
La procédure suivante décrit le processus d'activation de la copie instantanée entre régions pour un cluster AWS KMS chiffré. Pour plus d’informations sur le chiffrement dans Amazon Redshift et les autorisations de copie d’instantanés, consultez [Copier des instantanés AWS KMS chiffrés vers un autre Région AWS](working-with-db-encryption.md#configure-snapshot-copy-grant).
**Pour configurer un instantané interrégional pour un cluster AWS KMS chiffré**
1. Connectez-vous à la console Amazon Redshift AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/)
1. Dans le menu de navigation, choisissez **Clusters**, puis le cluster dont vous souhaitez déplacer les instantanés.
1. Pour **Actions**, choisissez **Configure cross-region snapshot (Configurer un instantané entre régions)**.
La boîte de dialogue Configure cross-Region (Configurer entre régions) apparaît.
1. Pour **Copy snapshots (Copier les instantanés)**, choisissez **Yes (Oui)**.
1. Dans ** AWS Région de destination**, choisissez la AWS région dans laquelle vous souhaitez copier les instantanés.
1. Dans **Période de conservation automatique des instantanés (jours)**, choisissez le nombre de jours pendant lesquels vous souhaitez que les instantanés automatisés soient conservés dans la AWS région de destination avant leur suppression.
1. Dans **Période de conservation manuelle des instantanés**, choisissez la valeur qui représente le nombre de jours pendant lesquels vous souhaitez que les instantanés manuels soient conservés dans la AWS région de destination avant leur suppression. Si vous choisissez **Custom value (Valeur personnalisée)**, la période de conservation doit être comprise entre 1 et 3 653 jours.
1. Choisissez **Enregistrer**.
# Modification de la période de conservation d’un instantané manuel
Vous pouvez modifier la période de conservation d’un instantané manuel en modifiant ses paramètres.
**Pour modifier la période de conservation d’un instantané manuel**
1. Connectez-vous à la console Amazon Redshift AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/)
1. Dans le menu de navigation, choisissez **Clusters**, **Snapshots (Instantanés)**, puis choisissez l’instantané manuel à modifier.
1. Pour **Actions**, choisissez **Manual snapshot settings (Paramètres d’instantané manuel)** pour afficher les propriétés de l’instantané manuel.
1. Entrez les propriétés révisées de la définition de l’instantané, puis choisissez **Save (Enregistrer)**.
# Modification de la période de conservation pour la copie d’instantanés entre régions
Après avoir configuré une copie d’instantanés entre régions, vous pouvez modifier les paramètres. Vous pouvez facilement modifier la période de conservation en sélectionnant un nouveau nombre de jours et en enregistrant les modifications.
**Avertissement**
Vous ne pouvez pas modifier la AWS région de destination une fois la copie instantanée entre régions configurée.
Si vous souhaitez copier des instantanés dans une autre AWS région, désactivez d'abord la copie d'instantanés entre régions. Réactivez-le ensuite avec une nouvelle AWS région de destination et une nouvelle période de conservation. Tous les instantanés automatisés copiés sont supprimés après la désactivation de la copie des instantanés inter-région. Vous devez donc déterminer si vous souhaitez en conserver et les copier dans des instantanés manuels avant de désactiver la copie d’instantanés inter-région.
**Pour modifier un instantané inter-région**
1. Connectez-vous à la console Amazon Redshift AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/)
1. Dans le menu de navigation, choisissez **Clusters**, puis le cluster pour lequel vous souhaitez modifier des instantanés.
1. Pour **Actions**, choisissez **Configurer un instantané inter-région** pour afficher les propriétés de l’instantané.
1. Entrez les propriétés révisées de la définition de l’instantané, puis choisissez **Save (Enregistrer)**.
# Suppression d’un instantané manuel
Vous pouvez supprimer des instantanés manuels en sélectionnant un ou plusieurs instantanés dans la liste des instantanés.
**Pour supprimer un instantané manuel**
1. Connectez-vous à la console Amazon Redshift AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/)
1. Dans le menu de navigation, choisissez **Clusters**, **Instantanés**, puis choisissez l’instantané à supprimer.
1. Pour **Actions**, choisissez **Delete snapshot (Supprimer un instantané)** pour supprimer l’instantané.
1. Confirmez la suppression des instantanés répertoriés, puis choisissez **Delete (Supprimer)**.
# Enregistrement d'un cluster auprès du AWS Glue Data Catalog
Vous pouvez enregistrer des clusters entiers dans le AWS Glue Data Catalog et créer des catalogues gérés par AWS Glue. Vous pouvez accéder à ces catalogues avec n’importe quel moteur SQL prenant en charge l’API REST d’Apache Iceberg. Pour plus d’informations sur la création de catalogues compatibles avec Apache Iceberg depuis Amazon Redshift, consultez [Compatibilité d’Apache Iceberg pour Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/dg/iceberg-integration_overview.html) dans le Guide du développeur de base de données Amazon Redshift.
**Pour enregistrer un cluster auprès du AWS Glue Data Catalog**
1. Connectez-vous à la console Amazon Redshift AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/)
1. Dans le menu de navigation, choisissez **Clusters**. Les clusters associés à votre compte en cours Région AWS sont répertoriés. Un sous-ensemble des propriétés de chaque cluster s’affiche dans les colonnes de la liste. Si vous n’avez pas de clusters, choisissez **Créer un cluster** pour en créer un.
1. Choisissez le nom du cluster que vous voulez enregistrer.
1. Dans **Actions**, sélectionnez **Enregistrer auprès de AWS Glue Data Catalog**. La fenêtre contextuelle **Enregistrer auprès du AWS Glue Data Catalog** s’affiche.
1. Entrez l'ID de AWS compte sur lequel vous souhaitez enregistrer le cluster sous **ID de compte de destination**. Il s’agit de l’identifiant de compte qui contiendra le catalogue dans le AWS Glue Data Catalog.
1. Entrez un nom sous **Enregistrer l’espace de noms en tant que**. Ce sera le nom du cluster dans le catalogue de données.
1. Choisissez **S’inscrire**. Vous serez redirigé vers la AWS Lake Formation console.
1. Suivez le processus de création du catalogue dans AWS Lake Formation. Pour plus d’informations sur la création d’un catalogue, consultez [Intégration des données Amazon Redshift dans le AWS Glue Data Catalog](https://docs.aws.amazon.com/lake-formation/latest/dg/managing-namespaces-datacatalog.html) dans le Guide du développeur AWS Lake Formation .