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

La fonction de base de données globale Aurora fournit une meilleure protection de continuité des activités et de reprise après sinistre (BCDR) que la haute disponibilité standard fournie par un cluster de base de données Aurora en un seul Région AWS. En utilisant la base de données mondiale Aurora, vous pouvez planifier une reprise plus rapide en cas de catastrophes régionales rares et imprévues ou en cas d'interruption rapide du niveau de service.

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

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 sectorielle suivante et la manière dont ces termes sont liés aux fonctionnalités de la base de données mondiale Aurora.

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

L'exécution d'un basculement ou d'un basculement avec Aurora Global Database implique de promouvoir un cluster de base de données secondaire en tant que cluster de base 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 :

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'un changement, Aurora fait du cluster de la région secondaire que vous avez choisie votre cluster principal. Le mécanisme de commutation 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 qu'Aurora ne lance le processus de commutation, elle attend que tous les clusters de régions secondaires soient entièrement synchronisés avec le cluster de régions principal. Ensuite, le cluster de base de données de la région principale devient en lecture seule. Le cluster secondaire choisi fait passer l'un de ses nœuds en lecture seule au statut d'écrivain complet, ce qui permet à ce cluster secondaire de jouer 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é :

Si vous utilisez le point de terminaison Aurora Global Database Writer, vous n'avez pas besoin de modifier 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 le fonctionnement complet de votre application.

Supposons que les connexions de vos applications utilisent le point de terminaison du cluster de l'ancien cluster principal, au lieu du point de terminaison global du rédacteur. Dans ce cas, assurez-vous de modifier les paramètres de connexion de votre application pour utiliser le point de terminaison du nouveau cluster principal. 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 le proxy RDS, veillez à rediriger les opérations d'écriture de votre application vers le point de read/write endpoint of the proxy that's associated with the new primary cluster. This proxy endpoint might be the default endpoint or a custom read/write terminaison approprié. Pour plus d'informations, voir Fonctionnement des points de terminaison du proxy RDS avec les bases de données globales.

Vous pouvez effectuer une commutation de base de données globale Aurora à l'aide de l'API, de AWS Management Console AWS CLI, ou de l'API RDS.

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 à https://console.aws.amazon.com/rds/l'adresse.

2. Choisissez Databases et recherchez la base de données globale Aurora dans laquelle vous souhaitez effectuer le basculement.

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'une de vos Régions AWS secondaires 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.

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 à https://console.aws.amazon.com/rds/l'adresse.

2. Choisissez Databases et recherchez la base de données globale Aurora dans laquelle vous souhaitez effectuer le basculement.

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'une de vos Régions AWS secondaires 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 commande switchover-global-cluster CLI pour effectuer une commutation pour la 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.

Dans 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

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

AWS CLI

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

Utilisez la commande switchover-global-cluster CLI pour effectuer une commutation pour la 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.

Dans 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

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 effectuer une commutation pour la base de données globale Aurora, exécutez l'opération SwitchoverGlobalClusterAPI.

API RDS

Pour effectuer une commutation pour la base de données globale Aurora, exécutez l'opération SwitchoverGlobalClusterAPI.

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 rencontrer une panne inattendue dans sa base de données principale Région AWS. 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.

Aurora Global Database propose 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.

Lors d'un basculement géré, le cluster secondaire de la région secondaire que vous avez choisie 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 est saine et à nouveau disponible, Aurora l'ajoute automatiquement au cluster mondial en tant que région secondaire. Ainsi, la topologie de réplication existante de votre base de données globale Aurora est 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 globale Aurora réplique les données de manière asynchrone, il est possible que toutes les transactions ne soient pas répliquées dans la AWS région secondaire choisie avant que celle-ci ne soit promue pour accepter les fonctionnalités complètes de lecture/écriture.

Pour garantir la cohérence des données, Aurora crée un nouveau volume de stockage pour l'ancienne région principale après sa restauration. Avant de créer le nouveau volume de stockage dans la AWS région, Aurora tente de prendre un instantané de l'ancien volume de stockage au point de défaillance. Ainsi, vous pouvez restaurer l'instantané et récupérer toutes 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 utiliser la describe-db-cluster-snapshots AWS CLI commande ou l'opération DescribeDBClusterSnapshots API 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. Nous appelons ce mécanisme « clôture 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 l'AZ dans une région, il est possible que le processus de délimitation des écritures ne réussisse 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 enregistre les événements sur le nouveau cluster principal. Pour en savoir plus sur ces événements, consultezÉvènements de cluster de base de données. Parce que l'écriture restreinte est une tentative de tous les moyens, il est possible que les écritures soient momentanément acceptées dans l'ancienne région principale, ce qui provoquerait des problèmes de division cérébrale.

Nous vous recommandons d'effectuer les tâches suivantes avant d'effectuer un basculement avec Aurora Global Database. Cela permet de minimiser le risque de problèmes de division cérébrale 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 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 l'instance de base de données Writer 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.

Si vous utilisez le point de terminaison global, il n'est pas nécessaire de modifier 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 le fonctionnement complet 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 d'utiliser le point de terminaison du cluster de base de données principal récemment promu. 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 le proxy RDS, veillez à rediriger les opérations d'écriture de votre application vers le point de read/write endpoint of the proxy that's associated with the new primary cluster. This proxy endpoint might be the default endpoint or a custom read/write terminaison approprié. 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 aboutit, Aurora crée un instantané nommérds:unplanned-global-failover-name-of-old-primary-DB-cluster-timestamp. Vous pouvez trouver cet instantané dans la section Instantanés du AWS Management Console. Vous pouvez également voir cet instantané répertorié dans les informations renvoyées par l'opération d'API DBClusterDescribe 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 effectuer un basculement avec la base de données globale Aurora à l'aide de l'API AWS Management Console, de 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 console Amazon RDS AWS Management Console et ouvrez-la à https://console.aws.amazon.com/rds/l'adresse.

2. Choisissez Databases et recherchez la base de données globale Aurora dans laquelle vous souhaitez effectuer le basculement.

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'une de vos Régions AWS secondaires comme nouveau cluster principal.

6. Saisissez confirm, puis choisissez Confirmer.

Une fois le basculement terminé, vous pouvez afficher les clusters de base de données Aurora et leur état actuel dans la liste des bases de données, comme illustré dans l'image suivante.

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 à https://console.aws.amazon.com/rds/l'adresse.

2. Choisissez Databases et recherchez la base de données globale Aurora dans laquelle vous souhaitez effectuer le basculement.

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'une de vos Régions AWS secondaires comme nouveau cluster principal.

6. Saisissez confirm, puis choisissez Confirmer.

Une fois le basculement terminé, vous pouvez afficher les clusters de base de données Aurora et leur état actuel dans la liste des bases de données, comme illustré dans l'image suivante.

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

Utilisez la commande failover-global-cluster CLI pour effectuer un basculement avec la 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 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.

Dans 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

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

AWS CLI

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

Utilisez la commande failover-global-cluster CLI pour effectuer un basculement avec la 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 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.

Dans 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

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 effectuer un basculement avec Aurora Global Database, exécutez l'opération FailoverGlobalClusterAPI.

API RDS

Pour effectuer un basculement avec Aurora Global Database, 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 effectuer un basculement 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 base de données Région AWS à votre nouvelle base de données globale, puis vous utilisez le processus de commutation pour changer de 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 de plus amples informations, veuillez consulter Réalisation de commutations pour les bases de données globales Amazon Aurora.

Gestion des bases RPOs 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 :

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.

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 SQL basées sur Aurora Postgre.

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.

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"

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

Dans Linux, macOS, 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 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"

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"