Basculement sur un cluster de bases de données multi-AZ pour Amazon RDS

En cas d'arrêt planifié ou non planifié de votre instance de base de données de rédacteur dans un cluster de base de données Multi-AZ, Amazon RDS bascule automatiquement sur une instance de base de données de lecteur dans une zone de disponibilité différente. Cela assure une haute disponibilité avec un minimum de perturbations. Des basculements peuvent se produire lors de pannes matérielles, de problèmes réseau ou de demandes manuelles. Cette rubrique décrit la détection automatique des pannes, la séquence des événements lors du basculement et son impact sur les opérations de lecture et d’écriture. Elle fournit également les bonnes pratiques en matière de surveillance et de minimisation des temps de basculement.

La durée du basculement dépend de l'activité de base de données et d'autres conditions au moment où l'instance de base de données d'écriture est devenue indisponible. Les durées de basculement sont généralement inférieures à 35 secondes. Le basculement se termine lorsque les deux instances de base de données de lecture ont appliqué les transactions en suspens de l'instance d'écriture défaillante. Lorsque le basculement est terminé, un temps supplémentaire peut être nécessaire pour que la console RDS reflète la nouvelle zone de disponibilité.

Basculements automatiques

Étant donné qu'Amazon RDS gère automatiquement les basculements, vous pouvez reprendre les opérations de base de données aussi rapidement que possible sans intervention administrative. Pour basculer, l'instance de base de données d'écriture bascule automatiquement sur une instance de base de données de lecture.

Basculement manuel d'un cluster de base de données multi-AZ

Si vous basculez manuellement sur un cluster de bases de données multi-AZ, RDS met d’abord fin à l’instance de base de données principale. Ensuite, le système de surveillance interne détecte que l’instance de base de données principale est défectueuse et promeut une instance de base de données de réplica accessible en lecture. Les durées de basculement sont généralement inférieures à 35 secondes.

Vous pouvez faire basculer manuellement un cluster de bases de données multi-AZ à partir de la AWS Management Console, d'AWS CLI ou de l'API RDS.

aws rds failover-db-cluster --db-cluster-identifier mymultiazdbcluster

Déterminer si un cluster de base de données multi-AZ a basculé

Pour déterminer si votre cluster de base de données multi-AZ a basculé, voici ce que vous pouvez faire :

Pour savoir comment répondre aux basculements, réduire le temps de récupération et découvrir d'autres bonnes pratiques pour Amazon RDS, consultez Bonnes pratiques relatives à Amazon RDS..

Configuration de la durée de vie de la JVM pour les recherches de nom DNS

Le mécanisme de basculement modifie automatiquement l'enregistrement DNS de l'instance de base de données pour pointer vers l'instance de base de données de lecture. Par conséquent, vous devez rétablir toutes les connexions existantes à votre instance de base de données. Dans un environnement de machine virtuelle Java, vous devrez peut-être reconfigurer les paramètres de votre machine virtuelle Java, en raison du fonctionnement du mécanisme de mise en cache Java du DNS.

La machine virtuelle Java met en cache les recherches de noms DNS. Lorsque la JVM résout un nom d'hôte en adresse IP, elle met en cache l'adresse IP pendant une période définie appelée time-to-live (TTL, durée de vie).

Comme les ressources AWS utilisent des entrées de nom DNS qui changent parfois, nous vous recommandons de configurer votre JVM avec une valeur de durée de vie (TTL) de 60 secondes. De cette manière, lorsque l'adresse IP d'une ressource change, votre application peut recevoir et utiliser la nouvelle adresse IP de la ressource en interrogeant le DNS.

Dans certaines configurations Java, la durée de vie par défaut de la JVM est définie de façon à ce que la JVM n'actualise jamais les entrées DNS tant qu'elle n'est pas redémarrée. Par conséquent, si l'adresse IP d'une ressource AWS change pendant que votre application est en cours d'exécution, elle ne peut pas utiliser cette ressource tant que vous n'aurez pas redémarré manuellement la JVM et que les informations IP mises en cache n'auront pas été actualisées. Dans ce cas, il est essentiel de définir la durée de vie de la JVM de façon à ce que ses informations IP mises en cache soient régulièrement actualisées.

Pour modifier la durée de vie de la JVM, définissez la valeur de la propriété networkaddress.cache.ttl. Utilisez l'une des méthodes suivantes selon vos besoins :