Un déploiement multi-AZ contribue-t-il à réduire les temps d'arrêt lors d'une modification d'Amazon RDS MySQL ?

Brève description

Lorsque vous modifiez votre instance Amazon RDS MySQL, un déploiement multi-AZ peut réduire l'impact de vos modifications.

Un déploiement multi-AZ peut avoir un impact sur votre instance Amazon RDS MySQL dans les scénarios suivants :

• Modification du stockage de l'instance de base de données
• Mise à jour de la classe d'instance de base de données
• Maintenance du système d'exploitation ou du matériel sous-jacent

Remarque : selon le type de mise à jour que vous effectuez, il est possible que les déploiements multi-AZ n’améliorent pas la disponibilité.

Solution

Modification du stockage de l'instance de base de données

Voici les modifications de stockage Amazon RDS disponibles :

• Volume de stockage alloué
• Valeur des IOPS provisionnés
• Type de stockage

L'augmentation du volume de stockage alloué et la modification des valeurs d'IOPS sont des opérations en ligne qui n'incluent pas de temps d'arrêt. Étant donné que ces mises à jour de stockage sur l'instance de base de données principale et de secours se produisent en même temps, le déploiement multi-AZ n'améliore pas la disponibilité. Pour plus d'informations sur les modifications du stockage et les temps d'arrêt potentiels, consultez la section Paramètres des instances de base de données.

Il n'y a pas non plus de temps d'arrêt lorsque vous modifiez le type de stockage d'une instance de base de données multi-AZ, entre General Purpose (SSD) (Usage général (SSD)) et Provisioned IOPS (SSD) (IOPS provisionnés (SSD)). Toutefois, il y a un temps d'arrêt dans les scénarios suivants :

• De General Purpose (SSD) à Magnetic, ou de Magnetic à General Purpose (SSD).
• De Provisioned IOPS (SSD) à Magnetic, ou de Magnetic à Provisioned IOPS (SSD).
• De General Purpose (SSD) à Provisioned IOPS (SSD), mais uniquement si l'instance de base de données est Single-AZ et que vous utilisez un groupe de paramètres personnalisés.
• De Provisioned IOPS (SSD) à General Purpose (SSD), mais uniquement si l'instance de base de données est Single-AZ et que vous utilisez un groupe de paramètres personnalisés.

Mise à jour de la classe d'instance de base de données

Étant donné qu'un changement de classe d'instance nécessite du nouveau matériel, ce changement n'est pas une opération en ligne et nécessite donc un temps d'arrêt. Un déploiement multi-AZ d'une instance de base de données Amazon RDS pour MySQL peut réduire considérablement l'impact. En effet, la mise à jour ne se produit pas simultanément sur l'instance principale et l'instance de secours. L'instance de secours est d'abord modifiée, ce qui entraîne un basculement. Après le basculement, la nouvelle instance de secours est modifiée. Le temps d'arrêt nécessaire comprend la durée d'achèvement d'un basculement (généralement de 60 à 120 secondes) et l'achèvement de la récupération après défaillance du moteur de base de données. Pour plus d'informations, consultez la section Déploiements multi-AZ.

Mise à niveau de la version du moteur de base de données

Une mise à niveau de la version du moteur de base de données peut être planifiée manuellement via la console RDS ou l'API. Autre possibilité : la mise à niveau du moteur de base de données est déclenchée via une mise à niveau automatique de la version mineure ou après une dépréciation du moteur. Étant donné que RDS MySQL n'automatise pas les mises à niveau progressives, la mise à niveau du moteur de base de données a lieu sur les hôtes principaux, mais aussi les hôtes de secours. Par conséquent, la mise à niveau du moteur de base de données ne bénéficie pas d'un déploiement multi-AZ. Pour évaluer l'étendue et la durée de l'impact, effectuez d’abord la mise à niveau dans un environnement intermédiaire. Pour plus d'informations, consultez la section Bonnes pratiques de mise à niveau d'Amazon RDS for MySQL et Amazon RDS for MariaDB.

Remarque : si votre instance de base de données RDS MySQL utilise des réplicas en lecture, mettez à niveau tous les réplicas en lecture avant l'instance source. Pour plus d'informations, consultez la section Utilisation d'un réplica en lecture pour réduire les temps d'arrêt lors de la mise à niveau d'une base de données MySQL.

Effectuer une maintenance programmée du système d'exploitation ou du matériel

Si vous travaillez pendant une maintenance planifiée du système d'exploitation ou du matériel, le déploiement multi-AZ peut réduire considérablement l'impact de ces changements.

Voici l’impact que peut avoir le déploiement multi-AZ sur une maintenance planifiée :

• Lorsque la maintenance est planifiée uniquement pour l'hôte principal, un basculement se produit et la maintenance est effectuée sur le nouvel hôte secondaire.
• Lorsque la maintenance est planifiée uniquement pour l'hôte secondaire, il n'y a pas de temps d'arrêt.
• Lorsque la maintenance est planifiée pour l’hôte principal et l’hôte secondaire, elle est d'abord effectuée sur l'hôte secondaire, puis sur le nouvel hôte secondaire après un basculement.

Pour plus d'informations, consultez la section Comment réduire les temps d'arrêt pendant une maintenance RDS obligatoire ?