Déploiements de clusters de base de données Multi-AZ - Amazon Relational Database Service

Déploiements de clusters de base de données Multi-AZ

Un déploiement de cluster de base de données multi-AZ est un mode de déploiement à haute disponibilité d'Amazon RDS qui compte deux instances de base de données de secours accessibles en lecture. Un cluster de base de données multi-AZ possède une instance de base de données d'écriture et deux instances de base de données de lecture dans trois zones de disponibilité distinctes d'une même région AWS. Les clusters de base de données multi-AZ offrent une haute disponibilité, une capacité accrue pour les charges de travail en lecture et une moindre latence en écriture par rapport aux déploiements d'instances de base de données multi-AZ.

Important

Les clusters de base de données multi-AZ sont différents des clusters de base de données Aurora. Pour en savoir plus sur les clusters de base de données Aurora, consultez le Guide de l'utilisateur Amazon Aurora.

Disponibilité des régions et des versions

La disponibilité et la prise en charge des fonctionnalités varient selon les versions spécifiques de chaque moteur de base de données, et selon les Régions AWS. Pour obtenir plus d'informations sur la disponibilité des versions et des régions d'Amazon RDS avec des clusters de bases de données multi-AZ, consultez Clusters de base de données multi-AZ.

Présentation des clusters de base de données multi-AZ

Avec un cluster de base de données multi-AZ, Amazon RDS réplique les données de l'instance de base de données d'écriture dans les deux instances de base de données de lecture en tirant parti des capacités de réplication natives du moteur de base de données. Lorsqu'une modification est apportée à l'instance de base de données d'écriture, elle est transmise à chaque instance de base de données de lecture. Un accusé de réception d'au moins une instance de base de données de lecteur est nécessaire pour qu'une modification soit validée et appliquée.

Les instances de base de données d'écriture font office de cibles de basculement automatique et traitent également le trafic en lecture pour accroître le débit de lecture des applications. En cas de panne sur votre instance de base de données de rédacteur, RDS gère laquelle des instances de base de données de lecteur devient la cible de basculement. RDS procède en fonction de l'instance de base de données de lecteur qui a l'enregistrement de changement le plus récent.

Le schéma suivant illustre un cluster de base de données multi-AZ.


				Cluster de base de données multi-AZ

Les clusters de base de données multi-AZ ont généralement une latence d'écriture moindre par rapport aux déploiements d'instances de base de données multi-AZ. Ils permettent également d'exécuter des charges de travail en lecture seule sur des instances de base de données de lecteurs. La console RDS affiche la zone de disponibilité de l'instance de base de données d'écriture et les zones de disponibilité des instances de base de données de lecture. Vous pouvez également utiliser la commande CLI describe-db-clusters ou l'opération d'API DescribeDBClusters pour rechercher ces informations.

Création et gestion d'un cluster de base de données Multi-AZ

Vous pouvez créer un cluster de base de données Multi-AZ directement ou en le restaurant à partir d'un instantané. Pour obtenir des instructions, veuillez consulter ces rubriques :

Vous pouvez modifier, redémarrer ou supprimer une base de données Multi-AZ en suivant les instructions de ces rubriques :

Vous pouvez créer un instantané de cluster de base de données Multi-AZ en suivant les instructions de Création d'un instantané de cluster de bases de données multi-AZ.

Vous pouvez restaurer un cluster de base de données Multi-AZ à un instant dans le passé en suivant les instructions de Restauration d'un cluster de base de données multi-AZ à une date définie.

Gestion des connexions pour les clusters de base de données multi-AZ

Un cluster de base de données multi-AZ compte trois instances de base de données (et non une). Chaque connexion est gérée par une instance de base de données spécifique. Lorsque vous vous connectez à un cluster de base de données Multi-AZ, le nom d'hôte et le port que vous spécifiez pointent vers un gestionnaire intermédiaire appelé point de terminaison. Le cluster de base de données multi-AZ utilise le mécanisme du point de terminaison pour faire abstraction de ces connexions. Ainsi, vous n'avez pas besoin de coder en dur tous les noms d'hôtes ou d'écrire votre propre logique de réacheminement des connexions lorsque certaines instances de base de données ne sont pas disponibles.

