Déploiements multi-AZ Amazon RDS

Amazon RDS Multi-AZ est disponible pour RDS for PostgreSQL, RDS for MySQL, RDS for MariaDB, RDS for SQL Server, RDS for Oracle et RDS for Db2. Amazon RDS Multi-AZ avec deux instances de secours accessibles en lecture est disponible pour RDS for PostgreSQL et RDS for MySQL. Pour savoir comment Amazon Aurora améliore la disponibilité en rendant vos données durables dans trois zones de disponibilité, consultez Déploiements multi-AZ avec les réplicas Aurora.

Pour les déploiements mono-AZ, les déploiement multi-AZ avec une instance de secours ou avec deux instances de secours accessibles en lecture, la tarification est calculée par heure d'instance de base de données consommée, à partir du lancement d'une instance de base de données jusqu'à son arrêt ou sa suppression. Les heures d'instance de base de données partielles sont facturées par incréments d'une seconde, avec un minimum facturable de 10 minutes, après un changement de statut facturable, tel que la création, le démarrage ou la modification de la classe d'instance de base de données.

Pour plus d'informations sur la tarification d'Amazon RDS Multi-AZ, consultez les pages de tarification d'Amazon RDS.

Les guides d'utilisation et tutoriels suivants vous permettront de démarrer rapidement avec Amazon RDS Multi-AZ.

Regardez des sessions, des webinaires et d'autres vidéos pour en savoir plus sur Amazon RDS Multi-AZ.

Découvrez les dernières améliorations apportées à Amazon RDS Multi-AZ et découvrez en détail comment vous pouvez l'utiliser pour vos cas d'utilisation d'Amazon RDS. 

ProxySQL permet d'obtenir un temps d'arrêt d'une seconde ou moins lors de la mise à niveau de déploiements Amazon RDS Multi-AZ avec deux instances de secours accessibles en lecture

Basculements rapides avec PGBouncer sur les déploiements Amazon RDS Multi-AZ avec deux instances de secours accessibles en lecture pour PostgreSQL

Bénéficiez d'une interruption d'une seconde ou moins grâce au pilote Advanced JDBC Wrapper lors de la mise à niveau des clusters de bases de données Amazon RDS Multi-AZ

Effectuez des mises à niveau mineures avec un temps d'arrêt d'une seconde ou moins grâce aux déploiements Proxy Amazon RDS et Amazon RDS Multi-AZ avec deux instances de secours accessibles en lecture

Consolidation des données pour les applications analytiques à l'aide de la réplication logique pour les clusters Amazon RDS Multi-AZ

Meilleures stratégies pour atteindre des performances et une disponibilité élevées sur Amazon RDS for MySQL avec des clusters de bases de données multi-AZ

Améliorez les performances des applications sur Amazon RDS for MySQL et sur les instances MariaDB et les clusters de bases de données MySQL Multi-AZ grâce à des écritures optimisées

Choisissez la bonne option de déploiement Amazon RDS : instance mono-AZ, instance multi-AZ ou cluster de bases de données multi-AZ

Configurez Multi-AZ avec Amazon RDS Custom pour SQL Server

Déployez un cluster de bases de données Amazon RDS for PostgreSQL et MySQL Multi-AZ à l'aide des modules Terraform

Nouvelle option de déploiement multi-AZ d'Amazon RDS for MySQL et PostgreSQL : performances d'écriture améliorées et basculement plus rapide

Lorsque vous créez ou modifiez votre instance DB afin qu'elle soit exécutée en tant que déploiement Multi-AZ, Amazon RDS met en service et maintient automatiquement un réplica « de secours » synchrone dans une zone de disponibilité différente. Les mises à jour vers votre instance DB sont répliquées de manière synchrone sur les zones de disponibilité vers l'instance de secours, afin qu'elles restent toutes deux synchronisées et qu'elles protègent vos dernières mises à jour de base de données contre une défaillance d'instance DB.

