View a markdown version of this page

Échec du Multi-AZ déploiement - Amazon Redshift

Amazon Redshift ne prendra plus en charge l'utilisation des UDF Python après le 30 juin 2026. Nous allons commencer à l'appliquer par étapes. Pour plus d'informations sur les détails de la fin de vie de Python et des options de migration, consultez le billet de blog publié le 30 juin 2025.

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.

Échec du Multi-AZ déploiement

Votre entrepôt de Multi-AZ données est un ensemble de ressources informatiques déployées simultanément dans deux zones de disponibilité. Les ressources de calcul déployées dans la zone de disponibilité principale sont désignées sous le terme de calcul principal et celles figurant dans les zones de disponibilité secondaires sont désignées sous le terme de calcul secondaire. Un entrepôt de Multi-AZ données peut être restauré automatiquement sans aucune intervention de l'utilisateur lors d'un événement peu probable, tel qu'une zone de disponibilité ou une panne d'infrastructure. Le processus de récupération implique le basculement du calcul principal vers le calcul secondaire et la désignation des ressources de calcul secondaire comme ressources de calcul principal. De plus, les nouvelles ressources de calcul secondaire sont provisionnées dans une troisième zone de disponibilité. Le processus de récupération automatique est mesuré en termes de RTO et de RPO.

  • Objectif de délai de reprise (RTO) : temps nécessaire à un système pour revenir à un état de fonctionnement normal après un sinistre. En d’autres termes, le RTO mesure les temps d’arrêt.

  • Objectif de point de reprise (RPO) : quantité de données pouvant être perdues (mesurée dans le temps). Pour un entrepôt de Multi-AZ données Amazon Redshift, le RPO est généralement égal à zéro car toutes les données sont stockées dans Amazon Redshift Managed Storage (RMS), soutenu par Amazon Simple Storage Service, qui est une solution hautement durable et disponible par défaut.

Note

Les performances d’une requête individuelle ne changent pas après un basculement. Le débit global de votre entrepôt des données est réduit pendant une courte période en raison de l’indisponibilité des ressources de calcul dans l’une des zones de disponibilité. Toutefois, Amazon Redshift acquerra automatiquement de la capacité dans une autre zone de disponibilité afin de garantir le rétablissement de la même capacité de traitement de l’entrepôt des données.

Outre le processus de récupération automatique, vous pouvez également déclencher ce processus manuellement pour votre entrepôt des données à l’aide de l’option Basculement du calcul principal. Vous pouvez utiliser cette approche pour tester la manière dont votre application Multi-AZ pourrait améliorer la haute disponibilité et la continuité.

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

  2. Effectuez l’une des actions suivantes :

    • Dans le menu de navigation, choisissez Clusters. Sous Clusters, choisissez un cluster. La page des détails du cluster s’affiche.

    • Dans le tableau de bord du cluster, choisissez un cluster.

  3. Dans Actions, choisissez Basculement du calcul principal.

  4. Lorsque vous y êtes invité, cliquez sur Confirm (Confirmer).

  • À partir de AWS CLI, utilisez la failover-primary-compute commande comme suit.

    aws redshift failover-primary-compute 
    --profile maz-test
    --endpoint-url  https://redshift.eu-west-1.amazonaws.com
    --region eu-west-1
    --cluster-identifier test-maz-11

Une fois l’opération ci-dessus confirmée, Amazon Redshift effectuera les mêmes étapes qu’une récupération automatique après une défaillance de zone de disponibilité ou d’infrastructure. Ce processus entraînera l’indisponibilité des nœuds de calcul dans la zone de disponibilité principale et la désignation des ressources de calcul dans la zone de disponibilité secondaire en tant que calcul principal. Lorsque la restauration du cluster est terminée avec succès, Multi-AZ le déploiement devient disponible. Votre entrepôt de Multi-AZ données provisionnera également automatiquement le nouveau calcul secondaire dans une autre troisième zone de disponibilité dès qu'il sera disponible.

Au cours de ce processus, l'état du cluster sur la console s'affiche comme étant en cours de modification pendant tout le temps, car le cluster se rétablit automatiquement et reconfigure la Multi-AZ configuration de déploiement. Le cluster peut accepter de nouvelles connexions immédiatement. Les connexions existantes et les requêtes en transit peuvent être supprimées. Vous pouvez les tester à nouveau immédiatement.