Le point de terminaison d'écriture se connecte à l'instance de base de données de rédacteur du cluster de base de données, qui prend en charge les opérations de lecture et d'écriture. Le point de terminaison du lecteur se connecte à l'une des deux instances de base de données de lecteur, qui ne prennent en charge que les opérations de lecture.

En utilisant des points de terminaison, vous pouvez mapper chaque connexion à l'instance ou groupe d'instances de base de données approprié, selon votre cas d'utilisation. Par exemple, pour exécuter des instructions DDL et DDM, vous pouvez vous connecter à l'instance de base de données qui correspond à l'instance de base de données d'écriture. Pour effectuer des requêtes, vous pouvez vous connecter au point de terminaison du lecteur, le cluster de base de données Multi-AZ gérant automatiquement les connexions entre les instances de base de données de lecteur. Pour le diagnostic et le réglage, vous pouvez vous connecter au point de terminaison d'une instance de base de données spécifique pour en examiner les détails.

Pour en savoir plus sur la connexion à une instance de base de données, consultez Connexion à une instance de base de données Amazon RDS.

Types de points de terminaison de cluster de base de données multi-AZ

Un point de terminaison est représenté par un identificateur unique qui contient une adresse d'hôte. Voici types de points de terminaison accessibles à un cluster de base de données multi-AZ :

Point de terminaison de cluster

Dans le cas d'un cluster de base de données multi-AZ, un point de terminaison de cluster (ou point de terminaison d'écriture) se connecte à l'instance de base de données d'écriture active du cluster. Ce point de terminaison est le seul à pouvoir exécuter des opérations d'écriture, telles que des instructions DDL et DDM. Ce point de terminaison peut également effectuer des opérations de lecture.

Chaque cluster de base de données multi-AZ dispose d'un point de terminaison de cluster et d'une instance de base de données d'écriture.

Le point de terminaison du cluster est destiné à toutes les opérations d'écriture sur le cluster de bases de données, y compris les insertions, les mises à jour, les suppressions et les modifications de langage de définition de données (DDL). Vous pouvez aussi utiliser le point de terminaison de cluster pour les opérations de lecture, par exemple les requêtes.

En cas de défaillance de l'instance de base de données d'écriture active d'un cluster de base de données, le cluster de base de données multi-AZ bascule automatiquement vers une nouvelle instance de base de données d'écriture. Pendant le basculement, le cluster de base de données continue de traiter les demandes de connexion au point de terminaison de cluster à partir de la nouvelle instance de base de données d'écriture, avec une interruption de service minime.

L'exemple suivant illustre un point de terminaison de cluster pour un cluster de base de données multi-AZ.

mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com

Point de terminaison du lecteur

Dans le cas d'un cluster de base de données Multi-AZ, un point de terminaison du lecteur prend en charge les connexions en lecture seule au cluster de base de données. Utilisez le point de terminaison de lecteur pour les opérations de lecture, par exemple les requêtes SELECT. En traitant ces instructions sur les instances de base de données de lecture, ce point de terminaison réduit la surcharge au niveau de l'instance de base de données d'écriture. Il aide également le cluster à mettre à l'échelle la capacité à traiter simultanément les requêtes SELECT. Chaque cluster de base de données multi-AZ dispose d'un point de terminaison de lecteur.

Le point de terminaison du lecteur répartit la charge de chaque demande de connexion entre les instances de base de données de lecteur. Lorsque vous utilisez le point de terminaison du lecteur pour une session, vous pouvez uniquement exécuter des instructions en lecture seule, telles que SELECT, dans cette session.

L'exemple suivant illustre un point de terminaison de lecteur pour un cluster de base de données multi-AZ. L'intention de lecture seule d'un point de terminaison de lecteur est indiquée par le suffixe -ro qui figure dans le nom du point de terminaison du cluster.

mydbcluster.cluster-ro-123456789012.us-east-1.rds.amazonaws.com

Point de terminaison d'instance

