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 cluster de base de données multi-AZ pour Amazon RDS
En cas de panne planifiée ou imprévue de votre instance de base de données d'écriture dans un cluster de base de données multi-AZ, Amazon bascule RDS automatiquement vers une instance de base de données de lecteur située dans une autre zone de disponibilité. Cela garantit 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 défaillances, la séquence des événements lors du basculement et son impact sur les opérations de lecture et d'écriture. Il fournit également les meilleures pratiques pour surveiller et minimiser les 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é, la RDS console peut mettre plus de temps à refléter la nouvelle zone de disponibilité.
Rubriques
Basculements automatiques
Amazon RDS gère automatiquement les basculements afin que vous puissiez reprendre les opérations de base de données le plus rapidement 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 base de données multi-AZ, mettez d'RDSabord 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éplique lisible. Les durées de basculement sont généralement inférieures à 35 secondes.
Vous pouvez basculer manuellement sur un cluster de base de données multi-AZ à l'aide du AWS Management Console AWS CLI, du ou du RDSAPI.
Pour faire basculer manuellement un cluster de base de données multi-AZ
Connectez-vous à la RDS console Amazon AWS Management Console et ouvrez-la à l'adresse https://console.aws.amazon.com/rds/
. -
Dans le panneau de navigation, choisissez Databases (Bases de données).
-
Choisissez le cluster de base de données multi-AZ que vous voulez faire basculer.
-
Pour Actions, choisissez Failover (Basculement).
La page Failover DB Cluster s'affiche.
-
Choisissez Failover (Basculement) pour confirmer le basculement manuel.
Pour basculer manuellement sur un cluster de base de données multi-AZ, utilisez la AWS CLI commande failover-db-cluster.
aws rds failover-db-cluster --db-cluster-identifiermymultiazdbcluster
Pour basculer manuellement sur un cluster de bases de données multi-AZ, appelez Amazon RDS API F ailoverDBCluster et spécifiez leDBClusterIdentifier.
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 :
Configurez des abonnements aux événements de base de données pour vous informer par e-mail ou SMS qu'un basculement a été initié. Pour plus d'informations sur les événements, consultez Utilisation des notifications d'RDSévénements Amazon.
Consultez les événements de votre base de données à l'aide de la RDS console ou API des opérations Amazon.
Consultez l'état actuel de votre cluster de base de données multi-AZ à l'aide de la RDS console Amazon, du AWS CLI, et du RDSAPI.
Pour plus d'informations sur la manière dont vous pouvez réagir en cas de basculement, réduire le temps de restauration et sur d'autres bonnes pratiques pour AmazonRDS, consultezBonnes pratiques pour Amazon RDS.
Configuration JVM TTL des recherches DNS de noms
Le mécanisme de basculement modifie automatiquement l'enregistrement Domain Name System (DNS) de l'instance de base de données pour qu'il pointe vers l'instance de base de données du lecteur. 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 (JVM), en raison du fonctionnement du mécanisme de DNS mise en cache Java, il se peut que vous deviez reconfigurer JVM les paramètres.
Les recherches de DNS noms de JVM caches. Lorsque le JVM convertit un nom d'hôte en adresse IP, il met l'adresse IP en cache pendant une période spécifiée, connue sous le nom de time-to-live(TTL).
Étant donné que les AWS ressources utilisent des entrées de DNS nom qui changent parfois, nous vous recommandons de configurer votre nom JVM avec une TTL valeur ne dépassant pas 60 secondes. Cela garantit que lorsque l'adresse IP d'une ressource change, votre application peut recevoir et utiliser la nouvelle adresse IP de la ressource en demandant le. DNS
Sur certaines configurations Java, la JVM valeur par défaut TTL est définie de manière à ne jamais actualiser les DNS entrées avant JVM le redémarrage. 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 ne l'avez pas redémarrée manuellement JVM et que les informations IP mises en cache ne sont pas actualisées. Dans ce cas, il est essentiel de définir le JVM « s » TTL afin qu'il actualise régulièrement ses informations IP mises en cache.
Note
La valeur par défaut TTL peut varier en fonction de la version de votre ordinateur JVM et de l'installation ou non d'un gestionnaire de sécurité. Beaucoup JVMs fournissent une valeur par défaut TTL inférieure à 60 secondes. Si vous utilisez un tel gestionnaire JVM sans utiliser de gestionnaire de sécurité, vous pouvez ignorer le reste de cette rubrique. Pour de plus amples informations sur les responsables de la sécurité dans Oracle, veuillez consulter The Security Manager
Pour modifier les « JVM s »TTL, définissez la valeur de la networkaddress.cache.ttl
-
Pour définir la valeur de propriété de manière globale pour toutes les applications utilisant leJVM, définissez
networkaddress.cache.ttldans le$JAVA_HOME/jre/lib/security/java.securityfichier.networkaddress.cache.ttl=60 -
Pour définir la propriété localement pour votre application uniquement, définissez
networkaddress.cache.ttldans le code d'initialisation de votre application avant que les connexions réseau ne soient établies.java.security.Security.setProperty("networkaddress.cache.ttl" , "60");
