Utilisation de la commutation ou du basculement dans une base de données globale Amazon Aurora

Une base de données globale Aurora fournit une protection de continuité des activités et de reprise après sinistre (BCDR) supérieure à la haute disponibilité standard fournie par un cluster de bases de données Aurora dans une Région AWS individuelle. En utilisant une base de données globale Aurora, vous pouvez planifier et effectuer une reprise rapide après de véritables catastrophes régionales ou des interruptions complètes de niveau de service. La reprise après sinistre est généralement axée sur les deux objectifs stratégiques suivants :

• Objectif de délai de reprise (RTO) : temps nécessaire à un système pour revenir à un état de fonctionnement après un sinistre ou une interruption de services. En d'autres termes, le RTO mesure les temps d'arrêt. Pour une base de données Aurora globale, le RTO peut être de l'ordre des minutes.

• Objectif de point de reprise (RPO) : quantité de données pouvant être perdue (mesurée dans le temps) après un sinistre ou une interruption de services. Cette perte de données est généralement due à un retard de réplication asynchrone. Pour une base de données Aurora globale, le RPO est généralement mesuré en secondes. Avec une base de données globale basée sur Aurora PostgreSQL–, vous pouvez utiliser le paramètre rds.global_db_rpo pour définir et suivre la limite supérieure du RPO, mais cela peut affecter le traitement des transactions sur le nœud d'écriture du cluster principal. Pour plus d’informations, consultez Gestion des RPO pour les bases de données globales basées sur Aurora PostgreSQL–.

La commutation ou le basculement d'une base de données globale Aurora implique la promotion d'un cluster de bases de données situé dans l'une des régions secondaires de votre base de données globale en tant que cluster de bases de données principal. Le terme « panne régionale » est couramment utilisé pour décrire divers scénarios de défaillance. Le pire des scénarios pourrait être une panne généralisée due à un événement catastrophique qui toucherait des centaines de kilomètres carrés. Toutefois, la plupart des pannes sont beaucoup plus localisées et ne concernent qu'un petit sous-ensemble de services cloud ou de systèmes clients. Tenez compte de toute l'étendue de la panne pour vous assurer que le basculement entre régions est la bonne solution et pour choisir la méthode de basculement adaptée à la situation. L'utilisation de l'approche de basculement ou de commutation dépend du scénario de panne spécifique :

• Basculement : utilisez cette approche pour récupérer après une panne imprévue. Avec cette approche, vous effectuez un basculement entre régions vers l'un des clusters de bases de données secondaires de votre base de données globale Aurora. Le RPO pour cette approche est généralement une valeur non nulle mesurée en secondes. L'ampleur de la perte de données dépend du délai global de réplication de la base de données Aurora Régions AWS au moment de la panne. Pour en savoir plus, veuillez consulter la section Reprise d'une base de données Amazon Aurora globale à partir d'une panne non planifiée.

• Commutation : cette opération était précédemment appelée « basculement planifié géré ». Utilisez cette approche pour les scénarios contrôlés, tels que la maintenance opérationnelle et d'autres procédures opérationnelles planifiées. Étant donné que cette fonction synchronise les clusters de base de données secondaires avec le cluster principal avant toute modification, le RPO est égal à 0 (aucune donnée perdue). Pour en savoir plus, veuillez consulter la section Réalisation de commutations pour les bases de données globales Amazon Aurora.

Note

Si vous souhaitez commuter ou basculer vers un cluster de bases de données Aurora secondaire sans tête, vous devez d'abord y ajouter une instance de base de données. Pour plus d'informations sur les clusters de bases de données sans tête, consultez Création d'un cluster de base de données Aurora sans tête dans une région secondaire.

Reprise d'une base de données Amazon Aurora globale à partir d'une panne non planifiée

En de très rares occasions, votre base de données Aurora globale peut rencontrer une interruption inattendue dans son Région AWS principale. Si cela se produit, votre cluster de bases de données Aurora principal et son nœud d'enregistreur ne sont pas disponibles, et la réplication entre les clusters de bases de données principal et secondaire s'interrompt. Pour minimiser les temps d'arrêt (RTO) et la perte de données (RPO), vous pouvez travailler rapidement pour effectuer un basculement entre régions.

Il existe deux méthodes pour basculer en cas de reprise après sinistre :

• Basculement géré : cette méthode est recommandée pour la reprise après sinistre. Lorsque vous utilisez cette méthode, Aurora réintègre automatiquement l'ancienne région principale dans la base de données globale en tant que région secondaire lorsqu'elle redevient disponible. Ainsi, la topologie d'origine de votre cluster global est conservée. Pour apprendre à utiliser cette méthode, consultez Réalisation de basculements gérés pour les bases de données globales Aurora.

• Basculement manuel : cette méthode alternative peut être utilisée quand le basculement géré n'est pas une option, par exemple quand vos régions principale et secondaire exécutent des versions de moteur incompatibles. Pour apprendre à utiliser cette méthode, consultez Réalisation de basculements manuels pour les bases de données globales Aurora.

Important

Les deux méthodes de basculement peuvent entraîner la perte de données de transaction d'écriture qui n'ont pas été répliquées dans la région secondaire choisie avant que le basculement se produise. Toutefois, le processus de récupération qui fait la promotion d'une instance de base de données sur le cluster de bases de données secondaire choisi comme instance de base de données principale d'enregistreur garantit que les données sont dans un état de cohérence transactionnelle.

