Quels facteurs peuvent avoir un impact sur mes temps d'arrêt ou les performances de ma base de données dans Amazon RDS ?

Solution

Modification d'une classe d'instance dans Amazon RDS

Lorsque vous modifiez la classe d'instance d'une instance mono-AZ dans Amazon RDS, un nouvel hôte Amazon Elastic Compute Cloud (Amazon EC2) est créé. Une fois que le nouvel hôte Amazon EC2 créé avec la classe d'instance mise à jour, la base de données de l'hôte existant est arrêtée. Le stockage de données est alors détaché de l'ancien hôte et rattaché au nouvel hôte d'une classe d'instance demandée. Votre base de données redémarre et le moteur effectue la récupération pour s'assurer que votre base de données reste dans un état cohérent. Toute interruption au cours de ce processus sera proportionnelle à la durée de récupération de la base de données.

Lorsque vous modifiez la classe d'instance d'une instance multi-AZ dans Amazon RDS, votre instance de secours est d'abord mise à jour. Après cette mise à jour, un basculement se produit, basculant les rôles des instances de secours et des instances principales. Le mécanisme de basculement propage également le point de terminaison DNS de l'instance de base de données afin de pointer vers le nouvel hôte. Après la récupération de la base de données, l'application peut accéder à la base de données. La modification de la classe d'instance est ensuite effectuée sur la nouvelle instance de secours.

En fonction de l'activité de votre base de données ou des transactions de longue durée, votre basculement peut prendre plus de temps que d'habitude. Les basculements s'effectuent généralement en 60 à 120 secondes. Toutefois, les transactions volumineuses ou un long processus de récupération peuvent augmenter le temps de basculement. Il est recommandé de s'assurer qu'il n'y a pas de transactions ouvertes dans votre base de données lors d'une modification d'instance. Pour éviter toute interruption, vous pouvez également planifier une tâche de maintenance.

Modification du stockage dans Amazon RDS

Si vous avez besoin d'espace supplémentaire pour les données ou d'attributs de performances de stockage différents, Amazon RDS prend en charge les mises à jour des éléments suivants (sans impact sur les performances) :

• Attribution de stockage
• IOPS
• Type de volume

Amazon RDS tire parti d'Elastic Volumes pour Amazon Elastic Block Store (Amazon EBS) afin de réduire le temps requis pour les opérations de mise à l'échelle du stockage. En fonction de la quantité de stockage demandée, Amazon RDS s'ajuste automatiquement sur plusieurs volumes Amazon EBS pour améliorer la performance.

Lorsque vous modifiez votre instance pour ajouter du stockage, votre instance de base de données est entièrement opérationnelle pour les requêtes d'application. Après avoir modifié le stockage sur une instance RDS, il existe une période de grâce de six heures avant de pouvoir effectuer des mises à jour de stockage supplémentaires. Pendant cette période, le statut d'instance indique « optimisation du stockage ». Lorsque votre instance entre dans la phase « optimisation du stockage », les nouveaux attributs de stockage sont entièrement activés et les performances ne sont pas impactées.

Mise à l'échelle du stockage dans Amazon RDS

La mise à l'échelle du stockage est un processus en ligne, et la base de données est pleinement opérationnelle pendant le processus. Toutefois, pour certaines instances RDS héritées, une conversion de stockage unique est requise.

Au cours de cette opération, les performances d'E/S peuvent être affectées pendant qu'Amazon RDS lit les données de l'ancien ensemble de volumes et écrit dans le nouvel ensemble. De plus, lors d'une mise à l'échelle supérieure à 400 Go (ou 200 Go pour les instances de base de données Oracle), Amazon RDS utilise également la méthode héritée pour la mise à l'échelle. Au cours de la méthode héritée, vous pouvez rencontrer une dégradation des performances. Toutes les modifications ultérieures de la mise à l'échelle du stockage utiliseront la méthode de mise à l'échelle élastique.

Conversions mono-AZ en multi-AZ dans Amazon RDS

Lorsque vous convertissez une instance de base de données mono-AZ en instance de base de données multi-AZ, Amazon RDS crée d'abord une copie de la base de données. Ensuite, la copie est restaurée dans une autre zone de disponibilité. Étant donné que la restauration des instantanés EBS fait également partie de ce processus, les blocs de stockage sont copiés sur le nouveau volume. Par conséquent, les conversions mono-AZ en Multi-AZ peuvent avoir un impact sur la latence et les performances des instances de base de données. Pour plus d'informations, consultez la section Haute disponibilité (multi-AZ) pour Amazon RDS.

L'impact de la conversion en multi-AZ est plus prononcé pour les instances de base de données à forte intensité d'écriture avec de gros volumes de stockage, pendant les périodes de charge de travail élevées. De plus, toute opération impliquant la restauration de volumes (comme la création de réplicas en lecture ou la restauration d'instantanés dans une nouvelle instance de base de données) entraîne une latence accrue. Une fois les blocs de stockage copiés depuis Amazon Simple Storage Service (Amazon S3) vers le nouveau volume, la latence disparaît.