Un point de terminaison d'instance se connecte à une instance de base de données spécifique dans un cluster de base de données multi-AZ. Chaque instance de bases de données d'un cluster de bases de données a son propre point de terminaison d'instance unique. Par conséquent, il existe un point de terminaison d'instance pour l'instance de base de données d'écriture active du cluster de base de données, et un point de terminaison d'instance pour chaque instance de base de données de lecture du cluster de base de données.

Le point de terminaison d'instance permet de contrôler directement les connexions au cluster de base de données. Cela vous permet de gérer les cas où l'utilisation du point de terminaison de cluster ou du point de terminaison de lecteur n'est pas appropriée. Par exemple, votre application client peut exiger une répartition de charge plus précis en fonction de la charge de travail. Dans ce cas, vous pouvez configurer plusieurs clients pour qu'ils se connectent à différentes instances de base de données de lecture au sein d'un cluster de base de données afin de distribuer les charges de travail en lecture.

L'exemple suivant illustre un point de terminaison d'instance pour une instance de base de données au sein d'un cluster de base de donnes multi-AZ.

mydbinstance.123456789012.us-east-1.rds.amazonaws.com

Affichage des points de terminaison d'un cluster de base de données multi-AZ

Dans la AWS Management Console, la page de détails de chaque cluster de base de données multi-AZ présente le point de terminaison de cluster et le point de terminaison de lecteur. La page de détails de chaque instance de base de données présente le point de terminaison d'instance.

Avec AWS CLI, les points de terminaison d'écriture et de lecteur figurent dans la sortie de la commande describe-db-clusters. Par exemple, la commande suivante affiche les attributs de point de terminaison pour tous les clusters figurant dans votre région AWS actuelle.

aws rds describe-db-cluster-endpoints

L'API Amazon RDS vous permet de récupérer les points de terminaison en appelant l'action DescribeDBClusterEndpoints. La sortie présente également les points de terminaison du cluster de base de données Amazon Aurora, le cas échéant.

Utilisation du point de terminaison du cluster

Chaque cluster de base de données multi-AZ intègre un point de terminaison de cluster, dont le nom et les autres attributs sont gérés par Amazon RDS. Vous ne pouvez pas créer, supprimer ni modifier ce type de point de terminaison.

Le point de terminaison de cluster vous permet d'administrer votre cluster de base de données, d'effectuer des opérations ETL (extraction, transformation et chargement) ou de développer et tester des applications. Le point de terminaison de cluster se connecte à l'instance de base de données d'écriture du cluster. L'instance de base de données d'écriture est la seule instance de base de données dans laquelle vous pouvez créer des tables et des index, exécuter des instructions INSERT et effectuer d'autres opérations DDL et DML.

L'adresse IP physique à laquelle renvoie le point de terminaison du cluster change lorsque le mécanisme de basculement promeut une nouvelle instance de base de données au rang d'instance principale de base de données d'écriture du cluster. Si vous utilisez toute forme de groupes de connexions ou de multiplexage quelconque, préparez-vous à réduire la durée de vie (time-to-live, TTL) des informations DNS mises en cache. Cette technique vous empêche d'essayer d'établir une connexion en lecture/écriture à une instance de base de données qui est devenue indisponible ou qui n'est plus qu'en lecture seule après un basculement.

Utilisation du point de terminaison du lecteur

Le point de terminaison de lecteur vous sert pour les connexions en lecture seule au cluster de base de données multi-AZ. Ce point de terminaison aide votre cluster de base de données à gérer une charge de travail exigeante en requêtes. Le point de terminaison du lecteur est le point de terminaison que vous fournissez aux applications qui créent les rapports ou qui effectuent d'autres opérations en lecture seule sur le cluster. Le point de terminaison du lecteur envoie des connexions aux instances de base de données de lecteur disponibles dans un cluster de base de données Multi-AZ.

Chaque cluster multi-AZ intègre un point de terminaison de lecteur, dont le nom et les autres attributs sont gérés par Amazon RDS. Vous ne pouvez pas créer, supprimer ni modifier ce type de point de terminaison.

Utilisation des points de terminaison d'instance