Réalisation de basculements gérés pour les bases de données globales Aurora

Cette approche vise à assurer la continuité des activités dans le cas d'une véritable catastrophe régionale ou interruption complète du niveau de service.

Lors d'un basculement géré, votre cluster principal est basculé vers la région secondaire de votre choix tandis que la topologie de réplication existante de votre base de données globale Aurora est conservée. Le cluster secondaire choisi promeut l'un de ses nœuds en lecture seule au statut d'enregistreur complet. Cette étape permet au cluster d'endosser le rôle de cluster principal. Votre base de données est indisponible pendant une courte période pendant que ce cluster endosse son nouveau rôle. Les données qui n'ont pas été répliquées de l'ancien cluster principal vers le cluster secondaire choisi sont manquantes lorsque ce cluster secondaire devient le nouveau cluster principal.

Note

Vous ne pouvez effectuer un basculement de base de données entre régions géré sur une base de données globale Aurora que si les clusters de bases de données principal et secondaire possèdent les mêmes versions de moteur majeures, mineures et de niveaux de correctif. Cependant, les niveaux de correctif peuvent varier en fonction de la version mineure du moteur. Pour plus d’informations, consultez Compatibilité des niveaux de correctif pour les commutations ou basculements entre régions gérés. Si les versions de votre moteur sont incompatibles, vous pouvez effectuer le basculement manuellement en suivant les étapes décrites dans Réalisation de basculements manuels pour les bases de données globales Aurora.

Pour minimiser les pertes de données, nous vous recommandons de prendre les mesures suivantes avant d'utiliser cette fonctionnalité :

• Déconnectez les applications pour empêcher l'envoi d'écritures vers le cluster principal de la base de données Aurora globale.

• Vérifiez les temps de retard pour tous les clusters de bases de données Aurora secondaires de la base de données Aurora globale. Le choix de la région secondaire présentant le retard de réplication minimum peut minimiser les pertes de données avec la région principale actuellement défaillante. Pour toutes les bases de données globales basées sur Aurora PostgreSQL et pour les bases de données globales basées sur Aurora MySQL à partir des versions du moteur 3.04.0 et supérieures, ou 2.12.0 et supérieures, utilisez Amazon CloudWatch pour consulter la métrique pour tous les clusters de bases de données secondaires. AuroraGlobalDBRPOLag Pour les versions mineures inférieures des bases de données globales basées sur Aurora MySQL, consultez la métrique AuroraGlobalDBReplicationLag à la place. Ces métriques indiquent le retard (en millisecondes) de la réplication vers un cluster secondaire par rapport au cluster de bases de données principal.

  Pour plus d'informations sur CloudWatch les métriques pour Aurora, consultezMétriques de niveau cluster pour Amazon Aurora.

Au cours d'un basculement géré, le cluster de bases de données secondaire choisi est promu dans son nouveau rôle de cluster principal. Toutefois, il n'hérite pas des différentes options de configuration du cluster de base de données principal. Une incompatibilité de configuration peut provoquer des problèmes de performances, des incompatibilités de charge de travail et d'autres comportements anormaux. Pour éviter de tels problèmes, nous vous recommandons de résoudre les différences entre vos clusters de bases de données Aurora globales pour les cas suivants :

• Configurer le groupe de paramètres de cluster de base de données Aurora pour le nouveau cluster principal, si nécessaire – Vous pouvez configurer vos groupes de paramètres de cluster de base de données Aurora indépendamment pour chaque cluster Aurora de votre base de données Aurora globale. Par conséquent, lorsque vous promouvez un cluster de bases de données secondaire pour endosser le rôle de cluster principal, le groupe de paramètres du cluster secondaire peut être configuré différemment de celui du cluster principal. Si c'est le cas, modifiez le groupe de paramètres du cluster de base de données secondaire promu afin qu'il soit conforme aux paramètres de votre cluster principal. Pour savoir comment procéder, consultez Modification des paramètres d'une base de données Aurora globale.

• Configurez les outils et options de surveillance, tels que les CloudWatch événements et les alarmes Amazon : configurez le cluster de base de données promu avec la même capacité de journalisation, les mêmes alarmes, etc. que celles requises pour la base de données globale. Comme pour les groupes de paramètres, la configuration de ces fonctionnalités n'est pas héritée du cluster principal durant le processus de basculement. Certaines CloudWatch mesures, telles que le délai de réplication, ne sont disponibles que pour les régions secondaires. Ainsi, un basculement modifie la façon d'afficher ces métriques et de définir des alarmes sur celles-ci, et peut nécessiter d'apporter des modifications à des tableaux de bord prédéfinis. Pour plus d'informations sur les clusters de bases de données Aurora et la surveillance, consultez Présentation de la surveillance Amazon Aurora.

• Configurer les intégrations avec d'autres AWS services : si votre base de données globale Aurora s'intègre à des AWS services tels que AWS Secrets Manager Amazon S3 AWS Lambda, vous devez vous assurer que ceux-ci sont configurés selon vos besoins. AWS Identity and Access Management Pour plus d'informations sur l'intégration de bases de données Aurora globales avec IAM, Simple Storage Service (Amazon S3) et Lambda, veuillez consulter Utilisation des bases de données globales Amazon Aurora avec d'autres services AWS. Pour en savoir plus sur Secrets Manager, consultez Comment automatiser la réplication des secrets dans AWS Secrets Manager Across Régions AWS.

