Machines d'état Aurora et Step Functions

Cette section couvre les processus et les machines d'état spécifiques au basculement et au retour en panne des clusters Amazon Aurora. Les clusters sont configurés en tant que base de données globale.

Note

À des fins de démonstration, cet exemple utilise Aurora MySQL Compatible Edition. Vous pouvez suivre des étapes similaires pour Aurora PostgreSQL Compatible Edition.

État stable

À l'état stable, une base de données globale compatible avec Amazon Aurora MySQL (dr-globaldb-cluster-mysql) a été créée avec deux clusters de bases de données. Le premier cluster de base de données (db-cluster-01) a été créé dans le cluster principal Région AWS (us-east-1) pour répondre à la charge de travail de lecture/écriture. Le deuxième cluster de base de données (db-cluster-02) a été créé dans la région secondaire (us-west-2) pour servir la charge de travail en lecture seule.

En plus de fournir la solution DR, vous pouvez réduire la charge sur votre cluster de base de données principal en acheminant les requêtes de lecture de vos applications vers le cluster de base de données secondaire. Chacun de ces clusters contient une instance de base de données appelée dbcluster-01-use1-instance-1 etdbcluster-02-usw2-instance-2, respectivement.

État de l'événement

À l'aide d'une base de données mondiale Amazon Aurora, vous pouvez planifier et reprendre vos activités en cas de sinistre assez rapidement. La reprise après sinistre est généralement mesurée à l'aide des valeurs de l'objectif de temps de restauration (RTO) et de l'objectif du point de reprise (RPO). Pour plus d'informations, consultez Utilisation du basculement ou du basculement dans une base de données globale Amazon Aurora.

Avec une base de données globale Aurora, il existe deux approches différentes pour le basculement :

• Basculement (basculement planifié géré)

• Basculement (basculement manuel non planifié, ou détachement et promotion)

Basculement

Le passage au numérique est destiné aux environnements contrôlés, tels que la maintenance opérationnelle et les autres procédures opérationnelles planifiées. En utilisant un basculement planifié géré, vous pouvez déplacer le cluster de base de données principal de votre base de données globale Aurora vers l'une des régions secondaires. Comme le basculement attend que les clusters de base de données secondaires soient synchronisés avec la base de données principale, le RPO est égal à 0 (aucune perte de données). Pour en savoir plus, consultez la section Effectuer des commutations pour les bases de données mondiales Amazon Aurora.

La machine dr-orchestrator-stepfunction-FAILOVER d'état est invoquée pendant l'état de l'événement pour faire basculer votre cluster principal vers la région secondaire que vous avez choisie (us-west-2).

Pour effectuer le basculement, procédez comme suit :

1. Connectez-vous au AWS Management Console.

2. Remplacez la région par la région DR (us-west-2).

3. Accédez à Services, puis sélectionnez Step Functions.

4. Accédez à la machine à dr-orchestrator-stepfunction-FAILOVER états.

5. Choisissez Démarrer l'exécution, puis entrez le code JSON suivant dans la Input - optional section :

   {
     "StatePayload": [
       {
         "layer": 1,
         "resources": [
           {
             "resourceType": "PlannedFailoverAurora",
             "resourceName": "Switchover (planned failover) of Amazon Aurora global databases (MySQL)",
             "parameters": {
               "GlobalClusterIdentifier": "!Import dr-globaldb-cluster-mysql-global-identifier",
               "DBClusterIdentifier": "!Import dr-globaldb-cluster-mysql-cluster-identifier" 
             }
           }
         ]
       }
     ]
   }

6. La machine dr-orchestrator-stepfunction-FAILOVER d'état lit le type de ressource PlannedFailoverAuroraMySQ L et appelle la machine d'dr-orchestrator-stepfunction-planned-Aurora-failoverétat pour qu'elle bascule sur la base de données globale Aurora.

   

7. La machine dr-orchestrator-stepfunction-planned-Aurora-failover d'état exécute les étapes suivantes pour passer du rôle de base de données globale compatible Aurora MySQL.

   

   Étape	Description	Valeurs attendues
   Résoudre les importations	Une fonction Lambda remplace !Import <variable name> les valeurs par le nom réel.	"!Import dr-globaldb-cluster-mysql-global-identifier"est remplacé par "dr-globaldb-cluster-mysql".
   Cluster mondial Failover Aurora	Une fonction Lambda appelle les API Boto3 failover_global_cluster pour qu'elles survolent la base de données globale Aurora.	{ 'GlobalCluster': { 'GlobalClusterIdentifier': 'dr-globaldb-cluster-mysql', 'GlobalClusterResourceId': 'cluster-cce7f9bec2846db4', 'GlobalClusterArn': 'arn:aws:rds::xxx', 'Status': 'failing-over', .... .... } }
   Vérifier l'état du basculement	Une fonction Lambda appelle les API Boto3 describe_db_clusters pour vérifier l'état du basculement.	modificatif, disponible
   Envoyer des jetons de réussite	Une fonction Lambda appelle les API Boto3 send_task_success et renvoie un jeton de réussite à la machine d'état. DR Orchestrator Failover	H7x /83P1e0 K9MBvKZSP7D9YRT1W RiCdLtd dMccoxlzFhglsdkzp

