Utilisation de la bascule ou du basculement dans une base de données Amazon Aurora Global Database

Une base de données Aurora Global Database fournit une protection de la continuité des activités et de la 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. Avec une base de données Aurora Global Database, vous pouvez planifier et effectuer des reprises plus rapides après des incidents régionaux imprévus ou des pannes complètes de services.

Vous pouvez consulter les directives et procédures suivantes pour planifier, tester et mettre en œuvre votre stratégie BCDR à l’aide de la fonctionnalité de base de données Aurora Global Database.

Planification de la continuité des activités et de la reprise après sinistre

Pour planifier votre stratégie de continuité des activités et de reprise après sinistre, il est utile de comprendre la terminologie suivante et le lien entre ces termes et les fonctionnalités de la base de données Aurora Global Database.

La reprise après sinistre est généralement axée sur les deux objectifs stratégiques suivants :

L’exécution d’une bascule ou d’un basculement avec la base de données Aurora Global Database implique de promouvoir un cluster de bases de données secondaire 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 bascule dépend du scénario de panne spécifique :

Réalisation de bascules pour les bases de données Amazon Aurora Global Database

En utilisant les bascules, vous pouvez modifier de façon routinière 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 bascules.

Lors d’une bascule, Aurora fait du cluster de la région secondaire de votre choix le cluster principal. Le mécanisme de bascule conserve la topologie de réplication existante de votre base de données globale : elle possède toujours le même nombre de clusters Aurora dans les mêmes régions. Avant de démarrer le processus de bascule, 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 devient accessible en lecture seule. Le cluster secondaire choisi promeut l’un de ses nœuds en lecture seule à l’état d’enregistreur complet, ce qui permet au cluster d’endosser le rôle de cluster principal. Comme tous les clusters secondaires ont été synchronisés avec le cluster 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é :

Si vous utilisez le point de terminaison d’enregistreur Aurora Global Database, il n’est pas nécessaire de changer les paramètres de connexion dans votre application. Vérifiez que les modifications DNS se sont propagées et que vous pouvez vous connecter et effectuer des opérations d’écriture sur le nouveau cluster principal. Vous pouvez ensuite reprendre l’exécution complète de votre application.

Supposons que les connexions de votre application utilisent le point de terminaison de l’ancien cluster principal, au lieu du point de terminaison d’enregistreur global. Dans ce cas, assurez-vous de modifier les paramètres de connexion de votre application pour que le point de terminaison du nouveau cluster principal soit utilisé. 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 effectuer une opération de bascule de votre base de données Aurora Global Database à l’aide de la AWS Management Console, de l’interface AWS CLI ou de l’API RDS.

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

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

2. Choisissez Bases de données et recherchez la base de données globale Aurora pour laquelle vous souhaitez effectuer une opération de bascule.

3. Choisissez Passer ou basculer sur une base de données globale dans le menu Actions.

   

4. Choisissez Bascule.

   

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

6. Choisissez Confirmer.

Lorsque la bascule 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.

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

Utilisez la commande CLI switchover-global-cluster pour effectuer une bascule pour Aurora Global Database. Avec la commande, passez les valeurs pour les paramètres suivants.

• --region : spécifiez la Région AWS dans laquelle s’exécute le cluster de bases de données principal de la base de données Aurora globale.

• --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 cluster principal pour la base de données Aurora globale.

Pour Linux, macOS 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

Pour 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

Pour effectuer une opération de bascule pour une base de données Aurora Global Database, exécutez l’opération d’API SwitchoverGlobalCluster.

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

Dans de rares cas, votre base de données globale Aurora peut subir une panne inattendue dans sa 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 secondaires s’interrompt. Pour minimiser la durée d’indisponibilité (RTO) et la perte de données (RPO), vous pouvez travailler rapidement pour effectuer un basculement entre régions.

La base de données Aurora Global Database offre deux méthodes de basculement que vous pouvez utiliser en cas de reprise après sinistre :

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.

Au cours d’un basculement géré, le cluster secondaire de la région secondaire de votre choix devient le nouveau cluster principal. 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. Dès que cette ancienne région principale sera saine et à nouveau disponible, Aurora l’ajoutera automatiquement au cluster global en tant que région secondaire. Ainsi, la topologie de réplication existante de votre base de données globale Aurora sera conservée.

Le basculement géré n’attend pas que les données soient synchronisées entre la région secondaire choisie et la région principale actuelle. Dans la mesure où la base de données Aurora Global Database réplique les données de manière asynchrone, il est possible que toutes les transactions ne soient pas répliquées dans la région AWS secondaire choisie avant qu’elle ne soit promue pour accepter toutes les fonctionnalités de lecture/écriture.