Généralement, le cluster secondaire choisi endosse le rôle principal en quelques minutes. Dès que le nœud d'enregistreur de la nouvelle région principale est disponible, vous pouvez y connecter vos applications et reprendre vos charges de travail. Une fois qu'Aurora a promu le nouveau cluster principal, il reconstruit automatiquement tous les clusters de régions secondaires supplémentaires.

Comme les bases de données globales Aurora utilisent la réplication asynchrone, le retard de réplication dans chaque région secondaire peut varier. Aurora reconstruit ces régions secondaires pour qu'elles disposent exactement des mêmes point-in-time données que le nouveau cluster de régions principal. La durée de la tâche de reconstruction complète peut prendre de quelques minutes à plusieurs heures, selon la taille du volume de stockage et la distance entre les régions. Lorsque les clusters des régions secondaires ont fini de se reconstruire à partir de la nouvelle région principale, ils sont disponibles pour un accès en lecture.

Dès que le nouvel enregistreur principal est promu et disponible, le cluster de la nouvelle région principale peut gérer les opérations de lecture et d'écriture pour la base de données globale Aurora. Veillez à modifier le point de terminaison de votre application pour utiliser le nouveau point de terminaison. Si vous avez accepté les noms fournis lors de la création de la base de données Aurora globale, vous pouvez modifier le point de terminaison en supprimant la chaîne -ro du point de terminaison du cluster promu dans votre application.

Par exemple, le point de terminaison du cluster secondaire my-global.cluster-ro-aaaaaabbbbbb.us-west-1.rds.amazonaws.com devient my-global.cluster-aaaaaabbbbbb.us-west-1.rds.amazonaws.com lorsque ce cluster est promu cluster principal.

Si vous utilisez un proxy RDS, assurez-vous de rediriger les opérations en écriture de votre application vers le point de terminaison en lecture/écriture approprié du proxy qui est associé au nouveau cluster principal. Ce point de terminaison du proxy peut être le point de terminaison par défaut ou un point de terminaison en lecture/écriture personnalisé. Pour plus d’informations, consultez Fonctionnement des points de terminaison du proxy RDS avec les bases de données globales.

Pour restaurer la topologie d'origine du cluster de bases de données global, Aurora surveille la disponibilité de l'ancienne région principale. Dès que cette région est saine et à nouveau disponible, Aurora l'ajoute automatiquement au cluster global en tant que région secondaire. Avant de créer le nouveau volume de stockage dans l'ancienne région principale, Aurora essaie de prendre un instantané de l'ancien volume de stockage au point de défaillance. Il le fait pour que vous puissiez l'utiliser pour récupérer les données manquantes. Si cette opération aboutit, Aurora place cet instantané nommé « rds : unplanned-global-failover - name-of-old-primary-DB-Cluster - timestamp » dans la section des instantanés du. AWS Management Console Vous pouvez également voir cet instantané répertorié dans les informations renvoyées par l'opération d'ClusterSnapshotsAPI DescribeDB.

Note

L'instantané de l'ancien volume de stockage est un instantané du système soumis à la période de conservation des sauvegardes configurée sur l'ancien cluster principal. Pour conserver cet instantané en dehors de la période de conservation, vous pouvez le copier pour l'enregistrer en tant qu'instantané manuel. Pour en savoir plus sur la copie des instantanés, y compris la tarification, consultez Copie d'un instantané de cluster de bases de données.

Une fois la topologie d'origine restaurée, vous pouvez rétablir votre base de données globale dans la région principale d'origine en effectuant une opération de commutation au moment qui convient le mieux à votre activité et à votre charge de travail. Pour ce faire, suivez les étapes de Réalisation de commutations pour les bases de données globales Amazon Aurora.

Vous pouvez basculer sur votre base de données globale Aurora à l'aide de l'API AWS Management Console, de AWS CLI, ou de l'API RDS.

Console

Pour effectuer le basculement géré sur votre base de données globale Aurora

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

2. Choisissez Databases (Bases de données) et recherchez la base de données Aurora globale que vous souhaitez basculer.

3. Choisissez Commuter ou basculer vers la base de données globale dans le menu Actions.

   

4. Choisissez Basculement (autoriser la perte de données).

   

5. Pour Nouveau cluster principal, choisissez un cluster actif dans l'un de vos clusters secondaires Régions AWS comme nouveau cluster principal.

6. Saisissez confirm, puis choisissez Confirmer.

Lorsque le basculement se termine, vous pouvez voir les clusters de bases de données Aurora et leur état actuel dans la liste Bases de données, comme illustré ci-dessous.

AWS CLI

Pour effectuer le basculement géré sur une base de données globale Aurora

Utilisez la commande failover-global-cluster de l'interface de ligne de commande pour basculer votre base de données Aurora globale. Avec la commande, passez les valeurs pour les paramètres suivants.

• --region— Spécifiez l' Région AWS endroit où s'exécute le cluster de base de données secondaire que vous souhaitez utiliser comme nouveau principal pour la base de données globale Aurora.

• --global-cluster-identifier – Spécifiez le nom de votre base de données Aurora globale.