Chaque instance de base de données d'un cluster de base de données multi-AZ dispose de son propre point de terminaison d'instance intégré, dont le nom et les autres attributs sont gérés par Amazon RDS. Vous ne pouvez pas créer, supprimer ni modifier ce type de point de terminaison. Avec un cluster de base de données multi-AZ, vous utilisez généralement plus souvent les points de terminaison d'écriture et de lecture que les points de terminaison d'instance.

Dans les opérations au quotidien, vous utilisez principalement les points de terminaison d'instance pour diagnostiquer les problèmes de capacité ou de performances qui affectent une instance de base de données déterminée au sein d'un cluster de base de données multi-AZ. Lorsque vous êtes connecté à une instance de base de données spécifique, vous pouvez examiner ses variables de statut, ses métriques, etc. Cette approche vous permet de déterminer en quoi le comportement de cette instance de base de données se distingue de celui des autres instances de base de données du cluster.

Les points de terminaison de base de données multi-AZ et la haute disponibilité

Dans le cas des clusters de base de données Multi-AZ où la haute disponibilité est importante, utilisez le point de terminaison d'écriture pour les opérations de lecture/écriture ou les connexions à usage général et le point de terminaison du lecteur pour les connexions en lecture seule. Les points de terminaison de l'enregistreur et du lecteur gèrent le basculement d'instance de base de données mieux que ne le font les points de terminaison d'instance. Contrairement aux points de terminaison d'instance, les points de terminaison de l'enregistreur et du lecteur modifient automatiquement l'instance de base de données à laquelle ils se connectent si une instance de base de données de votre cluster devient indisponible.

En cas de défaillance de l'instance de base de données d'écriture d'un cluster de base de données, Amazon RDS bascule automatiquement sur une nouvelle instance de base de données d'écriture. Une instance de base de données de lecture est alors promue au rang d'instance de base de données d'écriture. Si un basculement échoue, vous pouvez utiliser le point de terminaison d'écriture pour vous reconnecter à l'instance de base de données d'écriture nouvellement promue. Vous pouvez également utiliser le point de terminaison du lecteur pour vous reconnecter à l'une des instances de base de données de lecture du cluster de base de données. Pendant le basculement, le point de terminaison du lecteur peut brièvement diriger les connexions vers la nouvelle instance de base de données d'écriture d'un cluster de base de données après qu'une instance de base de données de lecture a été promue au rang de nouvelle instance de base de données d'écriture. Si vous concevez votre propre logique d'application pour gérer les connexions de point de terminaison d'instance, vous pouvez découvrir manuellement ou par programmation l'ensemble d'instances de base de données disponibles dans le cluster de base de données.

Gestion d'un cluster de base de données multi-AZ avec la AWS Management Console

Vous pouvez gérer un cluster de base de données multi-AZ avec la console.

Pour gérer un cluster de base de données multi-AZ avec la console

  1. Connectez-vous à la AWS Management Console et ouvrez la console Amazon RDS à l'adresse https://console.aws.amazon.com/rds/.

  2. Dans le panneau de navigation, choisissez Databases (Bases de données), puis le cluster de base de données multi-AZ que vous souhaitez gérer.

L'image suivante montre un cluster de base de données multi-AZ dans la console.


				Cluster de base de données multi-AZ dans la AWS Management Console

Les actions disponibles dans le menu Actions varient selon que vous sélectionnez le cluster de base de données multi-AZ ou une instance de base de données du cluster.

Choisissez le cluster de base de données multi-AZ pour en afficher les détails et effectuer des actions au niveau du cluster.


				Actions de cluster de base de données multi-AZ dans la AWS Management Console

Choisissez une instance de base de données dans un cluster de base de données multi-AZ pour en afficher les détails et effectuer des actions au niveau de cette instance de base de données.


				Actions d'instance de base de données dans un cluster de base de données multi-AZ dans la AWS Management Console

Utilisation des groupes de paramètres pour clusters de base de données multi-AZ

Dans un cluster de base de données multi-AZ, un groupe de paramètres de cluster de base de données sert de conteneur pour les valeurs de configuration du moteur qui sont appliquées à chaque instance de base de données contenue dans le cluster de base de données multi-AZ.

