Multi-AZ et sauvegardes automatisées

Multi-AZ est une fonctionnalite de haute disponibilite de RDS qui provisionne automatiquement une replique de secours synchrone dans une zone de disponibilite differente de la meme region. AWS gere la replication de maniere transparente : vous vous connectez a l'aide d'un unique point de terminaison DNS et RDS achemine le trafic vers l'instance principale.

Si l'instance principale echoue en raison de problemes materiels, reseau ou OS, RDS effectue un basculement automatique vers l'instance de secours en environ 60–120 secondes. Votre application se reconnecte a l'aide du meme point de terminaison DNS, qui est alors resolu vers l'adresse IP de l'instance de secours.

Vous pouvez activer Multi-AZ lors de la creation d'une instance RDS ou en modifiant une instance existante. Lors de l'activation sur une instance en cours d'execution, AWS cree un instantane de l'instance principale, le restaure dans une seconde AZ, puis synchronise les donnees a l'aide de la replication native du moteur. Ce processus peut provoquer une breve suspension des E/S sur l'instance principale ; planifiez-le donc pendant une periode de faible trafic ou acceptez le calendrier de la fenetre de maintenance.

Multi-AZ est pris en charge par tous les moteurs RDS, notamment MySQL, PostgreSQL, MariaDB, Oracle et SQL Server, et ne necessite aucune modification au niveau de l'application.

Lorsqu'un basculement se produit, RDS met a jour le CNAME DNS du point de terminaison de la DB afin qu'il pointe vers l'instance de secours dans un delai d'environ 60 secondes. Votre application doit se reconnecter apres avoir detecte une coupure de connexion TCP. Pour reduire les delais de reconnexion :

• Utilisez un TTL DNS court (generalement deja defini a 5 secondes par RDS)
• Implementez un backoff exponentiel avec nouvelles tentatives dans votre logique de connexion
• Utilisez des outils de regroupement de connexions tels que RDS Proxy, qui se reconnectent automatiquement

Le basculement est egalement declenche manuellement pour la maintenance ou les changements de classe d'instance, ce qui permet des mises a niveau avec une interruption presque nulle lorsque Multi-AZ est active.