• --target-db-cluster-identifier : spécifiez l'Amazon Resource Name (ARN) du cluster de bases de données Aurora que vous souhaitez promouvoir comme nouveau cluster principal pour la base de données globale Aurora.

• --allow-data-loss : faites-en explicitement une opération de basculement à la place d'une opération de commutation. Une opération de basculement peut entraîner une certaine perte de données si les composants de réplication asynchrone n'ont pas terminé d'envoyer toutes les données répliquées vers la région secondaire.

Pour LinuxmacOS, ou Unix :

aws rds --region region_of_selected_secondary \
   failover-global-cluster --global-cluster-identifier global_database_id \
   --target-db-cluster-identifier arn_of_secondary_to_promote \
   --allow-data-loss

Dans Windows :

aws rds --region region_of_selected_secondary ^
   failover-global-cluster --global-cluster-identifier global_database_id ^
   --target-db-cluster-identifier arn_of_secondary_to_promote ^
   --allow-data-loss

API RDS

Pour basculer sur une base de données globale Aurora, exécutez l'opération FailoverGlobalClusterAPI.

Réalisation de basculements manuels pour les bases de données globales Aurora

Dans certains scénarios, vous ne pourrez peut-être pas utiliser le processus de basculement géré. Par exemple, si vos clusters de bases de données principal et secondaire n'exécutent pas des versions de moteur compatibles. Dans ce cas, vous pouvez suivre ce processus manuel pour commuter votre base de données globale vers votre région secondaire cible.

Astuce

Nous vous recommandons de comprendre ce processus avant de l'utiliser. Ayez un plan prêt pour agir rapidement au premier signe de problème à l'échelle de la région. Vous pouvez être prêt à identifier la région secondaire présentant le moins de retard de réplication en utilisant Amazon CloudWatch régulièrement pour suivre les temps de latence des clusters secondaires. Veillez à tester votre plan pour vérifier que vos procédures sont complètes et précises, et que le personnel est formé pour effectuer un basculement de reprise après sinistre avant que le cas de figure se présente réellement.

Pour basculer manuellement vers un cluster secondaire après une panne imprévue dans la région principale

1. Arrêtez d'émettre des instructions DML et d'autres opérations d'écriture sur le cluster de base de données Aurora principal en cas de panne. Région AWS

2. Identifiez un cluster de base de données Aurora à partir d'un cluster de base de données secondaire Région AWS à utiliser comme nouveau cluster de base de données principal. Si votre base de données globale Aurora comporte Régions AWS au moins deux clusters secondaires, choisissez le cluster secondaire présentant le moins de retard de réplication.

3. Détachez le cluster de base de données secondaire choisi de la base de données Aurora globale.

   La suppression d'un cluster de base de données secondaire d'une base de données Aurora globale interrompt immédiatement la réplication du cluster principal vers le cluster secondaire et le promeut en cluster de base de données Aurora provisionné autonome avec des capacités complètes en lecture/écriture. Tous les autres clusters de bases de données Aurora secondaires associés au cluster principal dans la région concernée par la panne restent disponibles et peuvent accepter les appels de votre application. Ils consomment également des ressources. Puisque vous recréez la base de données Aurora globale, supprimez les autres clusters de bases de données secondaires avant de créer la nouvelle base de données Aurora globale dans les étapes suivantes. Cela évite les incohérences de données parmi les clusters de bases de données de la base de données Aurora globale (problèmes de split-brain).

   Afin d'obtenir les étapes détaillées du détachement, consultez Dissociation d'un cluster d'une base de données Amazon Aurora globale.

4. Reconfigurez votre application pour envoyer toutes les opérations d'écriture à ce cluster de base de données Aurora désormais autonome à l'aide de son nouveau point de terminaison. Si vous avez accepté les noms fournis lors de la création de la base de données Aurora globale, vous pouvez modifier le point de terminaison en supprimant la chaîne -ro du point de terminaison du cluster promu dans votre application.

   Par exemple, le point de terminaison du cluster secondaire my-global.cluster-ro-aaaaaabbbbbb.us-west-1.rds.amazonaws.com devient my-global.cluster-aaaaaabbbbbb.us-west-1.rds.amazonaws.com lorsque ce cluster est détaché de la base de données Aurora globale.

   Ce cluster de base de données Aurora devient le cluster principal d'une nouvelle base de données Aurora globale lorsque vous commencez à y ajouter des Régions lors de l'étape suivante.

   Si vous utilisez un proxy RDS, assurez-vous de rediriger les opérations en écriture de votre application vers le point de terminaison en lecture/écriture approprié du proxy qui est associé au nouveau cluster principal. Ce point de terminaison du proxy peut être le point de terminaison par défaut ou un point de terminaison en lecture/écriture personnalisé. Pour plus d’informations, consultez Fonctionnement des points de terminaison du proxy RDS avec les bases de données globales.

5. Ajoutez un Région AWS au cluster de base de données. Lorsque vous effectuez cette opération, le processus de réplication du cluster primaire vers le cluster secondaire commence. Afin d'obtenir les étapes détaillées pour ajouter une région, consultez Ajout d'une Région AWS à une base de données Amazon Aurora globale.

6. Ajoutez-en Régions AWS d'autres si nécessaire pour recréer la topologie requise pour prendre en charge votre application.

