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éploiements d'instances de base de données multi-AZ
Amazon RDS assure une haute disponibilité et une prise en charge du basculement pour les instances de base de données utilisant des déploiements multi-AZ avec une seule instance de base de données de secours. Ce type de déploiement est appelé déploiement d'instance de base de données multi-AZ. Amazon RDS utilise plusieurs technologies différentes pour fournir cette prise en charge du basculement. Les déploiements multi-AZ pour les instances de base de données MariaDB, MySQL, Oracle, PostgreSQL et RDS Custom for SQL Server utilisent la technologie de basculement Amazon. Les instances de base de données Microsoft SQL Server utilisent la mise en miroir de base de données SQL Server (DBM) ou les groupes de disponibilité AlwaysOn. Pour en savoir plus sur la prise en charge des versions de SQL Server pour les déploiements multi-AZ, consultez Déploiements multi-AZ pour Amazon RDS for Microsoft SQL Server. Pour plus d'informations sur l'utilisation de RDS Custom for SQL Server pour les déploiements multi-AZ, consultez Gestion d'un déploiement multi-AZ pour RDS Custom for SQL Server.
Dans un déploiement d'instance de base de données multi-AZ, Amazon RDS alloue et maintient automatiquement un réplica de secours synchrone dans une zone de disponibilité différente. L'instance de base de données primaire est répliquée de manière synchrone dans les zones de disponibilité sur un réplica de secours afin d'assurer une redondance des données et de limiter les pics de latence lors des sauvegardes système. L'exécution d'une instance de base de données en haute disponibilité peut améliorer la disponibilité pendant la maintenance planifiée du système. Elle peut également contribuer à protéger vos bases de données contre la défaillance d'une instance de base de données et la perturbation d'une zone de disponibilité. Pour plus d'informations sur les zones de disponibilité, consultez Régions, zones de disponibilité et zones locales.
Note
L'option de haute disponibilité n'est pas une solution de mise à l'échelle pour les scénarios de lecture seule. Vous ne pouvez pas utiliser un réplica de secours pour traiter le trafic en lecture. Pour traiter le trafic en lecture seule, utilisez plutôt un cluster de base de données multi-AZ ou un réplica en lecture. Pour plus d'informations sur les clusters de base de données multi-AZ, consultez Déploiements de clusters de base de données multi-AZ. Pour plus d'informations sur les réplicas en lecture, consultez Utilisation des réplicas en lecture d'instance de base de données.
À partir de la console RDS, vous pouvez créer un déploiement d'instance de base de données multi-AZ en spécifiant simplement l'option Multi-AZ au moment de créer une instance de base de données. Vous pouvez utiliser la console pour convertir des instances de base de données existantes en déploiements d'instance de base de données multi-AZ. Pour cela, vous devez modifier l'instance de base de données et spécifier l'option multi-AZ. Vous pouvez également spécifier un déploiement d'instance de base de données multi-AZ à l'aide de l' AWS CLI API Amazon RDS. Utilisez la commande create-db-instanceou modify-db-instanceCLI, ou l'opération d'API CreateDBInstance ou ModifyDBInstance.
La console RDS affiche la zone de disponibilité du réplica de secours (appelée zone de disponibilité secondaire). Vous pouvez également utiliser la commande describe-db-instancesCLI ou l'opération d'API DescribeDBInstances pour rechercher l'AZ secondaire.
Les instances de base de données qui utilisent des déploiements d'instance de base de données multi-AZ peuvent avoir une latence d'écriture et de validation accrue par rapport à un déploiement mono-AZ. Cela peut se produire en raison de la réplication de données synchrone qui se produit. La latence peut changer si votre déploiement bascule vers la réplique de secours, même si elle AWS est conçue avec une connectivité réseau à faible latence entre les zones de disponibilité. Pour les charges de travail de production, nous vous recommandons d'utiliser l'option IOPS provisionnés (opérations d'entrée/sortie par seconde) pour plus de rapidité et de constance sur le plan des performances. Pour plus d'informations sur les classes d'instance de base de données, veuillez consulter Classes d'instances de base de données .
Transformation d'une instance de base de données en déploiement d'instance de base de données multi-AZ
Si vous disposez d'une instance de base de données dans un déploiement mono-AZ et que vous en faites un déploiement d'instance de base de données multi-AZ (pour des moteurs autres qu'Amazon Aurora), Amazon RDS effectue plusieurs actions :
-
Prend un instantané des volumes Amazon Elastic Block Store (EBS) de l'instance de base de données principale.
-
Crée de nouveaux volumes pour le réplica en attente à partir de l'instantané. Ces volumes s'initialisent en arrière-plan, et les performances maximales du volume sont atteintes après l'initialisation complète des données.
-
Active la réplication synchrone au niveau des blocs entre les volumes des réplicas principal et secondaire.
Important
L'utilisation d'un instantané pour créer l'instance secondaire permet d'éviter les temps d'arrêt lors de la conversion de Mono-AZ à Multi-AZ, mais vous pouvez constater un impact sur les performances pendant et après la conversion vers Multi-AZ. Cet impact peut être significatif pour les charges de travail sensibles à la latence d'écriture.
Bien que cette fonctionnalité permette de restaurer rapidement des volumes importants à partir d'instantanés, elle peut entraîner une augmentation significative de la latence des opérations d'I/O en raison de la réplication synchrone. Cette latence peut avoir un impact sur les performances de votre base de données. Nous recommandons vivement, à titre de bonnes pratiques, de ne pas effectuer de conversion Multi-AZ sur une instance de base de données de production.
Pour éviter l'impact sur les performances de l'instance de base de données qui sert actuellement la charge de travail sensible, créez un réplica en lecture et activez les sauvegardes sur le réplica en lecture. Convertissez le réplica en lecture en Multi-AZ, et exécutez les requêtes qui chargent les données dans les volumes du réplica en lecture (sur les deux AZ). Ensuite, le réplica en lecture devient l'instance de base de données principale. Pour de plus amples informations, veuillez consulter Utilisation des réplicas en lecture d'instance de base de données.
Il existe deux façons de modifier une instance de base de données en déploiement d'instance de base de données multi-AZ :
Rubriques
Conversion en déploiement d'instance de base de données multi-AZ avec la console RDS
Vous pouvez utiliser la console RDS pour convertir une instance de base de données en déploiement d'instance de base de données multi-AZ.
Vous ne pouvez utiliser la console que pour finaliser la conversion. Pour utiliser l'API AWS CLI ou RDS, suivez les instructions deTransformation d'une instance de base de données en déploiement d'instance de base de données multi-AZ.
Pour effectuer une conversion en déploiement d'instance de base de données multi-AZ avec la console RDS
Connectez-vous à la console Amazon RDS AWS Management Console et ouvrez-la à l'adresse https://console.aws.amazon.com/rds/
. -
Dans le panneau de navigation, choisissez Bases de données, puis l'instance de base de données que vous souhaitez modifier.
-
Dans Actions, choisissez Convert to Multi-AZ deployment (Convertir en déploiement multi-AZ).
-
Sur la page de confirmation, choisissez Apply immediately (Appliquer immédiatement) pour appliquer les modifications immédiatement. Le choix de cette option n'entraîne pas d'interruption de service, mais il existe un impact possible sur les performances. Vous pouvez également choisir d'appliquer la mise à jour pendant le créneau de maintenance suivant. Pour de plus amples informations, veuillez consulter Paramètre des modifications du calendrier.
-
Choisissez Convert to Multi-AZ (Convertir en multi-AZ).
Transformation d'une instance de base de données en déploiement d'instance de base de données multi-AZ
Vous pouvez modifier une instance de base de données pour en faire un déploiement d'instance de base de données multi-AZ d'une des manières suivantes :
-
À l'aide de la console RDS, modifiez l'instance de base de données et définissez Multi-AZ deployment (Déploiement multi-AZ) sur Yes (Oui).
-
À l'aide de AWS CLI, appelez la modify-db-instancecommande et définissez l'
--multi-azoption. -
À l'aide de l'API RDS, appelez l'opération ModifyDBInstance et définissez le paramètre
MultiAZsurtrue.
Pour savoir comment modifier une instance de base de données, consultez Modification d'une instance de base de données Amazon RDS. Une fois la modification terminée, Amazon RDS déclenche un événement (RDS-EVENT-0025) qui indique que le processus est terminé. Vous pouvez contrôler les événements Amazon RDS. Pour plus d'informations sur les événements, consultez Utiliser la notification d'événements d'Amazon RDS.
Processus de basculement pour Amazon RDS
Si une interruption prévue ou imprévue de votre instance de base de données est le résultat d'une anomalie de l'infrastructure, Amazon RDS bascule automatiquement sur le réplica de secours d'une autre zone de disponibilité si vous avez activé l'option Multi-AZ. La durée du basculement dépend de l'activité de la base de données et d'autres conditions au moment où l'instance de base de données primaire est devenue indisponible. Les durées de basculement oscillent généralement entre 60 et 120 secondes. Cependant, les transactions importantes ou les processus de récupération longs peuvent augmenter le temps de basculement. 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é.
Note
Vous pouvez forcer le basculement manuel lorsque vous redémarrez une instance de base de données. Pour plus d'informations, consultez Redémarrage d'une instance de base de données.
É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. L'instance de base de données primaire bascule automatiquement vers le réplica de secours si l'une des conditions décrites dans le tableau suivant se produit : Vous pouvez consulter les raisons du basculement dans le journal des événements.
| Raison du basculement | Description |
|---|---|
Le système d'exploitation sous-jacent à l'instance de base de données RDS fait l'objet d'un correctif dans le cadre d'une opération hors connexion. |
Un basculement a été déclenché pendant la fenêtre de maintenance d'un correctif du système d'exploitation ou d'une mise à jour de sécurité. Pour plus d'informations, consultez Entretien d'une instance de base de données. |
L'hôte principal de l'instance RDS multi-AZ est non sain. |
Le déploiement d'instance de base de données multi-AZ a détecté une instance de base de données primaire déficiente et a opéré un basculement. |
L'hôte principal de l'instance RDS multi-AZ est inaccessible en raison d'une perte de connectivité réseau. |
La surveillance RDS a détecté une défaillance de la capacité d'accessibilité du réseau à l'instance de base de données primaire et a déclenché un basculement. |
L'instance RDS a été modifiée par le client. |
Une modification d'instance de base de données RDS a déclenché un basculement. Pour plus d'informations, consultez Modification d'une instance de base de données Amazon RDS. |
L'instance principale RDS multi-AZ est occupée et ne répond pas. |
L'instance de base de données primaire ne répond pas. Nous vous recommandons d'effectuer les opérations suivantes :
Pour plus d'informations sur ces recommandations, consultez la section Présentation de la surveillance des métriques dans Amazon RDS et Bonnes pratiques relatives à Amazon RDS.. |
Le volume de stockage sous-jacent à l'hôte principal de l'instance RDS multi-AZ a été défaillant. |
Le déploiement d'instance de base de données multi-AZ a détecté un problème de stockage sur l'instance de base de données primaire et a opéré un basculement. |
L'utilisateur a demandé un basculement de l'instance de base de données. |
Vous avez redémarré l'instance de base de données et choisi l'option Redémarrer avec basculement. Pour de plus amples informations, veuillez consulter Redémarrage d'une instance de base de données. |
Pour déterminer si votre instance 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 RDS ou d'opérations d'API.
Examinez l'état actuel de votre déploiement d'instance de base de données multi-AZ à l'aide de la console RDS ou d'opérations d'API.
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 en attente. 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 convertit un nom d'hôte en adresse IP, elle 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 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.
Vous pouvez obtenir la durée de vie par défaut de la JVM en récupérant la valeur de la propriété networkaddress.cache.ttl
String ttl = java.security.Security.getProperty("networkaddress.cache.ttl");
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
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.ttldans 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.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");
