Les déploiements multi-AZ Amazon RDS fournissent une disponibilité et une durabilité accrues pour les instances de base de données (DB), ce qui les rend particulièrement adaptés pour les charges de travail des bases de données en production. Lorsque vous mettez en service une instance DB multi-AZ, Amazon RDS crée automatiquement une instance DB principale et réplique les données de manière synchrone sur une instance de secours située dans une autre zone de disponibilité ou AZ (Availability Zone, en anglais). Chaque AZ exécute sa propre infrastructure indépendante et physiquement distincte et est conçue pour être hautement fiable. En cas de défaillance de l'infrastructure, Amazon RDS exécute un basculement automatique vers l'instance de secours (ou vers une réplica en lecture pour Amazon Aurora), de façon à pouvoir reprendre les opérations de base de données dès la fin du basculement. Etant donné que le point de terminaison de votre instance DB reste le même après le basculement, votre application peut reprendre les opérations de base de données sans qu'il soit nécessaire qu'un administrateur intervienne manuellement.

ha_ed_grizzly_reg_database_orange
3:01
Converting an Amazon RDS Instance to Multi-AZ

Démarrez avec AWS avec notre offre gratuite

Créer un compte gratuit

Le niveau gratuit d'AWS inclut 750 heures d'exécution d'une instance DB Micro chaque mois durant un an, 20 Go de stockage et 20 Go de sauvegardes avec Amazon Relational Database Service (RDS).

Voir les détails relatifs au niveau gratuit d'AWS »

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 de SQL Server. Ces deux approches permettent de protéger vos données en cas de défaillance ou de perte sur une instance DB d'une zone de disponibilité donnée.

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

Amazon Aurora utilise une layer de stockage virtualisé SSD, hautement durable et conçue pour les charges de travail de base de données. Amazon Aurora réplique automatiquement votre volume six fois dans trois zones de disponibilité. Le stockage Amazon Aurora est tolérant aux pannes. Il peut supporter la perte de deux copies de données sans affecter la disponibilité en écriture de la base de données, et celle de trois copies sans affecter la disponibilité en lecture. Le stockage Amazon Aurora est également doté d'un mécanisme d'autoréparation. Le système analyse les blocs de données et les disques en continu pour détecter toute erreur éventuelle, et les remplace si besoin.

Les déploiements multi-AZ vous permettent aussi 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 DB, l'impact sur votre disponibilité est limité à la durée de mise en place du failover (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, et 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 DB, 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.

A 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'I/O 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, en cas de défaillance, Amazon RDS tentera de créer automatiquement une nouvelle instance DB Amazon Aurora pour vous.

Le basculement des instances DB 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 DB ou la réalisation de mises à niveau système (application de correctifs sur le SE, 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.

Veuillez consulter la page des tarifs Amazon RDS pour plus d'informations.

Vous pouvez facilement créer des déploiements multi-AZ ou transformer des instances mono-AZ en déploiements multi-AZ à partir d'AWS Management Console. Pour créer un déploiement multi-AZ dans AWS Management Console, sélectionnez simplement l'option « Yes » pour « Multi-AZ Deployment » au moment de lancer une instance DB. Pour convertir une instance DB mono-AZ existante en déploiement multi-AZ, utilisez l'option « Modify » correpondant à cette instance DB dans AWS Management Console.

Amazon RDS pour MySQL et PostgreSQL vous permettent d'utiliser la réplication intégrée de ces moteurs avec les réplicas en lecture pour dimensionner au-delà des limites de capacité d'une seule instance DB pour les charges de travail de base de données à lecture intensive. Vous pouvez utiliser les déploiements multi-AZ conjointement avec les réplicas en lecture pour profiter des avantages complémentaires de chacun. Il vous suffit de désigner un déploiement multi-AZ donné en tant qu'instance DB source de vos réplicas en lecture. De cette manière vous bénéficiez de la disponibilité et de la durabilité des données des déploiements Multi-AZ et du dimensionnement en lecture des réplicas en lecture.

En cas de déploiement multi-AZ, vous avez également la possibilité de créer votre réplica en lecture au sein d'une zone de disponibilité différente de celle de vos instances principale et de secours, pour une redondance supérieure. Pour identifier la zone de disponibilité de votre instance de secours, référez-vous au champ « Secondary Zone » de votre instance DB dans AWS Management Console.