Assurez-vous que les écritures d'application sont envoyées au cluster de base de données Aurora approprié avant, pendant et après l'application de ces modifications. Cela évite les incohérences de données parmi les clusters de bases de données de la base de données Aurora globale (problèmes de split-brain).

Si vous l'avez reconfiguré en réponse à une panne dans un Région AWS, vous pouvez en faire à nouveau Région AWS le serveur principal une fois la panne résolue. Pour ce faire, vous ajoutez l'ancienne Région AWS à votre nouvelle base de données globale, puis vous utilisez le processus de commutation pour échanger son rôle. Votre base de données globale Aurora doit utiliser une version d'Aurora PostgreSQL ou d'Aurora MySQL qui prend en charge les commutations. Pour plus d’informations, consultez Réalisation de commutations pour les bases de données globales Amazon Aurora.

Réalisation de commutations pour les bases de données globales Amazon Aurora

Note

Les commutations étaient auparavant appelées « basculements planifiés gérés ».

En utilisant les switchovers, vous pouvez modifier régulièrement la région de votre cluster principal. Cette approche est destinée aux scénarios contrôlés tels que la maintenance opérationnelle et d'autres procédures opérationnelles planifiées.

Il existe trois cas d'utilisation courants pour l'utilisation des commutations.

• Pour les exigences de « rotation régionale » imposées à des secteurs spécifiques. Par exemple, la réglementation des services financiers peut exiger que les systèmes de niveau 0 passent à une autre région pendant plusieurs mois afin de garantir que les procédures de reprise après sinistre sont régulièrement mises à l'épreuve.

• Pour les applications « follow-the-sun » multirégionales. Par exemple, une entreprise peut souhaiter fournir une latence d'écriture plus faible dans différentes régions en fonction des heures d'ouverture dans différents fuseaux horaires.

• En tant que zero-data-loss méthode pour revenir à la région principale d'origine après un basculement.

Note

Les commutations sont conçues pour être utilisées sur une base de données globale Aurora saine. Pour récupérer après une panne imprévue, suivez la procédure appropriée dans Reprise d'une base de données Amazon Aurora globale à partir d'une panne non planifiée.

Pour effectuer une commutation, votre cluster de bases de données secondaire cible doit exécuter exactement la même version de moteur que le cluster principal, y compris le niveau de correctif, en fonction de la version du moteur. Pour plus d’informations, consultez Compatibilité des niveaux de correctif pour les commutations ou basculements entre régions gérés. Avant de commencer la commutation, vérifiez les versions du moteur de votre cluster global pour vous assurer qu'elles prennent en charge la commutation interrégionale gérée, et mettez-les à niveau si nécessaire.

Lors d'une commutation, Aurora commute votre cluster principal vers la région secondaire de votre choix tout en conservant la topologie de réplication existante de votre base de données globale. Avant de démarrer le processus de commutation, Aurora attend que tous les clusters des régions secondaires soient entièrement synchronisés avec le cluster de la région principale. Ensuite, le cluster de bases de données de la région principale passe en lecture seule et le cluster secondaire choisi promeut l'un de ses nœuds en lecture seule au statut d'enregistreur à part entière. La promotion de ce nœud au rang d'enregistreur permet à ce cluster secondaire d'endosser le rôle de cluster principal. Tous les clusters secondaires ayant été synchronisés avec le principal au début du processus, le nouveau cluster principal poursuit les opérations de la base de données Aurora globale sans perdre de données. Votre base de données est indisponible pendant une courte période durant laquelle les clusters principaux et secondaires sélectionnés endossent leurs nouveaux rôles.

Pour optimiser la disponibilité des applications, nous vous recommandons d'effectuer les opérations suivantes avant d'utiliser cette fonctionnalité :

• Effectuez cette opération pendant les heures creuses ou à tout autre moment où les écritures sur le cluster de base de données principal sont minimales.

• Déconnectez les applications pour empêcher l'envoi d'écritures vers le cluster principal de la base de données Aurora globale.

• Vérifiez les temps de retard pour tous les clusters de bases de données Aurora secondaires de la base de données Aurora globale. Pour toutes les bases de données globales basées sur Aurora PostgreSQL et pour les bases de données globales basées sur Aurora MySQL à partir des versions du moteur 3.04.0 et supérieures ou 2.12.0 et supérieures, utilisez Amazon CloudWatch pour consulter la métrique pour tous les clusters de bases de données secondaires. AuroraGlobalDBRPOLag Pour les versions mineures inférieures des bases de données globales basées sur Aurora MySQL, consultez la métrique AuroraGlobalDBReplicationLag à la place. Ces métriques indiquent le retard (en millisecondes) de la réplication vers un cluster secondaire par rapport au cluster de bases de données principal. Cette valeur est directement proportionnelle au temps nécessaire à Aurora pour terminer la commutation. Par conséquent, plus la valeur de retard est élevée, plus la commutation prendra de temps.

  Pour plus d'informations sur CloudWatch les métriques pour Aurora, consultezMétriques de niveau cluster pour Amazon Aurora.

Au cours d'une commutation, le cluster de bases de données secondaire choisi est promu dans son nouveau rôle de cluster principal. Toutefois, il n'hérite pas des différentes options de configuration du cluster de base de données principal. Une incompatibilité de configuration peut provoquer des problèmes de performances, des incompatibilités de charge de travail et d'autres comportements anormaux. Pour éviter de tels problèmes, nous vous recommandons de résoudre les différences entre vos clusters de bases de données Aurora globales pour les cas suivants :

