View a markdown version of this page

Configuration du Multi-AZ déploiement - Amazon Redshift
Limitations

Amazon Redshift ne prendra plus en charge la création de nouveaux UDFs Python à partir du patch 198. Les fonctions Python définies par l’utilisateur existantes continueront de fonctionner normalement jusqu’au 30 juin 2026. Pour plus d’informations, consultez le billet de blog .

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.

Configuration du Multi-AZ déploiement

Pour configurer un Multi-AZ déploiement, sélectionnez l'Multi-AZoption et spécifiez le nombre de nœuds de calcul à provisionner dans chaque zone de disponibilité. Amazon Redshift déploie automatiquement des ressources de calcul égales sur deux zones de disponibilité et toutes les ressources de calcul sont toujours disponibles pour le traitement en lecture et en écriture pendant le fonctionnement normal. Cela permet à un Multi-AZ déploiement d'agir comme un entrepôt de données unique avec un seul point de terminaison, éliminant ainsi le besoin de modifier les applications en cas de sinistre. Bien qu'un Multi-AZ déploiement traite une requête individuelle en utilisant les ressources de calcul résidant dans une seule zone de disponibilité, il peut automatiquement répartir le traitement de plusieurs requêtes simultanées vers les deux zones de disponibilité afin d'augmenter le débit global pour les charges de travail simultanées élevées.

Vous pouvez également convertir un entrepôt de Single-AZ données existant en entrepôt de Multi-AZ données ou vice versa. Tout reste identique, si ce n’est que des ressources de calcul supplémentaires sont provisionnées dans la deuxième zone de disponibilité. Lors de la migration Multi-AZ depuis un Single-AZ cluster existant, vous devrez peut-être doubler le nombre de nœuds de cluster nécessaires, afin de garantir le maintien des performances d'une seule requête. La plupart des charges de travail observent une augmentation du débit global de traitement des requêtes dans un entrepôt de Multi-AZ données, car les ressources informatiques disponibles sont deux fois plus nombreuses.

En cas de panne dans une zone de disponibilité, Amazon Redshift continue de fonctionner en utilisant automatiquement les ressources de la zone de disponibilité restante. Toutefois, les connexions des utilisateurs peuvent être perdues et doivent être rétablies. En outre, les requêtes qui s’exécutaient dans la zone de disponibilité en défaillance peuvent échouer et doivent être retentées. Toutefois, vous pouvez vous reconnecter à votre cluster et replanifier les requêtes immédiatement, et Amazon Redshift traitera les requêtes dans la zone de disponibilité restante. Les requêtes émises pendant ou après une panne peuvent subir des retards d'exécution pendant la restauration de l'entrepôt de Multi-AZ données.

Note

Pour obtenir de meilleures performances et une meilleure disponibilité, nous vous recommandons d'utiliser SNAPSHOT ISOLATION avec vos Multi-AZ clusters. Pour plus d’informations, consultez CREATE DATABASE.

Limitations