Dans un cluster de base de données multi-AZ, un groupe de paramètres de base de données est défini comme étant le groupe de paramètres de base de données par défaut pour le moteur et la version du moteur de base de données Les paramètres du groupe de paramètres de cluster de base de données s'appliquent à toutes les instances de base de données du cluster.

Pour plus d'informations sur les groupes de paramètres, veuillez consulter Utilisation des groupes de paramètres.

Retard de réplica et clusters de base de données multi-AZ

Le retard de réplica est la différence de temps entre la dernière transaction au niveau de l'instance de base de données d'enregistreur et la dernière transaction appliquée sur une instance de base de données de lecteur. La métrique Amazon CloudWatch ReplicaLag représente cette différence de temps. Pour de plus amples informations sur les métriques CloudWatch, veuillez consulter Surveillance des métriques Amazon RDS avec Amazon CloudWatch.

Bien que les clusters de base de données Multi-AZ permettent des performances d'écriture élevées, un retard de réplica peut toujours se produire en raison de la nature de la réplication basée sur le moteur. Étant donné que tout basculement doit d'abord résoudre le retard du réplica avant de promouvoir une nouvelle instance de base de données d'enregistreur, la surveillance et la gestion de ce retard de réplica sont à prendre en compte.

Pour les clusters de base de données Multi-AZ RDS for MySQL, le temps de basculement dépend du décalage de réplica des deux instances de base de données de lecteur restantes. Les deux instances de base de données de lecteur doivent appliquer des transactions non appliquées avant que l'une d'elles ne soit promue vers la nouvelle instance de base de données de rédacteur.

Pour les clusters de bases de données Multi-AZ RDS for PostgreSQL, le temps de basculement dépend du décalage de réplica le plus bas des deux instances de bases de données de lecture restantes. L'instance de base de données de lecteur ayant le plus faible décalage de réplica doit appliquer les transactions non appliquées avant d'être promue en tant que nouvelle instance de base de données de rédacteur.

Pour obtenir un didacticiel qui explique comment créer une alarme CloudWatch lorsque le décalage de réplica dépasse un certain temps, veuillez consulter Didacticiel : Création d'une alarme Amazon CloudWatch pour un décalage de réplica de cluster de bases de données Multi-AZ.

Causes courantes du retard de réplica

En général, le retard de réplica se produit lorsque la charge de travail en écriture est trop élevée pour que les instances de base de données du lecteur puissent appliquer efficacement les transactions. Diverses charges de travail peuvent entraîner un retard de réplica temporaire ou continu. Voici quelques exemples de causes courantes :

  • Une concurrence d'écriture élevée ou une mise à jour par lots lourde sur l'instance de base de données de l'enregistreur, ce qui entraîne un retard du processus d'application sur les instances de base de données du lecteur.

  • Une charge de travail de lecture lourde qui utilise des ressources sur une ou plusieurs instances de base de données du lecteur. L'exécution de requêtes lentes ou volumineuses peut affecter le processus d'application et entraîner un retard de réplica.

  • Les transactions qui modifient de grandes quantités de données ou d'instructions DDL peuvent parfois entraîner une augmentation temporaire du retard de réplica, car la base de données doit préserver l'ordre de validation.

Atténuation du retard de réplica

Pour les clusters de base de données multi-AZ pour RDS for MySQL et RDS for PostgreSQL, vous pouvez réduire le retard de réplica en réduisant la charge sur votre instance de base de données d'enregistreur. Vous pouvez également utiliser le contrôle de flux pour réduire le décalage de réplica. Le contrôle de flux fonctionne en limitant les écritures sur l'instance de base de données d'enregistreur, ce qui garantit que le retard de réplica ne continue pas à augmenter sans limite. La limitation des écritures est obtenue en ajoutant un délai à la fin d'une transaction, ce qui réduit le débit d'écriture sur l'instance de base de données d'enregistreur. Bien que le contrôle de flux ne garantit pas l'élimination du retard, il peut contribuer à réduire le retard global pour de nombreuses charges de travail. Les sections suivantes fournissent des informations sur l'utilisation du contrôle de flux avec RDS for MySQL et RDS for PostgreSQL.

