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 meilleure protection en matière de continuité des activités et de reprise après sinistre (BCDR) que la haute disponibilité standard fournie par un cluster de bases de données Aurora en une seule solution Région AWS. 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 :

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 :

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 à la fois les temps d'arrêt (RTORPO) et les pertes de données (), vous pouvez effectuer rapidement un basculement entre régions.

Il existe deux méthodes pour basculer 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.

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.

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

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 :

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 RDS proxy, veillez à rediriger les opérations d'écriture de votre application vers le point de terminaison de lecture/écriture approprié du proxy 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, voir 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 est réussie, Aurora place cet instantané nommé « rds : - unplanned-global-failovername-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'APIopération D escribeDBCluster Snapshots.

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 en utilisant le AWS Management Console, le AWS CLI, ou le RDSAPI.

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

1. Connectez-vous à la RDS console Amazon 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.

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

Utilisez la failover-global-cluster CLI commande pour basculer sur 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 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 le nom de ressource Amazon (ARN) du cluster de base de données Aurora que vous souhaitez promouvoir en tant que nouveau serveur principal de 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

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

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.

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 Postgre SQL ou Aurora My SQL qui prend en charge les commutations. Pour de plus amples informations, veuillez consulter 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

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.

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

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 :

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 RDS proxy, veillez à rediriger les opérations d'écriture de votre application vers le point de terminaison de lecture/écriture approprié du proxy 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, voir Fonctionnement des points de terminaison du proxy RDS avec les bases de données globales.

Vous pouvez changer de base de données globale Aurora en utilisant le AWS Management Console, le AWS CLI, ou le RDSAPI.

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

1. Connectez-vous à la RDS console Amazon 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.

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

Utilisez la switchover-global-cluster CLI commande pour basculer entre 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 le nom de ressource Amazon (ARN) du cluster de base de données Aurora que vous souhaitez promouvoir comme principal pour la base de données globale Aurora.

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

Pour basculer entre une base de données globale Aurora, exécutez l'SwitchoverGlobalClusterAPIopération.

Gestion des RPOs bases de données globales SQL basées sur Aurora Postgre

Avec une base de données globale SQL basée sur Aurora Postgre, vous pouvez gérer l'objectif du point de récupération (RPO) pour votre base de données globale Aurora à l'aide du rds.global_db_rpo paramètre. RPOreprésente la quantité maximale de données susceptibles d'être perdues en cas de panne.

Lorsque vous définissez un RPO pour votre base de données globale SQL basée sur Aurora Postgre, Aurora surveille le temps de RPO latence de tous les clusters secondaires pour s'assurer qu'au moins un cluster secondaire reste dans la fenêtre cibleRPO. RPOle temps de latence 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 RPO et retarde RPO les délais pour valider (ou bloquer) les transactions sur le serveur principal comme suit :

En d'autres termes, si tous les clusters secondaires sont en retard par rapport à la cibleRPO, Aurora suspend les transactions sur le cluster principal jusqu'à ce qu'au moins un des clusters secondaires rattrape son retard. Les transactions suspendues sont reprises et validées dès que le délai d'au moins un cluster de base de données secondaire devient inférieur à. RPO Il en résulte qu'aucune transaction ne peut être validée tant que le seuil n'RPOest 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 un autre outil pour interroger le cluster de base de données principal de la base de données globale Aurora et obtenir des informations détaillées sur les opérations de votre base de données globale SQL basée sur Aurora Postgre. Pour savoir comment procéder, consultez Surveillance des bases de données globales SQL basées sur Aurora Postgre.

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

Le rds.global_db_rpo paramètre contrôle le RPO réglage d'une base de SQL données Postgre. 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, vous pouvez prévoir jusqu'à 10 minutes pour votreRPO, auquel cas vous définissez la valeur sur 600.

Vous pouvez définir cette valeur pour votre base de données globale SQL basée sur Aurora Postgre en utilisant le AWS Management Console AWS CLI, le ou le. RDS API

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 récupération

L'objectif du point de restauration (RPO) d'une base de données globale est stocké dans le rds.global_db_rpo paramètre de 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 suivante provient d'un cluster de base de données secondaire doté d'un RPO paramètre de 1 minute.

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

Vous pouvez également utiliser le pour CLI obtenir des valeurs permettant de savoir s'il rds.global_db_rpo est actif sur l'un des clusters de base de données Aurora en utilisant le CLI pour obtenir les valeurs de tous les user paramètres 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 base de données dans Amazon Aurora.

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

Pour le désactiverRPO, réinitialisez le rds.global_db_rpo paramètre. Vous pouvez réinitialiser les paramètres à l'aide du AWS Management Console AWS CLI, du ou du RDSAPI.

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"