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.

Amazon Aurora a recours à une couche de stockage virtualisé SSD conçue spécifiquement pour les charges de travail de base de données. Amazon Aurora réplique automatiquement votre stockage 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. Pour en savoir plus sur la haute disponibilité avec Amazon Aurora, consultez la documentation en ligne.

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.

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.

Les déploiements multi-AZ Amazon RDS complètent les Réplicas en lecture pour Amazon RDS pour MySQL, MariaDB et PostgreSQL. Ces deux fonctionnalités conservent une copie supplémentaire de vos données, mais certaines différences subsistent :

Déploiements multi-AZ Réplicas en lecture
Réplaction synchrone – hautement durable Réplaction asynchrone – hautement évolutive
Seul le moteur de base de données est actif sur l'instance primaire Tous les réplicas en lecture sont accessibles et sont utilisables à des fins de dimensionnement de lecture
Les sauvegardes automatiques sont tirées de leur veille Aucune sauvegarde configurée par défaut
Toujours sur deux zones de disponibilité dans une même région Peut se trouver dans une zone de disponibilité, sur plusieurs zones de disponibilité ou sur plusieurs régions
Des mises à niveau de version de moteur de base de données surviennent sur la primaire Les mises à niveau de version de moteur de base de données sont indépendantes de l'instance source
Basculement automatique pour mettre en veille en cas de détection de problème Promotion manuelle possible vers une instance de base de données autonome

Vous pouvez combiner les déploiements multi-AZ aux réplicas en lecture pour profiter des avantages de chacun. Par exemple, vous pouvez configurer une base de données source sur multi-AZ pour profiter d'une haute disponibilité et créer un réplica en lecture (en zone de disponibilité seule) pour profiter d'un haut dimensionnement en lecture.

Avec RDS pour MySQL et MariaDB, il est également possible de configurer le réplica en lecture sur multi-AZ, ce qui vous permet de l'utiliser comme une cible DR. En cas de promotion du réplica en lecture vers une base de données autonome, ce dernier sera directement configuré sur multi-AZ. Il est à noter que RDS pour PostgreSQL ne prend pas encore en charge cette fonctionnalité.