• Configurer le groupe de paramètres de cluster de base de données Aurora pour le nouveau cluster principal, si nécessaire – Vous pouvez configurer vos groupes de paramètres de cluster de base de données Aurora indépendamment pour chaque cluster Aurora de votre base de données Aurora globale. Cela signifie que lorsque vous promouvez un cluster de base de données secondaire pour endosser le rôle de cluster principal, le groupe de paramètres du cluster secondaire peut être configuré différemment de celui du principal. Si c'est le cas, modifiez le groupe de paramètres du cluster de base de données secondaire promu afin qu'il soit conforme aux paramètres de votre cluster principal. Pour savoir comment procéder, consultez Modification des paramètres d'une base de données Aurora globale.

• Configurez les outils et options de surveillance, tels que les CloudWatch événements et les alarmes Amazon : configurez le cluster de base de données promu avec la même capacité de journalisation, les mêmes alarmes, etc. que celles requises pour la base de données globale. Comme pour les groupes de paramètres, la configuration de ces fonctionnalités n'est pas héritée du cluster principal durant le processus de commutation. Certaines CloudWatch mesures, telles que le délai de réplication, ne sont disponibles que pour les régions secondaires. Ainsi, une commutation modifie la façon d'afficher ces métriques et de définir des alarmes sur celles-ci, et peut nécessiter d'apporter des modifications à des tableaux de bord prédéfinis. Pour plus d'informations sur les clusters de bases de données Aurora et la surveillance, consultez Présentation de la surveillance Amazon Aurora.

• Configurez les intégrations avec d'autres AWS services : si votre base de données globale Aurora s'intègre à des AWS services tels que AWS Secrets Manager Amazon S3 AWS Lambda, assurez-vous de configurer vos intégrations avec ces services selon vos besoins. AWS Identity and Access Management Pour plus d'informations sur l'intégration de bases de données Aurora globales avec IAM, Simple Storage Service (Amazon S3) et Lambda, veuillez consulter Utilisation des bases de données globales Amazon Aurora avec d'autres services AWS. Pour en savoir plus sur Secrets Manager, consultez Comment automatiser la réplication des secrets dans AWS Secrets Manager Across Régions AWS.

Note

En général, la commutation de rôle peut prendre plusieurs minutes. Toutefois, la création de clusters secondaires supplémentaires peut prendre de quelques minutes à plusieurs heures, selon la taille de votre base de données et la distance physique entre les régions.

Lorsque le processus de commutation se termine, le cluster de bases de données Aurora promu peut traiter les opérations d'écriture pour la base de données globale Aurora. Veillez à modifier le point de terminaison de votre application pour utiliser le nouveau point de terminaison. Si vous avez accepté les noms fournis lors de la création de la base de données Aurora globale, vous pouvez modifier le point de terminaison en supprimant la chaîne -ro du point de terminaison du cluster promu dans votre application.

Par exemple, le point de terminaison du cluster secondaire my-global.cluster-ro-aaaaaabbbbbb.us-west-1.rds.amazonaws.com devient my-global.cluster-aaaaaabbbbbb.us-west-1.rds.amazonaws.com lorsque ce cluster est promu cluster principal.

Si vous utilisez un proxy RDS, assurez-vous de rediriger les opérations en écriture de votre application vers le point de terminaison en lecture/écriture approprié du proxy qui est associé au nouveau cluster principal. Ce point de terminaison du proxy peut être le point de terminaison par défaut ou un point de terminaison en lecture/écriture personnalisé. Pour plus d’informations, consultez Fonctionnement des points de terminaison du proxy RDS avec les bases de données globales.

Vous pouvez basculer entre votre base de données globale Aurora à l'aide de l'API AWS Management Console, de AWS CLI, ou de l'API RDS.

Console

Pour effectuer la commutation sur votre base de données globale Aurora

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

2. Choisissez Bases de données et recherchez la base de données globale Aurora que vous souhaitez commuter.

3. Choisissez Commuter ou basculer vers la base de données globale dans le menu Actions.

   

4. Choisissez Commutation.

   

5. Pour Nouveau cluster principal, choisissez un cluster actif dans l'un de vos clusters secondaires Régions AWS comme nouveau cluster principal.

6. Choisissez Confirmer.

Lorsque la commutation se termine, vous pouvez voir les clusters de bases de données Aurora et leurs rôles actuels dans la liste Bases de données, comme illustré dans l'image suivante.

AWS CLI

Pour effectuer la commutation sur une base de données globale Aurora

Utilisez la commande CLI switchover-global-cluster pour commuter vers votre base de données globale Aurora. Avec la commande, passez les valeurs pour les paramètres suivants.

• --region— Spécifiez l' Région AWS endroit où s'exécute le cluster de base de données principal de la base de données globale Aurora.

• --global-cluster-identifier – Spécifiez le nom de votre base de données Aurora globale.

• --target-db-cluster-identifier – Spécifiez l'Amazon Resource Name (ARN) du cluster de base de données Aurora que vous souhaitez promouvoir comme cluster principal pour la base de données Aurora globale.

Pour LinuxmacOS, ou Unix :

aws rds --region region_of_primary \
   switchover-global-cluster --global-cluster-identifier global_database_id \
  --target-db-cluster-identifier arn_of_secondary_to_promote

