Pourquoi AWS RDS Aurora a-t-il l'option de «déploiement multi-AZ» alors qu'il effectue déjà la réplication sur différentes zones par défaut?
Lors du lancement d'une instance Aurora, j'ai l'option de "Déploiement Multi-AZ", qu'il décrit comme "Spécifie si l'instance DB doit avoir une réserve déployée dans une autre zone de disponibilité".
Cependant, la documentation d'Aurora indique qu'Aurora répartit déjà automatiquement la base de données sur différentes zones de disponibilité?
De plus, quelle est la différence entre une veille Aurora Multi-AZ et une réplique Aurora ordinaire. Est-ce qu'une réplique ordinaire peut être lue à partir d'une augmentation des performances alors qu'une veille ne peut pas être lue?
Aurora réplique vos données sur trois zones de disponibilité, au niveau de la couche de stockage ... mais l'instance du serveur de base de données, elle-même, est toujours une machine virtuelle fonctionnant sur un une seule machine physique située dans une seule zone de disponibilité.
La couche de stockage Aurora se trouve en dehors de cette instance et peut laisser l'accès se poursuivre sans interruption sans perte de données, même en cas de perte de deux AZ maximum, mais la perte de la zone contenant l'instance db entraînera toujours une panne pour vous, si vous n'avez qu'une seule instance Aurora dans votre cluster (1 maître, 0 répliques). La perte d'une zone de disponibilité entière est une de ces choses qui est hautement improbable mais pas impossible. Votre instance db est toujours un point de défaillance unique lorsque vous n'en avez qu'une.
Multi-AZ prend en compte une instance de base de données redondante complète, dans une autre AZ, qui prendra automatiquement le relais pour la principale en une minute, si cela fonctionne comme prévu, en cas de perte de la AZ hébergeant l'instance principale ou d'une catastrophe échec de l'instance principale. C'est une deuxième machine virtuelle, sur une deuxième machine physique, dans une deuxième zone de disponibilité. Il fonctionne toujours, mais vous ne pouvez pas y accéder. Il est en arrière-plan, géré et surveillé par l'infrastructure RDS, mais il n'est accessible qu'à vous en cas de défaillance de l'instance principale. La machine secondaire peut également être utilisée pour réduire les temps d'arrêt en cas de mise à niveau logicielle ou de maintenance sur le serveur principal. Lorsque le basculement se produit, si vous utilisez DNS pour vous connecter à votre base de données (comme vous le devriez), vous constaterez que l'entrée DNS est automatiquement pointée vers le secondaire.
Comparez cela à une réplique de lecture, qui est accessible tout le temps et peut ainsi fournir un avantage significatif en termes de performances, en permettant le déchargement des lectures. Passer à une réplique implique de la promouvoir pour qu'elle devienne un maître autonome (ce qui la détache définitivement de son propre ancien maître) et de reconfigurer votre application pour utiliser l'autre point de terminaison. Bien sûr, cela est encore plus rapide que la récupération après une défaillance du maître en utilisant un instantané ponctuel pour créer une instance principale de remplacement.
Le stockage dans Aurora est répliqué sur trois zones de disponibilité. Le nœud principal de la base de données est une instance unique. Ainsi, alors que vos données sont réparties sur plusieurs cibles, le nœud principal ne l'est pas.
Lorsque vous activez un déploiement multi-AZ, nous créons un réplica en lecture Aurora qui est disponible comme cible de basculement. Toutes les réplicas de lecture Aurora que vous créez (jusqu'à un maximum de 15 pour le moment) sont également disponibles en tant que cibles de basculement.
Il n'y a pas de différence significative entre Multi-AZ et les autres répliques Aurora. Il s'agit principalement d'une simplification de l'interface utilisateur pour les clients habitués à utiliser Multi-AZ pour d'autres moteurs RDS.