Un entrepôt de Multi-AZ données possède les mêmes fonctionnalités qu'un entrepôt de Single-AZ données, à l'exception des limitations suivantes qui s'appliquent à un entrepôt de Multi-AZ données :

  • Vous ne pouvez pas créer un entrepôt de Multi-AZ données non chiffré. Assurez-vous d'ajouter un chiffrement lors de la création d'un nouvel entrepôt de Multi-AZ données, de la conversion d'un entrepôt de Single-AZ données en entrepôt de Multi-AZ données ou de la conversion d'un entrepôt de Single-AZ données en entrepôt de Multi-AZ données.

  • Vous ne pouvez pas créer un Multi-AZ déploiement de nœud unique pour aucun type d'instance RG ou RA3. Choisissez 2 nœuds ou plus par zone de disponibilité lors de la création d'un Multi-AZ déploiement.

  • Amazon Redshift ne prend pas en charge une configuration de sous-réseau capable de prendre en charge moins de trois zones de disponibilité. En d’autres termes, le groupe de sous-réseaux configuré nécessite trois sous-réseaux supplémentaires ou plus.

  • Vous ne pouvez pas déplacer un Multi-AZ déploiement vers une autre zone de disponibilité. La relocalisation sera automatiquement déterminée et menée par Amazon Redshift lors de l'utilisation Multi-AZ du déploiement.

  • Vous ne pouvez pas suspendre ou reprendre un Multi-AZ déploiement.

  • Vous ne pouvez pas exécuter votre Multi-AZ déploiement en dehors des plages de ports prises en charge 5431 à 5455 et 8191 à 8215.

  • Vous ne pouvez pas utiliser les vues STL, SVCS, SVL, SVV, STV avec les Multi-AZ déploiements, car elles ne prennent en charge que les vues de surveillance du système (vues SYS_*). Modifiez vos requêtes de surveillance pour utiliser les vues de surveillance du système (vues SYS_*).

  • Vous ne pouvez pas associer une adresse IP élastique à un cluster existant lorsque Multi-AZ cette option est activée.

  • Vous ne pouvez pas convertir un cluster auquel est attachée une adresse IP élastique Single-AZ en Multi-AZ.

  • Le Multi-AZ déploiement d'Amazon Redshift est disponible dans les pays suivants : Régions AWS

    Note

    Les instances RG sont disponibles dans certaines régions. Reportez-vous à la disponibilité des types de nœuds RG dans AWS les régions.

    • USA Est (Ohio) (us-east-2)

    • USA Est (Virginie du Nord) (us-east-1)

    • USA Ouest (Oregon) (us-west-2)

    • Afrique (Le Cap) (af-south-1)

    • Asie-Pacifique (Hong Kong) (ap-east-1)

    • Asie-Pacifique (Taipei) (ap-east-2)

    • Asie-Pacifique (Hyderabad) (ap-south-2)

    • Asie-Pacifique (Jakarta) (ap-southeast-3)

    • Asie-Pacifique (Malaisie) (ap-southeast-5)

    • Asie-Pacifique (Melbourne) (ap-southeast-4)

    • Asie-Pacifique (Mumbai) (ap-south-1)

    • Asie-Pacifique (Osaka) (ap-northeast-3)

    • Asie-Pacifique (Séoul) (ap-northeast-2)

    • Asie-Pacifique (Singapour) (ap-southeast-1)

    • Asie-Pacifique (Sydney) (ap-southeast-2)

    • Asie-Pacifique (Nouvelle Zélande) (ap-southeast-6)

    • Asie-Pacifique (Thaïlande) (ap-southeast-7)

    • Asie-Pacifique (Tokyo) (ap-northeast-1)

    • Canada (Centre) (ca-central-1)

    • Chine (Beijing) cn-north-1

    • Chine (Ningxia) cn-northwest-1

    • Europe (Francfort) (eu-central-1)

    • Europe (Irlande) (eu-west-1)

    • Europe (Londres) (eu-west-2)

    • Europe (Milan) (eu-south-1)

    • Europe (Paris) (eu-west-3)

    • Europe (Espagne) (eu-south-2)

    • Europe (Stockholm) (eu-north-1)

    • Europe (Zurich) (eu-central-2)

    • Israël (Tel Aviv) (il-central-1)

    • Mexique (Centre) (mx-central-1)

    • Moyen-Orient (Bahreïn) (me-south-1)

    • Moyen-Orient (Émirats arabes unis) (me-central-1)

    • Amérique du Sud (São Paulo) (sa-east-1)

    • AWS GovCloud (US-East) (us-gov-east-1)

    • AWS GovCloud (US-West) (US-GOV-West-1)

  • Multi-AZ Les entrepôts de données accessibles au public prennent en charge un groupe de sécurité VPC de moins que Single-AZ les entrepôts accessibles Multi-AZ au privé.