Dans Windows :

aws rds --region region_of_primary ^
   switchover-global-cluster --global-cluster-identifier global_database_id ^
  --target-db-cluster-identifier arn_of_secondary_to_promote

API RDS

Pour passer d'une base de données globale Aurora à une autre, exécutez l'opération SwitchoverGlobalClusterAPI.

Gestion des RPO pour les bases de données globales basées sur Aurora PostgreSQL–

Avec une base de données globale basée sur Aurora PostgreSQL, vous pouvez gérer l'objectif de point de reprise (RPO) de votre base de données globale Aurora à l'aide du paramètre rds.global_db_rpo. Le RPO représente la quantité maximale de données pouvant être perdue en cas de panne.

Lorsque vous définissez un RPO pour votre base de données globale basée sur Aurora PostgreSQL–, Aurora surveille le temps de retard RPO de tous les clusters secondaires pour vous assurer qu'au moins un cluster secondaire reste dans la fenêtre RPO cible. Le temps de retard RPO est une autre métrique basée sur le temps.

Le RPO est utilisé lorsque votre base de données reprend ses opérations dans une nouvelle base de données Région AWS après un basculement. Aurora évalue le RPO et les retards de RPO pour valider (ou bloquer) des transactions sur le cluster principal comme suit :

• Effectue la transaction si au moins un cluster de base de données secondaire a un temps de retard RPO inférieur au RPO.

• Bloque la transaction si tous les clusters de bases de données secondaires ont des temps de retard RPO supérieurs au RPO. Il enregistre également l'événement dans le fichier journal PostgreSQL et émet des événements « wait » qui montrent les sessions bloquées.

En d'autres termes, si tous les clusters secondaires prennent du retard sur le RPO cible, Aurora interrompt les transactions sur le cluster principal jusqu'à ce qu'au moins un des clusters secondaires le rattrape. Les transactions interrompues sont reprises et validées dès que le retard d'au moins un cluster de base de données secondaire devient inférieur au RPO. Par conséquent, aucune transaction ne peut être validée tant que le RPO n'est pas atteint.

Le paramètre rds.global_db_rpo est dynamique. Si vous décidez de ne pas bloquer toutes les transactions d'écriture jusqu'à ce que le retard diminue suffisamment, vous pouvez le réinitialiser rapidement. Dans ce cas, Aurora reconnaît et met en œuvre le changement après un court délai.

Important

Dans une base de données globale assortie de seulement deux régions, nous recommandons de conserver la valeur par défaut du paramètre rds.global_db_rpo dans le groupe de paramètres de la région secondaire. Dans le cas contraire, le basculement vers cette région à la suite de la perte de la région principale pourrait conduire Aurora à interrompre les transactions. Attendez plutôt qu'Aurora ait terminé la reconstruction du cluster dans l'ancienne région défaillante avant de modifier ce paramètre, ceci afin d'appliquer un RPO maximal.

Si vous définissez ce paramètre comme indiqué ci-dessous, vous pouvez également surveiller les métriques qu'il génère. Vous pouvez le faire en utilisant psql ou un autre outil d'interrogation du cluster de base de données principal de la base de données Aurora globale et obtenir des informations détaillées sur les opérations de votre base de données globale basée sur Aurora PostgreSQL–. Pour savoir comment procéder, consultez Surveillance des bases de données globales basées sur Aurora PostgreSQL.

Rubriques

• Configuration de l'objectif de point de récupération
• Affichage de l'objectif de point de récupération
• Désactivation de l'objectif de point de récupération

Configuration de l'objectif de point de récupération

Le paramètre rds.global_db_rpo contrôle le paramètre RPO pour une base de données PostgreSQL. Ce paramètre est pris en charge par Aurora PostgreSQL. Les valeurs valides pour rds.global_db_rpo sont comprises entre 20 secondes et 2 147 483 647 secondes (68 ans). Choisissez une valeur réaliste pour répondre aux besoins de votre entreprise et à votre cas d'utilisation. Par exemple, si vous voulez prévoir jusqu'à 10 minutes pour votre RPO, définissez la valeur sur 600.

Vous pouvez définir cette valeur pour votre base de données globale basée sur Aurora PostgreSQL–à l'aide de l' AWS Management Console, de l' AWS CLI ou de l'API RDS.

Console

Pour définir le RPO

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

2. Choisissez le cluster principal de votre base de données Aurora globale et ouvrez l'onglet Configuration pour rechercher son groupe de paramètres de cluster de base de données. Par exemple, le groupe de paramètres par défaut pour un cluster de base de données principal exécutant Aurora PostgreSQL 11.7 est default.aurora-postgresql11.

   Les groupes de paramètres ne peuvent pas être modifiés directement. Au lieu de cela, procédez comme suit :

   • Créez un groupe de paramètres de cluster de base de données personnalisé en utilisant le groupe de paramètres par défaut approprié comme point de départ. Par exemple, créez un groupe de paramètres de cluster de base de données personnalisé basé sur le default.aurora-postgresql11.

   • Sur votre groupe de paramètres de bases de données personnalisé, définissez la valeur du paramètre rds.global_db_rpo pour répondre à votre cas d'utilisation. Les valeurs valides sont comprises entre 20 secondes et la valeur entière maximale 2 147 483 647 secondes (68 ans).

   • Appliquez le groupe de paramètres de cluster de base de données modifié à votre cluster de base de données Aurora.