8. Accédez à la console Amazon RDS. Sous Status, les valeurs de la base de données globale Aurora passeront de Disponible à Switching over ou Modifying.

9. Une fois que la machine dr-orchestrator-stepfunction-planned-Aurora-failover d'état est terminée, elle renvoie un jeton de réussite à la machine dr-orchestrator-stepfunction-FAILOVER d'état.

   

10. La machine à dr-orchestrator-stepfunction-FAILOVER états est terminée.

    

Sur la console, le rôle du cluster secondaire (dbcluster-02) est désormais le cluster principal, et le cluster est prêt à traiter des charges de travail en lecture/écriture. Le rôle du cluster principal d'origine (dbcluster-01) est désormais répertorié comme cluster secondaire.

Basculement manuel non planifié

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 base de données Aurora principal et son nœud de scripteur ne sont pas disponibles, et la réplication entre le cluster principal et les clusters secondaires s'interrompt. Pour minimiser à la fois les temps d'arrêt (RTO) et les pertes de données (RPO), effectuez rapidement un basculement entre régions et reconstruisez votre base de données globale Aurora. Pour plus d'informations, consultez Restaurer une base de données globale Amazon Aurora suite à une panne imprévue.

Pour effectuer un basculement imprévu, vous devez détacher votre cluster secondaire de la base de données globale Aurora. Avant d'effectuer le basculement imprévu, arrêtez les écritures d'applications sur votre cluster de base de données Aurora principal. Une fois le basculement effectué avec succès, reconfigurez l'application pour écrire sur le nouveau cluster de base de données principal. Cette approche permet d'éviter les pertes de données. Cela permet également d'éviter les incohérences dans les données si le nœud d'écriture principal revient en ligne pendant le processus de basculement.

Pour effectuer le basculement imprévu, appelez la machine d'dr-orchestrator-stepfunction-FAILOVERétat. Pour cet exemple, le cluster secondaire (db-cluster-02) se trouve dans la région DR (us-west-2) à l'état stable.

Pour effectuer le basculement, procédez comme suit :

1. Connectez-vous à la console.

2. Remplacez la région par la région DR (us-west-2).

3. Accédez à Services, puis sélectionnez Step Functions.

4. Accédez à la machine à dr-orchestrator-stepfunction-FAILOVER états.

5. Choisissez Démarrer l'exécution, puis entrez le code JSON suivant dans la Input - optional section, en utilisant UnPlannedFailoverAurora comme suit resourceType :

   {
     "StatePayload": [
       {
         "layer": 1,
         "resources": [
           {
             "resourceType": "UnPlannedFailoverAurora",
             "resourceName": "Performing unplanned failover for Amazon Aurora global databases (MySQL)",
             "parameters": {
               "GlobalClusterIdentifier": "!Import dr-globaldb-cluster-mysql-global-identifier",
               "DBClusterIdentifier": "!Import dr-globaldb-cluster-mysql-cluster-identifier",
               "ClusterRegion": "!Import dr-globaldb-cluster-mysql-cluster-region"
             }
           }
         ]
       }
     ]
   }
   

6. La machine dr-orchestrator-stepfunction-FAILOVER d'état lit le type de ressource UnPlannedFailoverAuroraMySQL et appelle la tâche Detach Cluster from Global Database depuis la machine dr-orchestrator-stepfunction-unplanned-Aurora-failover d'état.

   

7. La Detach Cluster from Global Database tâche détache (supprime) le cluster secondaire de la base de données globale.

   

8. Le cluster secondaire (dbcluster-02) est promu au rang de cluster autonome, et il peut prendre en charge des charges de travail en lecture/écriture.

9. La machine à dr-orchestrator-stepfunction-FAILOVER états est terminée.

   

10. Le cluster secondaire (dbcluster-02) est détaché de la base de données globale Aurora et devient un cluster autonome pour répondre à la charge de travail de lecture/écriture.

11. Reconfigurez votre application pour envoyer toutes les opérations d'écriture à ce nouveau cluster de base de données Aurora autonome à l'aide de son nouveau point de terminaison de cluster.

Failback