Pendant certains types de maintenance planifiée ou dans le cas improbable d'une défaillance d'instance DB ou de zone de disponibilité, Amazon RDS basculera automatiquement vers l'instance de secours, afin que vous puissiez continuer les écritures et lectures vers la base de données dès que l'instance de secours est activée. Étant donné que l'enregistrement de nom pour votre instance de base de données reste le même, votre application peut reprendre les opérations de base de données sans qu'une intervention manuelle d'administration soit nécessaire. Dans le cas des déploiements multi-AZ, la réplication est transparente. Vous n'interagissez pas directement avec l'instance de secours, et elle ne prend pas en charge le trafic de lecture. Pour en savoir plus sur les déploiements multi-AZ, consultez le Guide de l'utilisateur Amazon RDS.

Les zones de disponibilité sont des emplacements distincts dans une région, conçues pour être isolées des défaillances dans d'autres zones de disponibilité. Chaque zone de disponibilité exécute sa propre infrastructure indépendante et physiquement distincte et est conçue pour être hautement fiable. Les points de défaillance uniques, tels que les générateurs et les équipements de refroidissement, ne sont pas partagés entre les zones de disponibilité. En outre, ils sont physiquement séparés. Ainsi même un sinistre extrêmement rare, comme un incendie, une tempête ou une inondation, n'affecterait qu'une seule zone de disponibilité. Les zones de disponibilité dans la même région bénéficient d'une connectivité réseau avec une faible latence.

Lorsque vous exécutez une instance DB en tant que déploiement Multi-AZ, l'instance « principale » sert les écritures et lectures de base de données. En outre, Amazon RDS prévoit et maintient une instance de « secours » en arrière-plan, qui est un réplica à jour de l'instance principale. L'instance de secours est « promue » en cas de scénario de basculement. Après le basculement, l'instance secours devient l'instance principale et accepte vos opérations de base de données. Vous n'interagissez pas directement avec l'instance de secours (par ex. pour les opérations en lecture) à un moment quelconque avant la promotion. Si vous souhaitez mettre à l'échelle vos capacités de trafic en lecture au-delà des contraintes liées à une instance de base de données unique, consultez les questions fréquentes (FAQ) sur les réplicas en lecture.

Les avantages principaux de l'exécution de votre instance DB en tant que déploiement Multi-AZ sont une durabilité et une disponibilité de la base de données améliorées. La disponibilité améliorée et la tolérance de panne offertes par les déploiements Multi-AZ en font le choix naturel pour les environnements de production.

En exécutant votre instance DB sous forme de déploiement Multi-AZ, vos données sont protégées dans le cas, peu probable, d'une défaillance d'un composant d'une instance DB ou d'une perte de disponibilité dans une zone de disponibilité. Par exemple, si un volume de stockage sur l'instance principale connaît une défaillance, Amazon RDS déclenche automatiquement un basculement vers l'instance de secours, où toutes vos mises à jour de base de données sont intactes. Ceci fournit une durabilité des données supplémentaire relativement aux déploiements standards dans une seule AZ, où une opération de restauration lancée par un utilisateur serait requise et les mises à jour qui ont eu lieu après le dernier moment restaurable (en général dans les cinq dernières minutes) ne seraient pas disponibles.

Vous profitez également d'une disponibilité de base de données améliorée lorsque votre instance DB est exécutée en tant que déploiement Multi-AZ. Si une défaillance de zone de disponibilité ou d'instance DB se produit, l'impact sur votre disponibilité est limité à la durée de mise en place du basculement. Les avantages de la disponibilité Multi-AZ s'étendent également jusqu'à la maintenance planifiée.

Par exemple, avec les sauvegardes automatisées, l'activité I/O n'est plus suspendue sur votre instance principale pendant votre fenêtre de sauvegarde préférée, car les sauvegardes sont effectuées depuis l'instance de secours. Dans le cas d'une application de correctifs ou d'une mise à l'échelle de classe d'instance de base de données, ces opérations ont lieu tout d'abord sur l'instance de secours, avant le basculement automatique. En conséquence, l'impact sur votre disponibilité est limité à la durée d'exécution du basculement automatique.