Pour plus d’informations, consultez Modification de paramètres dans un groupe de paramètres de cluster de base de données.

AWS CLI

Pour définir le rds.global_db_rpo paramètre, utilisez la commande CLI modify-db-cluster-parameter-group. Dans la commande, spécifiez le nom du groupe de paramètres de votre cluster principal et les valeurs du paramètre RPO.

Dans l'exemple suivant, le RPO est défini sur 600 secondes (10 minutes) pour le groupe de paramètres du cluster de base de données principal appelé my_custom_global_parameter_group.

Pour LinuxmacOS, ou Unix :

aws rds modify-db-cluster-parameter-group \
    --db-cluster-parameter-group-name my_custom_global_parameter_group \
    --parameters "ParameterName=rds.global_db_rpo,ParameterValue=600,ApplyMethod=immediate"

Dans Windows :

aws rds modify-db-cluster-parameter-group ^
    --db-cluster-parameter-group-name my_custom_global_parameter_group ^
    --parameters "ParameterName=rds.global_db_rpo,ParameterValue=600,ApplyMethod=immediate"

API RDS

Pour modifier le rds.global_db_rpo paramètre, utilisez l'opération d'API Amazon RDS ModifyDB. ClusterParameterGroup

Affichage de l'objectif de point de récupération

L'objectif de point de récupération (RPO) d'une base de données globale est stocké dans le paramètre rds.global_db_rpo pour chaque cluster de base de données. Vous pouvez vous connecter au point de terminaison du cluster secondaire que vous souhaitez afficher et utiliser psql afin d'interroger l'instance pour cette valeur.

db-name=>show rds.global_db_rpo;

Si ce paramètre n'est pas défini, la requête renvoie le résultat suivant :

rds.global_db_rpo
-------------------
 -1
(1 row)

La réponse ci-dessous est renvoyée par un cluster de base de données secondaire pour lequel le paramètre RPO est défini sur 1 minute.

rds.global_db_rpo
-------------------
 60
(1 row)

Vous pouvez également utiliser l'interface de ligne de commande pour obtenir des valeurs afin de savoir si rds.global_db_rpo est actif sur l'un des clusters de bases de données Aurora en utilisant l'interface de ligne de commande pour obtenir les valeurs de tous les paramètres user du cluster.

Pour LinuxmacOS, ou Unix :

aws rds describe-db-cluster-parameters \
 --db-cluster-parameter-group-name lab-test-apg-global \
 --source user

Dans Windows :

aws rds describe-db-cluster-parameters ^
 --db-cluster-parameter-group-name lab-test-apg-global *
 --source user

La commande renvoie une sortie similaire à celle ci-dessous pour tous les paramètres user différents des paramètres de cluster de base de données default-engine ou system.

{
    "Parameters": [
        {
            "ParameterName": "rds.global_db_rpo",
            "ParameterValue": "60",
            "Description": "(s) Recovery point objective threshold, in seconds, that blocks user commits when it is violated.",
            "Source": "user",
            "ApplyType": "dynamic",
            "DataType": "integer",
            "AllowedValues": "20-2147483647",
            "IsModifiable": true,
            "ApplyMethod": "immediate",
            "SupportedEngineModes": [
                "provisioned"
            ]
        }
    ]
}

Pour en savoir plus sur l'affichage des paramètres du groupe de paramètres de cluster, consultez Affichage des valeurs de paramètres pour un groupe de paramètres de cluster de bases de données.

Désactivation de l'objectif de point de récupération

Pour désactiver le RPO, réinitialisez le paramètre rds.global_db_rpo. Vous pouvez réinitialiser les paramètres à l'aide de l'API AWS Management Console, de AWS CLI, ou de l'API RDS.

Console

Pour désactiver le RPO

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

2. Dans le volet de navigation, choisissez Groupes de paramètres.

3. Dans la liste, choisissez votre groupe de paramètres de cluster de base de données principal.

4. Choisissez Modifier les paramètres.

5. Sélectionnez la case en regard du paramètre rds.global_db_rpo.

6. Choisissez Réinitialiser.

7. Lorsque l'écran affiche Réinitialiser les paramètres dans le groupe de paramètres de base de données, choisissez Réinitialiser les paramètres.

Pour de plus amples informations sur la réinitialisation d'un paramètre avec la console, veuillez consulter Modification de paramètres dans un groupe de paramètres de cluster de base de données.

AWS CLI

Pour réinitialiser le rds.global_db_rpo paramètre, utilisez la commande reset-db-cluster-parameter-group.

Pour LinuxmacOS, ou Unix :

aws rds reset-db-cluster-parameter-group \
    --db-cluster-parameter-group-name global_db_cluster_parameter_group \
    --parameters "ParameterName=rds.global_db_rpo,ApplyMethod=immediate"

Dans Windows :

aws rds reset-db-cluster-parameter-group ^
    --db-cluster-parameter-group-name global_db_cluster_parameter_group ^
    --parameters "ParameterName=rds.global_db_rpo,ApplyMethod=immediate"

API RDS

Pour réinitialiser le rds.global_db_rpo paramètre, utilisez l'opération ResetDB ClusterParameterGroup de l'API Amazon RDS.