Un retour de secours ramène votre base de données à son emplacement principal d'origine (ou à son nouvel emplacement) après la résolution d'un sinistre (ou d'un événement planifié). Lorsque la panne imprévue aura été résolue, vous souhaiterez peut-être ajouter à nouveau votre ancienne région principale à la base de données mondiale Aurora. Vous devez d'abord supprimer le cluster de base de données existant de l'ancienne région principale, créer un nouveau cluster de base de données à partir de la nouvelle région principale, puis utiliser le processus de basculement planifié géré pour changer le rôle du nouveau cluster.

Cela peut être considéré comme une activité planifiée que vous pouvez effectuer en dehors des heures de pointe ou le week-end.

Vous devez modifier manuellement le cluster de base de données Amazon Aurora et le désactiver DeletionProtection avant d'exécuter la machine d'DR Orchestrator FAILBACKétat depuis l'ancienne région principale (us-east-1), car elle a été créée avecDeletionProtection.

DR Orchestrator Framework utilise la machine à dr-orchestrator-stepfunction-FAILBACK états pour automatiser les étapes de suppression du cluster existant et de création d'un nouveau cluster dans l'ancienne région principale.

Pour le désactiverDeletionProtection, procédez comme suit :

1. Connectez-vous à la console.

2. Remplacez la région par l'ancienne région principale (us-east-1).

3. Accédez à la console Amazon RDS, sélectionnez le nom du cluster (dbcluster-01), puis choisissez Modifier.

4. Sous Protection contre la suppression, décochez la case Activer la protection contre la suppression, puis choisissez Continuer.

5. Choisissez Appliquer immédiatement, puis Modifier le cluster.

La machine DR Orchestrator FAILBACK d'état est invoquée pendant le processus de repli depuis l'ancienne région principale (us-east-1).

Pour effectuer le retour en arrière, procédez comme suit :

1. Connectez-vous à la console.

2. Remplacez la région par l'ancienne région principale (us-east-1).

3. Accédez à Services, puis sélectionnez Step Functions.

4. Accédez à la machine à DR Orchestrator FAILBACK états.

5. Choisissez Démarrer l'exécution, puis entrez le code JSON suivant dans la Input - optional section :

    {
     "StatePayload": [
       {
         "layer": 1,
         "resources": [
           {
             "resourceType": "CreateAuroraSecondaryDBCluster",
             "resourceName": "To create secondary Aurora MySQL Global Database Cluster",
             "parameters": {
               "GlobalClusterIdentifier": "!Import dr-globaldb-cluster-mysql-global-identifier",
               "DBClusterIdentifier": "!Import dr-globaldb-cluster-mysql-cluster-identifier",
               "DBClusterName": "!Import dr-globaldb-cluster-mysql-cluster-name",
               "SourceDBClusterIdentifier": "!Import dr-globaldb-cluster-mysql-source-cluster-identifier",
               "DBInstanceIdentifier": "!Import dr-globaldb-cluster-mysql-instance-identifier",
               "Port": "!Import dr-globaldb-cluster-mysql-port",
               "DBInstanceClass": "!Import dr-globaldb-cluster-mysql-instance-class",
               "DBSubnetGroupName": "!Import dr-globaldb-cluster-mysql-subnet-group-name",
               "VpcSecurityGroupIds": "!Import dr-globaldb-cluster-mysql-vpc-security-group-ids",
               "Engine": "!Import dr-globaldb-cluster-mysql-engine",
               "EngineVersion": "!Import dr-globaldb-cluster-mysql-engine-version",
               "KmsKeyId": "!Import dr-globaldb-cluster-mysql-KmsKeyId",
               "SourceRegion": "!Import dr-globaldb-cluster-mysql-source-region",
               "ClusterRegion": "!Import dr-globaldb-cluster-mysql-cluster-region",
               "BackupRetentionPeriod": "7",
               "MonitoringInterval": "60",
               "StorageEncrypted": "True",
               "EnableIAMDatabaseAuthentication": "True",
               "DeletionProtection": "True",
               "CopyTagsToSnapshot": "True",
               "AutoMinorVersionUpgrade": "True",
               "MonitoringRoleArn": "!Import rds-mysql-instance-RDSMonitoringRole"
             }
           }
         ]
       }
     ]
   }

6. La machine DR Orchestrator FAILBACK d'état lit le type de ressource commeCreateAuroraSecondaryDBCluster, et elle appelle la machine dr-orchestrator-stepfunction-create-Aurora-Secondary-cluster d'état.

   

7. La machine dr-orchestrator-stepfunction-create-Aurora-Secondary-cluster d'état supprime le cluster existant (dbcluster-01) de l'ancienne région principale (us-east-1).

   

8. Une fois le cluster (dbcluster-01) supprimé, la machine d'état crée un nouveau cluster (dbcluster-01) avec l'instance de base de données, et il rejoint la base de données globale Aurora en tant que cluster secondaire pour traiter les charges de travail en lecture seule.

   

9. Une fois que le cluster secondaire est disponible, la machine d'dr-orchestrator-stepfunction-create-Aurora-Secondary-clusterétat est terminée et renvoie un jeton de réussite à la machine DR Orchestrator Failback d'état.

   

10. La machine à dr-orchestrator-stepfunction-FAILBACK états est terminée.

    

11. Vous pouvez vérifier la base de données globale Aurora sur la console Amazon RDS.

Si vous souhaitez déplacer le cluster de base de données principal vers us-east-1, vous pouvez suivre les étapes mentionnées dans la section Switchover.