Un autre avantage implicite d'exécuter votre instance DB en tant que déploiement Multi-AZ est le fait que le basculement d'instance DB est automatique et ne nécessite pas d'administration. Dans un contexte Amazon RDS, ceci signifie que vous n'avez pas besoin de surveiller les événements d'instance DB et de lancer une récupération d'instance DB manuelle (via les API RestoreDBInstanceToPointInTime ou RestoreDBInstanceFromSnapshot) en cas de défaillance de zone de disponibilité ou d'instance DB.
 

Vous pouvez observer des temps de latence élevés par rapport à un déploiement d'instance DB standard dans une seule zone de disponibilité, du fait de la réplication synchrone des données qui est réalisée.

Afin de créer un déploiement d'instance de base de données multi-AZ, il suffit de cliquer sur l'option « Oui » pour un « déploiement multi-AZ » lors du lancement d'une instance de base de données avec la console de gestion AWS.

De manière alternative, si vous utilisez les API Amazon RDS, vous appelez l'API CreateDBInstance et définissez le paramètre « Multi-AZ » sur la valeur « true ». Pour convertir une instance de base de données standard existante (Mono-AZ) en Multi-AZ, modifiez l'instance de base de données dans la console de gestion AWS ou utilisez l'API ModifyDBInstance et définissez le paramètre Multi-AZ sur « true ».
 

Pour les moteurs de base de données RDS for PostgreSQL, RDS for MySQL, RDS for MariaDB, RDS for SQL Server, RDS for Oracle et RDS for Db2, lorsque vous décidez de convertir votre instance Amazon RDS de mono-AZ en instance multi-AZ, voici ce qui se passe :

• Création d'un instantané de votre instance principale.
• Une nouvelle instance de secours est créée dans une autre zone de disponibilité (AZ) à partir de l'instantané.
• Une réplication synchronisée est configurée entre l'instance principale et l'instance de secours.
  

Ainsi, la conversion d'une instance du Mono-AZ vers le Multi-AZ ne devrait pas provoquer de perturbations. Vous pouvez toutefois constater une latence accrue tandis que les données en attente sont interceptées pour la correspondance avec le serveur principal.

Pour les déploiements multi-AZ, Amazon RDS assure une détection et une récupération automatique dans la plupart des scénarios de défaillance courants afin que vous puissiez reprendre les opérations de base de données aussi rapidement que possible et sans intervention d'un administrateur. Amazon RDS procède automatiquement au basculement dès lors qu'un des événements suivants se produit :

• Perte de disponibilité dans la zone de disponibilité principale
• Perte de connectivité réseau avec le serveur principal
• Échec d'unité de calcul sur le serveur principal
• Échec de stockage sur l'instance principale

