Déploiements multi-AZ Amazon RDS

Les déploiements multi-AZ pour les moteurs MySQL, MariaDB, Oracle et PostgreSQL utilisent la réplication physique synchrone pour assurer l'actualisation des données de l'instance de secours par rapport à celles de l'instance primaire. Les déploiements multi-AZ pour le moteur SQL Server utilisent la réplication logique synchrone pour aboutir au même résultat à l'aide de la technologie de mise en miroir native SQL Server. Amazon Aurora utilise une couche de stockage virtualisé SSD conçue spécifiquement pour les charges de travail de base de données. Toutes les approches permettent de protéger vos données en cas de défaillance ou de perte sur une instance de base de données d'une zone de disponibilité donnée.

Les déploiements multi-AZ vous permettent de profiter d'une disponibilité accrue pour vos bases de données. Si une défaillance se produit au sein d'une zone de disponibilité (AZ) ou d'une instance de base de données, l'impact sur votre disponibilité est limité à la durée de mise en place du basculement automatique, c'est-à-dire en général moins d'une minute (jusqu'à 30 secondes en cas d'utilisation de MariaDB Connector/J) pour Amazon Aurora. Cette durée est d'une à deux minutes pour les autres moteurs de base de données (consultez la FAQ sur RDS pour plus d'informations).

Les déploiements multi-AZ accroissent également la disponibilité lors des opérations de maintenance planifiée et de sauvegarde. Si le système doit être mis à niveau, notamment en cas d'application de correctif du système d'exploitation ou de dimensionnement de l'instance de base de données, ces opérations sont réalisées d'abord sur l'instance de secours, avant le basculement automatique. En conséquence, l'impact sur votre disponibilité est, ici encore, uniquement limité à la durée de mise en place du basculement.

À la différence des déploiements mono-AZ, les déploiements multi-AZ pour MySQL, MariaDB, Oracle et PostgreSQL permettent de maintenir les opérations d'E/S sur l'instance principale pendant les sauvegardes, dans la mesure où les données sauvegardées sont récupérées depuis l'instance de secours. Cependant, même dans le cadre d'un déploiement multi-AZ, il se peut que vous subissiez des temps de latence élevés pendant quelques minutes au cours des sauvegardes.

En cas de défaillance d'une instance dans les déploiements Amazon Aurora, Amazon RDS utilise la technologie RDS multi-AZ pour automatiser le basculement vers un des 15 réplicas Amazon Aurora que vous avez créés dans chacune des trois zones de disponibilité. Si aucun réplica Amazon Aurora n'a été mis en service, Amazon RDS tentera de créer automatiquement une nouvelle instance DB Amazon Aurora pour vous en cas de défaillance.

Si un volume de stockage sur votre instance principale est défaillant dans un déploiement multi-AZ, Amazon RDS réalise automatiquement un basculement vers le volume de secours à jour (ou vers un réplica pour Amazon Aurora). Cela est comparable à un déploiement mono-AZ : en cas d'échec de la base de données mono-AZ, une opération de restauration-à-un-point-dans-le-temps devra être initiée par l'utilisateur. Cette restauration peut prendre plusieurs heures et toutes les mises à jour de données apportées après la dernière sauvegarde à des fins de restauration (en général, pendant les cinq dernières minutes) sont perdues.

Le basculement des instances de base de données est entièrement automatique et ne nécessite aucune intervention d'un administrateur. Amazon RDS surveille l'état de vos instances principale et de secours et lance automatiquement un basculement pour faire face aux différentes conditions de défaillance.

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 le serveur principal
  

Remarque : pour une meilleure disponibilité, lorsque des opérations telles que le dimensionnement 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 sur des déploiements multi-AZ, elles sont d'abord appliquées au niveau de l'instance de secours avant tout basculement automatique (consultez la documentation sur Aurora pour en savoir plus sur les paramètres de mise à jour). En conséquence, l'impact sur votre disponibilité est uniquement limité à la durée de mise en place du basculement. Notez que les déploiements multi-AZ d'Amazon RDS 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 d'altération de la base de données.