Redimensionnement des clusters

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.

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 des nœuds DC2 aux nœuds RA3. 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.

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. Cet instantané inclut toujours des tables sans sauvegarde pour les nœuds où cela est applicable. (Certains types de nœuds, comme RA3, n’ont pas de table sans sauvegarde.) 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.

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

3. Les connexions de séance sont réactivées et les requêtes reprennent leur exécution.

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

5. 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, le rollback 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 réservés DC2, vous pouvez passer à des nœuds réservés RA3 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 des nœuds RA3, consultez Mise à niveau vers des types de nœuds 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.

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 Utilisez EC2-VPC lorsque vous créez votre cluster.

• 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-clusteroption. Pour en savoir plus sur la modification des métadonnées à l’aide de la console Amazon Redshift, consultez Redimensionnement d’un 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.

  Type de nœud d’origine	Limite d’augmentation	Limite de réduction
  ra3.16xlarge	4x (de 4 à 16 nœuds, par exemple)	Jusqu’à un quart du nombre (de 16 à 4 nœuds, par exemple)
  ra3.4xlarge	4x	Jusqu’à un quart du nombre
  ra3.xlplus	2x (de 4 à 8 nœuds, par exemple)	Jusqu’à un quart du nombre
  dc2.8xlarge	2x	Jusqu’à la moitié du nombre (de 16 à 8 nœuds, par exemple)
  dc2.large	2x	Jusqu’à la moitié du nombre

  Note

  Choix des types de nœuds existants lorsque vous redimensionnez un cluster RA3 : si vous tentez de redimensionner un cluster contenant des nœuds RA3 vers un autre type de nœud, tel que 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.

Le redimensionnement classique vers RA3 peut offrir 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 des performances et des résultats optimaux lorsque vous effectuez un redimensionnement classique vers un cluster RA3, 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 les nœuds RA3, 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.

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

3. L’instantané utilisé pour effectuer le redimensionnement classique ne peut pas être utilisé à des fins de restauration de table ou autres.

4. Le cluster doit se trouver dans un VPC.

Opérations de tri et de distribution résultant d’un redimensionnement classique vers RA3

Lors d’un redimensionnement classique vers RA3, les tables avec une distribution KEY qui sont migrées comme une 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. 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_RESTORE_STATE et SYS_RESTORE_LOG. 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. Pour plus d’informations sur les tranches dans les nœuds de calcul, consultez Architecture système de l’entrepôt des données.

Étapes de redimensionnement classique lorsque le cluster cible est RA3

Le redimensionnement classique comprend les étapes suivantes, lorsque le type de cluster cible est RA3 et que vous remplissez les conditions préalables 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.

   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.

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

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

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

5. 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 cluster RA3 : si vous tentez de redimensionner un cluster contenant des nœuds RA3 vers un autre type de nœud, tel que 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_RESTORE_STATE. 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 classique lorsque le cluster cible n’est pas RA3

Le redimensionnement classique consiste en ce qui suit, lorsque le type de nœud cible est autre que RA3, comme 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.

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

3. Les données sont migrées vers le cluster cible. La base de données reste en lecture seule.

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

5. 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, lorsque le cluster cible n’est pas RA3 ou qu’il ne répond pas aux conditions requises pour un cluster cible RA3 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.

Redimensionnement élastique vs redimensionnement classique
Attitude	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 cluster RA3, vous ne pouvez pas l’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 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 dans la référence de AWS CLI commande ou Action dans la référence d'API Amazon CreateScheduledRedshift.

Capture instantanée, restauration et redimensionnement

Le redimensionnement élastique 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.

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

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

4. Redimensionnez le cluster cible. Choisissez les nouveaux type de nœud, nombre de nœuds et autres paramètres du cluster cible.

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

6. 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_CANCEL_BACKEND et PG_TERMINATE_BACKEND. Le redémarrage du cluster est la solution la plus simple pour vous assurer que le cluster n’est pas disponible.

7. Renommez le cluster source. Par exemple, renommez-le de examplecluster en examplecluster-source.

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

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