Atténuation du décalage de réplica avec le contrôle de flux pour RDS for MySQL

Lorsque vous utilisez les clusters de bases de données Multi-AZ RDS for PostgreSQL, le contrôle de flux est activé par défaut à l'aide du paramètre dynamique rpl_semi_sync_master_target_apply_lag. Ce paramètre spécifie la limite supérieure souhaitée pour le décalage du réplica. À mesure que le décalage de réplica approche cette limite configurée, le contrôle de flux limite les transactions d'écriture sur l'instance de base de données de rédacteur pour tenter de contenir le décalage du réplica en dessous de la valeur spécifiée. Dans certains cas, le décalage de réplica peut dépasser la limite spécifiée. Par défaut, ce paramètre est défini à 120 secondes. Pour désactiver le contrôle de flux, définissez ce paramètre sur sa valeur maximale de 86 400 secondes (un jour).

Pour afficher le délai de courant injecté par le contrôle de flux, affichez le paramètre Rpl_semi_sync_master_flow_control_current_delay en exécutant la requête suivante.

SHOW GLOBAL STATUS like '%flow_control%';

Votre résultat ressemble à ce qui suit.

+-------------------------------------------------+-------+ | Variable_name | Value | +-------------------------------------------------+-------+ | Rpl_semi_sync_master_flow_control_current_delay | 2010 | +-------------------------------------------------+-------+ 1 row in set (0.00 sec)
Note

Le délai est affiché en microsecondes.

Lorsque Performance Insights est activé pour un cluster de bases de données Multi-AZ RDS for MySQL, vous pouvez surveiller l'événement d'attente correspondant à une instruction SQL indiquant que les requêtes ont été retardées par un contrôle de flux. Lorsqu'un délai a été introduit par un contrôle de flux, vous pouvez afficher l'événement d'attente /wait/synch/cond/semisync/semi_sync_flow_control_delay_cond correspondant à l'instruction SQL du tableau de bord Performance Insights. Pour afficher ces métriques, assurez-vous que le schéma de performances est activé. Pour plus d'informations sur Performance Insights, veuillez consulter Surveillance de la charge de la base de données avec Performance Insights sur Amazon RDS.

Atténuation du décalage de réplica avec le contrôle de flux pour RDS for PostgreSQL

Lorsque vous utilisez les clusters de base de données Multi-AZ RDS for PostgreSQL, le contrôle de flux est déployé en tant qu'extension. Il active un processus de travail en arrière-plan pour toutes les instances de base de données du cluster de base de données. Par défaut, les processus de travail en arrière-plan sur les instances de base de données de lecteur communiquent le retard actuel du réplica avec le processus de travail en arrière-plan sur l'instance de base de données d'enregistreur. Si le retard dépasse deux minutes sur n'importe quelle instance de base de données de lecteur, le processus de travail en arrière-plan de l'instance de base de données d'enregistreur ajoute un délai à la fin d'une transaction. Pour contrôler le seuil de retard, utilisez le paramètre flow_control.target_standby_apply_lag.

Lorsqu'un contrôle de flux limite un processus PostgreSQL, l'événement d'attente Extension dans pg_stat_activity et Performance Insights l'indique. La fonction get_flow_control_stats affiche des détails sur le délai actuellement ajouté.

Le contrôle de flux peut bénéficier à la plupart des charges de travail de traitement transactionnel en ligne (OLTP) ayant des transactions courtes mais très concurrentes. Si le retard est causé par des transactions de longue durée, telles que des opérations par lots, le contrôle de flux n'offre pas un avantage aussi important.

Vous pouvez désactiver le contrôle de flux en supprimant l'extension de preload_shared_libraries et en redémarrant votre instance de base de données.

Processus de basculement des clusters de base de données multi-AZ

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. 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

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.

Pour faire basculer manuellement un cluster de base de données multi-AZ

  1. Connectez-vous à l'AWS Management Console et ouvrez la console Amazon RDS à l'adresse https://console.aws.amazon.com/rds/.

  2. Dans la panneau de navigation, choisissez Databases (Bases de données).

  3. Choisissez le cluster de base de données multi-AZ que vous voulez faire basculer.

  4. Pour Actions, choisissez Failover (Basculement).

    La page Failover DB cluster (Basculement du cluster de base de données) s'affiche.

  5. Choisissez Failover (Basculement) pour confirmer le basculement manuel.