Pour garantir la cohérence des données, Aurora crée un volume de stockage pour l’ancienne région principale après sa restauration. Avant de créer le volume de stockage dans la région AWS principale, Aurora essaie d’effectuer un instantané de l’ancien volume de stockage au point de défaillance. Vous pourrez ainsi restaurer l’instantané et 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 de la AWS Management Console. Vous pouvez également utiliser la commande describe-db-cluster-snapshots d’AWS CLI ou l’opération d’API DescribeDBClusterSnapshots pour voir les détails de l’instantané.

Lorsque vous lancez un basculement géré, Aurora tente également d’arrêter le trafic d’écriture via la couche de stockage Aurora hautement disponible. C’est ce que l’on appelle le « clôturage d’écriture ». Si le processus aboutit, Aurora émet un événement RDS vous indiquant que les écritures ont été arrêtées. Dans le cas peu probable de plusieurs défaillances de zone de disponibilité dans une région, il est possible que le processus de clôturage d’écriture n’aboutisse pas à temps. Dans ce cas, Aurora émet un événement RDS vous informant que le délai imparti pour arrêter les écritures a expiré. Si l’ancien cluster principal est accessible sur le réseau, Aurora y enregistre ces événements. Dans le cas contraire, Aurora les enregistre sur le nouveau cluster principal. Pour en savoir plus sur ces événements, consultez Événements de cluster de bases de données. Comme le clôturage d’écriture est une tentative exécutée dans la mesure du possible, il est possible que les écritures soient momentanément acceptées dans l’ancienne région principale, ce qui provoquerait des problèmes d’incohérence des données, ou split-brain.

Nous vous recommandons d’effectuer les tâches suivantes avant de procéder à un basculement avec une base de données Aurora Global Database. Cela permet de minimiser le risque d’incohérence des données ou de récupération de données non répliquées à partir de l’instantané de l’ancien cluster principal.

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 bases 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 :

Généralement, le cluster secondaire choisi endosse le rôle principal en quelques minutes. Dès que l’instance de base de données 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 données ponctuelles que le nouveau cluster de la région principale. 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.

Si vous utilisez le point de terminaison global, il n’est pas nécessaire de changer les paramètres de connexion dans votre application. Vérifiez que les modifications DNS se sont propagées et que vous pouvez vous connecter et effectuer des opérations d’écriture sur le nouveau cluster principal. Vous pouvez ensuite reprendre l’exécution complète de votre application.

Si vous n’utilisez pas le point de terminaison global, assurez-vous de modifier le point de terminaison de votre application afin que le point de terminaison du cluster de bases de données principal récemment promu soit utilisé. 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 crée un instantané nommé rds:unplanned-global-failover-name-of-old-primary-DB-cluster-timestamp. Vous trouverez cet instantané dans la section Instantanés de la AWS Management Console. Vous pouvez également voir cet instantané répertorié dans les informations renvoyées par l’opération d’API DescribeDBClusterSnapshots.

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 bascule au moment qui convient le mieux à votre activité et à votre charge de travail. Pour ce faire, suivez les étapes de Réalisation de bascules pour les bases de données Amazon Aurora Global Database.

Vous pouvez effectuer une opération de basculement de votre base de données Aurora Global Database à l’aide de la AWS Management Console, de l’interface AWS CLI ou de l’API RDS.

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

1. Connectez-vous à la AWS Management Console et ouvrez la console Amazon RDS à 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 basculer.

3. Choisissez Passer ou basculer sur une 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’une de vos Régions AWS secondaires comme nouveau cluster principal.

6. Saisissez confirm, puis choisissez Confirmer.

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

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

Utilisez la commande CLI failover-global-cluster pour basculer vers votre base de données Aurora Global Database. Avec la commande, passez les valeurs pour les paramètres suivants.

• --region : spécifiez la Région AWS où le cluster de bases de données secondaire que vous souhaitez utiliser comme nouveau cluster principal pour la base de données globale Aurora est en cours d’exécution.

• --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 bascule. 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 Linux, macOS 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

Pour 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

Pour effectuer un basculement avec Aurora Global Database, exécutez l’opération d’API FailoverGlobalCluster.

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 effectuer un basculement vers votre région secondaire cible.

Assurez-vous que les écritures d’application sont envoyées au cluster de bases 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 avez reconfiguré un système en réponse à une panne dans une Région AWS, vous pouvez faire de cette Région AWS le cluster principal une fois la panne résolue. Pour ce faire, ajoutez l’ancienne Région AWS à votre nouvelle base de données globale, puis utilisez le processus de bascule 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 bascules. Pour plus d’informations, consultez Réalisation de bascules pour les bases de données Amazon Aurora Global Database.

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

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

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

Configuration de l’objectif de point de reprise

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.

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"

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"

Affichage de l’objectif de point de reprise

L’objectif de point de reprise (RPO) d’une base de données globale est stocké dans le paramètre rds.global_db_rpo pour chaque cluster de bases 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 bases 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 Linux, macOS ou Unix :

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

Pour 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 bases 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 dans Amazon Aurora.

Désactivation de l’objectif de point de reprise

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

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"

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"