Une confusion frequente lors des examens concerne Multi-AZ (pour la disponibilite) et les repliques de lecture (pour l'evolutivite). Principales differences :

• Instance de secours Multi-AZ : replication synchrone, aucun trafic de lecture traite, basculement automatique, meme region
• Replique de lecture : replication asynchrone, traite le trafic de lecture, aucun basculement automatique, peut etre interregionale

Multi-AZ n'ameliore pas les performances de lecture : l'instance de secours est inaccessible pour les requetes. Pour ameliorer a la fois la disponibilite ET mettre les lectures a l'echelle, utilisez Multi-AZ sur l'instance principale et ajoutez separement des repliques de lecture.

RDS cree automatiquement chaque jour des instantanes complets de base de donnees et capture les journaux de transactions toutes les 5 minutes. Ensemble, ces elements permettent une recuperation a un instant donne (PITR) a n'importe quelle seconde comprise dans la periode de conservation des sauvegardes. Vous pouvez restaurer la base de donnees dans l'etat ou elle se trouvait a n'importe quel moment de cette periode.

Les sauvegardes automatisees sont activees par defaut et peuvent etre conservees pendant 1 a 35 jours. Definir la conservation a 0 desactive les sauvegardes automatisees (ainsi que PITR). La fenetre de sauvegarde est une periode de 30 minutes que vous specifiez ou que vous laissez AWS choisir pendant les heures creuses.

La fenêtre de sauvegarde correspond à la période durant laquelle les instantanés quotidiens sont effectués. Durant cette période, les opérations d’E/S du stockage peuvent être brièvement interrompues dans les déploiements Single-AZ. Les déploiements Multi-AZ prennent l’instantané depuis l’instance de secours, ce qui élimine l’impact sur les opérations d’E/S de l’instance principale.

La fenêtre de maintenance est une période hebdomadaire distincte durant laquelle AWS applique les correctifs du système d’exploitation, les mises à niveau mineures du moteur et les modifications de l’instance. La bonne pratique consiste à définir les deux fenêtres pendant des périodes de faible trafic et à veiller à ce qu’elles ne se chevauchent pas.

Pour effectuer une restauration à un instant précis, RDS restaure d’abord l’instantané quotidien le plus récent, puis rejoue les journaux des transactions jusqu’à l’horodatage demandé. Le résultat est une nouvelle instance DB : PITR ne remplace jamais l’instance source, ce qui vous offre une procédure de récupération sûre sans interrompre la production.

Une fois l’instance restaurée disponible, vous mettez à jour la chaîne de connexion de votre application afin qu’elle pointe vers le nouveau point de terminaison, vous vérifiez l’intégrité des données, puis vous supprimez l’instance d’origine si la récupération était intentionnelle. La durée habituelle de la restauration est proportionnelle à la taille de la base de données et au volume des journaux depuis le dernier instantané.

En plus des sauvegardes automatisées, vous pouvez prendre des instantanés manuels à tout moment. Contrairement aux sauvegardes automatisées, les instantanés manuels ne sont pas soumis à la période de rétention : ils sont conservés jusqu’à ce que vous les supprimiez explicitement.

Les instantanés manuels sont idéaux pour capturer l’état de la base avant une migration majeure du schéma, une mise à niveau de l’application ou à la fin d’un cycle de facturation à des fins d’archivage réglementaire. Vous pouvez également partager des instantanés manuels avec d’autres comptes AWS ou les copier entre des Régions à des fins de reprise après sinistre.

Vous pouvez copier des instantanés automatisés ou manuels vers une autre Région AWS à des fins de reprise après sinistre. La copie est un instantané complet stocké dans l’infrastructure S3 de la Région de destination. Une fois la copie effectuée, vous pouvez restaurer une nouvelle instance RDS dans cette Région si votre Région principale devient indisponible.

Les copies d’instantanés peuvent être chiffrées dans la destination même si la source ne l’est pas, et inversement. Les copies entre Régions entraînent des coûts de transfert de données. Utilisez AWS Backup ou une fonction Lambda déclenchée par EventBridge pour automatiser les copies périodiques d’instantanés entre Régions.

Amazon RDS Proxy se place entre votre application et RDS et regroupe les connexions à la base de données dans un pool. Cette fonctionnalité est particulièrement utile pour les fonctions Lambda qui peuvent ouvrir des milliers de connexions de courte durée et épuiser la limite de connexions de la base de données. RDS Proxy multiplexe les connexions afin que la base de données voie beaucoup moins de connexions actives.

Lors d’un basculement Multi-AZ, RDS Proxy conserve les connexions de l’application et rétablit la connexion à la base de données avec la nouvelle instance principale, réduisant ainsi le temps de reconnexion de l’application à quelques secondes au lieu de plusieurs minutes. RDS Proxy s’intègre également à Secrets Manager pour faire tourner les informations d’identification sans interruption de l’application.

RDS propose désormais deux options Multi-AZ : instance DB Multi-AZ (classique, avec une instance de secours) et cluster DB Multi-AZ (deux instances de secours accessibles en lecture dans des AZ différentes). Le mode cluster utilise une réplication semi-synchrone et autorise le trafic de lecture sur les instances de secours, offrant une disponibilité et une capacité de lecture supérieures sans Read Replicas distinctes.

Pour l’examen SAA-C03, l’instance DB Multi-AZ classique est la plus souvent évaluée. Retenez que le cluster Multi-AZ est l’option la plus récente, dont les instances de secours peuvent traiter des lectures, contrairement à l’instance de secours classique.

Vérifiez votre compréhension des concepts AWS Solutions Architect (SAA-C03) présentés dans cette leçon.

Dans cette leçon, vous avez appris que Multi-AZ fournit une réplication synchrone vers une instance de secours avec basculement automatique en 60 à 120 secondes, que les sauvegardes automatisées permettent PITR à n’importe quelle seconde pendant la période de rétention (1 à 35 jours), et que les instantanés manuels sont conservés indéfiniment et peuvent être copiés entre des Régions à des fins de DR. Nous allons maintenant étudier les Read Replicas pour distribuer le trafic de lecture et améliorer le débit de lecture.