Pour faire basculer manuellement un cluster de base de données multi-AZ, utilisez la commande failover-db-cluster d'AWS CLI.

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

Pour faire basculer manuellement un cluster de base de données multi-AZ, appelez l'opération FailoverDBCluster de l'API Amazon RDS et spécifiez DBClusterIdentifier.

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 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.

  • Examinez vos événements de base de données à l'aide de la console Amazon RDS ou des opérations d'API.

  • Examinez l'état actuel de votre cluster de base de données multi-AZ à l'aide de la console Amazon RDS, d'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..

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.

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 de plus amples informations sur les responsables de la sécurité dans Oracle, veuillez consulter The Security Manager dans la documentation Oracle.

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 :

  • 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");

Limites des clusters de base de données multi-AZ

Les limites suivantes s'appliquent aux clusters de base de données Multi-AZ :

  • Les clusters de base de données multi-AZ prennent uniquement en charge le stockage IOPS provisionnés.

  • Vous ne pouvez pas transformer un déploiement d'instance de base de données mono-AZ ou un déploiement d'instance de base de données multi-AZ en cluster de base de données multi-AZ En revanche, vous pouvez restaurer l'instantané d'un déploiement d'instance de base de données mono-AZ ou d'un déploiement d'instance de base de données multi-AZ dans un cluster de base de données multi-AZ.

  • Vous ne pouvez pas restaurer un instantané de cluster de base de données multi-AZ dans un déploiement d'instance de base de données multi-AZ ou un déploiement mono-AZ.

  • Les clusters de base de données multi-AZ ne prennent pas en charge les modifications au niveau de l'instance de base de données, car toutes les modifications s'effectuent au niveau du cluster de base de données.

  • Les clusters de base de données multi-AZ ne prennent pas en charge les fonctions suivantes :

    • Amazon RDS Proxy

    • AWS CloudFormation

    • Prise en charge des connexions IPv6 (mode double pile)

    • Exportation de données d'instantané de cluster de base de données multi-AZ vers un compartiment Amazon S3

    • Authentification de base de données IAM

    • Authentification Kerberos

    • Modification du port

      Il existe une solution de remplacement qui consiste à restaurer un cluster de base de données multi-AZ à un instant dans le passé et à spécifier un port différent.

    • Groupes d'options

    • Réplicas en lecture

    • Instances de base de données réservées

    • Restauration d'un instantané de cluster de base de données multi-AZ à partir d'un compartiment Amazon S3

    • Mise à l'échelle automatique du stockage en définissant la capacité de stockage allouée maximale

      En guise d'alternative, vous pouvez mettre le stockage à l'échelle manuellement.

    • Arrêt et démarrage du cluster de base de données

    • Copie d’un instantané de cluster de base de données multi-AZ

    • Chiffrement d'un cluster de base de données Multi-AZ non chiffré

  • Les clusters de base de données Multi-AZ RDS for MySQL ne prennent pas en charge la réplication dans une base de données cible externe.

  • Les clusters de base de données Multi-AZ RDS for MySQL ne prennent en charge que les procédures stockées système suivantes :

    • mysql.rds_rotate_general_log

    • mysql.rds_rotate_slow_log

    • mysql.rds_show_configuration

    Les clusters de base de données Multi-AZ RDS for MySQL ne prennent pas en charge les autres procédures stockées système. Pour obtenir des informations sur ces procédures, veuillez consulter Référence SQL de MySQL sur Amazon RDS.

  • Les clusters de base de données multi-AZ RDS for PostgreSQL ne prennent pas en charge les extensions PostgreSQL suivantes : aws_s3, pg_transport et pglogical.

  • Les clusters de base de données multi-AZ RDS for PostgreSQL ne prennent pas en charge l'utilisation d'un serveur DNS personnalisé pour l'accès réseau sortant.

  • Les clusters de base de données multi-AZ RDS for PostgreSQL ne prennent pas en charge la réplication logique.