Que se passe-t-il lorsque je change mon instance de base de données RDS d'un déploiement mono-AZ à un déploiement multi-AZ ou d'un déploiement multi-AZ à un déploiement mono-AZ ?

Résolution

Choisir le type de déploiement adapté à votre cas d'utilisation

Avant de modifier votre type de déploiement, examinez les différences suivantes entre les déploiements multi-AZ et mono-AZ :

• Une configuration mono-AZ déploie une instance de base de données RDS et des volumes de stockage Amazon Elastic Block Store (Amazon EBS) dans une seule zone de disponibilité.
• Une configuration multi-AZ déploie une instance et des volumes de stockage EBS dans deux zones de disponibilité.
• Lorsque vous utilisez le déploiement multi-AZ, Amazon RDS conserve une copie de secours de vos données. Amazon RDS détecte des défaillances de l'infrastructure, puis s’en rétablit automatiquement afin que vous puissiez reprendre rapidement les opérations de base de données.
• Lorsque vous utilisez un déploiement mono-AZ, vous devrez peut-être lancer une opération de reprise ponctuelle (PITR) lors d'une panne planifiée ou non planifiée. Une opération PITR peut prendre plusieurs heures. Les mises à jour des données qui se produisent après la dernière heure de restauration ne sont pas disponibles. Vous risquez donc de subir une durée d’indisponibilité supplémentaire.
• Pour un déploiement multi-AZ, Amazon RDS crée des instantanés de base de données et des sauvegardes automatisées à partir de l'instance secondaire pendant la fenêtre de sauvegarde automatique. Le processus de sauvegarde ne suspend pas l'activité I/O sur votre instance principale car Amazon RDS sélectionne la sauvegarde depuis l'instance secondaire pour les moteurs de base de données Amazon RDS for MariaDB, Amazon RDS for MySQL, Amazon RDS pour Oracle et Amazon RDS pour PostgreSQL. Pour Amazon RDS pour SQL Server, le processus de sauvegarde suspend brièvement l'activité I/O.
• Dans un déploiement mono-AZ, le processus de sauvegarde entraîne une brève suspension des I/O qui peut durer de quelques secondes à quelques minutes. La durée dépend de la taille et de la classe de votre instance.
• Pour les déploiements multi-AZ, Amazon RDS applique d’abord les opérations de maintenance et de mise à l’échelle du système d'exploitation à l'instance secondaire. Amazon RDS promeut l'instance secondaire à l'instance principale, puis effectue une maintenance ou des modifications sur l'ancienne instance principale. L'ancienne instance principale devient la nouvelle instance de secours. La durée d’indisponibilité est donc minime lors de l’application de certains correctifs du système d'exploitation ou de certaines opérations de mise à l’échelle.
• Une instance mono-AZ n'est pas disponible lors d'une opération de mise à l’échelle.

Remarque : Aucune durée d’indisponibilité n’est observée sur l'instance lorsque vous passez d'un type de déploiement à un autre.

Modifier votre type de déploiement de multi-AZ à mono-AZ

Modifiez votre type de déploiement.

Lorsque vous faites passer votre instance d'un déploiement multi-AZ à un déploiement mono-AZ, Amazon RDS supprime uniquement l'instance secondaire et les volumes. La modification n'affecte pas l'instance principale.

Modifier votre type de déploiement de mono-AZ à multi-AZ

Modifiez votre type de déploiement.

Lorsque vous faites passer votre instance d'un déploiement mono-AZ à un déploiement multi-AZ, Amazon RDS crée un instantané des volumes de l'instance. Amazon RDS utilise l’instantané pour créer de nouveaux volumes dans une autre zone de disponibilité. Les nouveaux volumes sont immédiatement disponibles.

Cependant, il se peut que vous subissiez une période de latence d'écriture accrue pendant et après le processus de modification en raison du chargement différé. Cela se produit car l'instance charge les données du nouveau volume depuis Amazon Simple Storage Service (Amazon S3) en arrière-plan. Pour plus d'informations, consultez la section Restauration vers une instance de base de données.

Le temps de latence observé dépend du type de volume, de la charge de travail, de l'instance et de la taille du volume. Par conséquent, il est recommandé de modifier une instance de test avant de modifier l'instance de production. Il est également recommandé de modifier l'instance dans une fenêtre de maintenance ou à faible débit.

Pour réduire la durée de chargement et la latence d'écriture, procédez comme suit :

1. Modifiez le type de stockage de l'instance en opérations d'entrée/sortie provisionnées par seconde (IOPS). Provisionnez une quantité d'IOPS bien supérieure à celle requise par votre charge de travail.
   Remarque : Si l'instance utilise un groupe de paramètres personnalisés, une durée d’indisponibilité peut survenir lorsque vous modifiez le type de stockage.
2. Si vous n'avez pas changé de type de déploiement, modifiez l'instance à un déploiement multi-AZ.
3. Initiez un basculement sur votre instance pour vous assurer que la nouvelle zone de disponibilité est la zone de disponibilité principale.
4. Exécutez un vidage complet des données de votre instance. Vous pouvez également exécuter des requêtes d'analyse complète des tables les plus actives pour charger rapidement les données dans les volumes.
5. Consultez la métrique WriteLatency dans Amazon CloudWatch pour vous assurer que la latence d'écriture revient à des niveaux normaux.
6. Revenez au type de stockage ou aux IOPS de l'instance par rapport à votre configuration précédente.
   Remarque : Aucune durée d’indisponibilité n’est observée lorsque vous changez de nouveau le type de stockage.

Lorsque vous faites passer une instance d'un déploiement mono-AZ à un déploiement multi-AZ, Amazon RDS crée une instance de secours avec la même configuration dans une autre zone de disponibilité. L'instance de secours peut entraîner des coûts supplémentaires. De plus, étant donné qu'un déploiement multi-AZ utilise la réplication synchrone, les écritures sont légèrement plus lentes que celles d'un déploiement mono-AZ.

Informations connexes

Amazon RDS Multi-AZ