Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Défaillance d'un Multi-AZ cluster de base de données pour Amazon RDS
En cas de panne planifiée ou imprévue de votre instance de base de données d'écriture dans un Multi-AZ cluster de base de données, Amazon RDS bascule automatiquement vers une instance de base de données de lecteur située dans une autre zone de disponibilité. 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é.
**Topics**
+ [Basculements automatiques](#multi-az-db-clusters-concepts-failover-automatic)
+ [Basculement manuel sur un Multi-AZ cluster de base de données](#multi-az-db-clusters-concepts-failover-manual)
+ [Déterminer si un Multi-AZ cluster de base de données a basculé](#multi-az-db-clusters-concepts-failover-determining)
+ [Configuration de la durée de vie de la JVM pour les recherches de nom DNS](#multi-az-db-clusters-concepts-failover-java-dns)
## 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 sur un Multi-AZ cluster de base de données
Si vous basculez manuellement sur un Multi-AZ cluster de base de données, 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 basculer manuellement sur un Multi-AZ cluster de base de données à l'aide de l'API AWS Management Console, de AWS CLI, ou de l'API RDS.
### Console
**Pour basculer manuellement sur un Multi-AZ cluster de bases de données**
1. Connectez-vous à la console Amazon RDS AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)l'adresse.
1. Dans le panneau de navigation, choisissez **Databases (Bases de données)**.
1. Choisissez le Multi-AZ cluster de base de données sur lequel vous souhaitez basculer.
1. Pour **Actions**, choisissez **Failover (Basculement)**.
La page **Basculement du cluster de bases de données** s’affiche.
1. Choisissez **Failover (Basculement)** pour confirmer le basculement manuel.
### AWS CLI
Pour basculer manuellement sur un Multi-AZ cluster de base de données, utilisez la AWS CLI commande [failover-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/failover-db-cluster.html).
**Example**
```
1. aws rds failover-db-cluster --db-cluster-identifier {{mymultiazdbcluster}}
```
### API RDS
Pour basculer manuellement sur un Multi-AZ cluster de bases de données, appelez l'API Amazon RDS [FailoverDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_FailoverDBCluster.html) et spécifiez le. `DBClusterIdentifier`
## Déterminer si un Multi-AZ cluster de base de données a basculé
Pour déterminer si votre Multi-AZ cluster de base de données a basculé, vous pouvez effectuer les opérations suivantes :
+ Configurez les abonnements aux événements de base de données de sorte qu’ils vous notifient par e-mail ou SMS qu’un basculement a été initié. Pour plus d'informations sur les événements, consultez [Utiliser la notification d’événements d’Amazon RDS](USER_Events.md).
+ Examinez vos événements de base de données à l'aide de la console Amazon RDS ou des opérations d'API.
+ Consultez l'état actuel de votre Multi-AZ cluster de bases de données à l'aide de la console Amazon RDS, du AWS CLI, et de l'API RDS.
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.](CHAP_BestPractices.md).
## 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).
Étant donné que les AWS ressources utilisent des entrées de nom DNS qui changent occasionnellement, nous vous recommandons de configurer votre JVM avec une valeur TTL ne dépassant pas 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. Ainsi, si l'adresse IP d'une AWS ressource change alors que votre application est toujours en cours d'exécution, elle ne peut pas utiliser cette ressource tant que vous n'avez pas redémarré manuellement la JVM et que les informations IP mises en cache ne sont pas 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.
**Note**
La durée de vie par défaut peut varier en fonction de la version de votre JVM et selon qu'un gestionnaire de sécurité est installé ou non. De nombreuses JVM fournissent une durée de vie par défaut de moins de 60 secondes. Si c'est le cas pour la JVM que vous utilisez et que vous n'avez pas recours à un gestionnaire de sécurité, vous pouvez ignorer le reste de cette rubrique. Pour plus d’informations sur les responsables de la sécurité dans Oracle, consultez [The Security Manager](https://docs.oracle.com/javase/tutorial/essential/environment/security.html) dans la documentation Oracle.
Pour modifier la durée de vie de la JVM, définissez la valeur de la propriété [https://docs.oracle.com/javase/7/docs/technotes/guides/net/properties.html](https://docs.oracle.com/javase/7/docs/technotes/guides/net/properties.html). Utilisez l'une des méthodes suivantes selon vos besoins :
+ Pour définir globalement la valeur de la propriété pour toutes les applications qui utilisent la JVM, définissez `networkaddress.cache.ttl` dans le fichier `$JAVA_HOME/jre/lib/security/java.security`.
```
networkaddress.cache.ttl=60
```
+ Pour définir la propriété localement pour votre application uniquement, définissez `networkaddress.cache.ttl` dans le code d'initialisation de votre application avant que les connexions réseau ne soient établies.
```
java.security.Security.setProperty("networkaddress.cache.ttl" , "60");
```