Remarque : pour une meilleure disponibilité, lorsque des opérations telles que la mise à l'échelle d'une instance de base de données ou la réalisation de mises à niveau système (application de correctifs sur le système d'exploitation, par exemple) sont lancées pour des déploiements multi-AZ, elles sont d'abord appliquées au niveau de l'instance de secours avant tout basculement automatique. En conséquence, l'impact sur votre disponibilité est uniquement limité à la durée d'exécution du basculement automatique. Notez que les déploiements Amazon RDS Multi-AZ ne basculent pas automatiquement en cas d'opérations de bases de données, telles que les requêtes à exécution prolongée, les verrous bloquants ou les erreurs de corruption de la base de données.

Oui, Amazon RDS émettra un événement d'instance DB vous informant qu'un basculement automatique a eu lieu. Vous pouvez cliquer sur la section « Events » d'Amazon RDS Console ou utiliser l'API DescribeEvents pour renvoyer des informations sur des événements liés à votre instance DB. Vous pouvez également utiliser la notification d'événement Amazon RDS pour être informé quand des événements de base de données particuliers se produisent.

Le basculement est automatiquement traité par Amazon RDS afin que vous puissiez reprendre vos opérations de base de données aussi vite que possible sans intervention administrative. Lors du basculement, Amazon RDS retourne simplement l'enregistrement de nom canonique (CNAME) de votre instance DB pour pointer vers l'instance de secours, qui est promue à son tour pour devenir la nouvelle instance principale. Nous vous encourageons à suivre les bonnes pratiques et à implémenter une nouvelle tentative de connexion de base de données au niveau de la couche d'application.

Les basculements, tels que définis par l'intervalle entre la détection de la défaillance dans l'instance primaire et la reprise des transactions dans l'instance de secours, s'effectuent généralement en une ou deux minutes. La durée du basculement peut également être affectée par la nécessité de restaurer de grandes transactions non validées. Il est recommandé d'utiliser des types d'instances au volume approprié avec multi-AZ pour obtenir les meilleurs résultats. AWS recommande également d'utiliser les volumes IOPS provisionnés avec les instances multi-AZ pour obtenir des performances de débit rapides, prévisibles et homogènes.

Amazon RDS procède au basculement automatique, sans aucune intervention de l'utilisateur, dans diverses conditions de pannes. En outre, Amazon RDS offre une option permettant de lancer un basculement lors du redémarrage de votre instance. Vous pouvez accéder à cette fonctionnalité via la Console de gestion AWS ou en appelant l'API RebootDBInstance.

Avec les déploiements Multi-AZ, vous définissez simplement le paramètre « Multi-AZ » sur vrai. La création de l'instance de secours, de la réplication synchrone et du basculement est traitée automatiquement. Ceci signifie que vous ne pouvez pas sélectionner la zone de disponibilité lorsque votre instance de secours est déployée ou modifier le nombre d'instances de secours disponibles (Amazon RDS met en service une instance de secours dédiée par instance DB principale). Par ailleurs, le réplica de secours ne peut pas être configuré pour accepter des activités en lecture de base de données. En savoir plus sur les configurations Multi-AZ.

Oui. Votre instance de secours est mise automatiquement en service dans une zone de disponibilité différente de la même région comme votre instance DB principale.

Oui, vous pouvez avoir accès à l'emplacement de l'instance principale actuelle en utilisant la Console de gestion AWS ou l'API DescribeDBInstances.

Les zones de disponibilité sont conçues pour fournir une connectivité réseau à faible latence vers les autres zones de disponibilité de la même région. En outre, vous pourriez envisager d'avoir une architecture avec redondance pour votre application et d'autres ressources AWS parmi des zones de disponibilité multiples, afin que votre application soit résiliente en cas de défaillance d'une zone de disponibilité. Les déploiements Multi-AZ répondent à ce besoin pour le niveau de base de données sans administration de votre part.

Vous interagissez avec la fonctionnalité de sauvegarde automatisée et les instantanés DB de la même manière, que vous exécutiez un déploiement standard mono-AZ ou un déploiement multi-AZ. Si vous exécutez un déploiement Multi-AZ, les sauvegardes automatisées et les instantanés DB sont simplement pris à partir de l'instance de secours, afin d'éviter la suspension d'E/S sur l'instance principale. Notez qu'il est possible de constater un temps de latence accru en E/S (généralement quelques minutes) lors des sauvegardes, à la fois pour les déploiements mono-AZ et multi-AZ.

Dans les déploiements multi-AZ, les opérations de restauration (restauration à un moment donné ou restauration à partir d'un instantané DB) fonctionnent de la même manière que dans les déploiements mono-AZ standard. Les nouveaux déploiements d'instance DB peuvent être créés avec l'API RestoreDBInstanceFromSnapshot ou RestoreDBInstanceToPointInTime. Ces nouveaux déploiements d'instance DB peuvent être standards ou multi-AZ, que la sauvegarde source ait été lancée sur un déploiement standard ou multi-AZ.