Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # Stati Aurora e macchine a stati Step Functions Questa sezione descrive i processi e le macchine a stati specifici per il failover e il failback dei cluster Amazon Aurora. I cluster sono configurati come database globale. **Nota** A scopo dimostrativo, questo esempio utilizza Aurora MySQL Compatible Edition. È possibile utilizzare passaggi simili per Aurora PostgreSQL Compatible Edition. ## Stato stazionario Nello stato stazionario, è stato creato un database globale compatibile con Amazon Aurora MySQL `dr-globaldb-cluster-mysql` () con due cluster DB. Il primo cluster DB (`db-cluster-01`) è stato creato nel sistema primario Regione AWS (`us-east-1`) per servire il carico di lavoro di lettura/scrittura. Il secondo cluster DB (`db-cluster-02`)**** è stato creato nella regione secondaria (`us-west-2`) per gestire il carico di lavoro di sola lettura. Oltre a fornire la soluzione DR, è possibile ridurre il carico sul cluster DB primario instradando le query di lettura dalle applicazioni al cluster DB secondario. Ciascuno di questi cluster contiene un'istanza di database denominata `dbcluster-01-use1-instance-1` e`dbcluster-02-usw2-instance-2`, rispettivamente. ## Stato dell'evento Utilizzando un database globale di Amazon Aurora, puoi pianificare e ripristinare i dati in caso di emergenza abbastanza rapidamente. Il ripristino in caso di emergenza viene in genere misurato utilizzando i valori di Recovery Time Objective (RTO) e Recovery Point Objective (RPO). Per ulteriori informazioni, consulta [Utilizzo dello switchover o del failover in un database globale Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-disaster-recovery.html). Con un database globale Aurora, esistono due diversi approcci al failover: + Switchover (failover pianificato gestito) + *Failover (failover manuale non pianificato o scollegamento e promozione)* ### Passaggio Lo switchover è destinato ad ambienti controllati, come la manutenzione operativa e altre procedure operative pianificate. Utilizzando un failover pianificato gestito, è possibile trasferire il cluster DB primario del database globale Aurora in una delle regioni secondarie. Poiché lo switchover attende che i cluster DB secondari siano sincronizzati con il database primario, l'RPO è 0 (nessuna perdita di dati). Per ulteriori informazioni, consulta [Esecuzione degli switchover per i database globali di Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-disaster-recovery.html#aurora-global-database-disaster-recovery.managed-failover). La macchina a `dr-orchestrator-stepfunction-FAILOVER` stati viene richiamata durante *lo stato dell'evento* per trasferire il cluster primario alla regione secondaria prescelta (). `us-west-2` Per eseguire lo switchover, effettuate le seguenti operazioni: 1. Accedi alla Console di gestione AWS. 1. Cambiate la regione nella regione DR ()`us-west-2`. 1. Vai a **Services** e scegli **Step Functions**. 1. Passa alla macchina a `dr-orchestrator-stepfunction-FAILOVER` stati. 1. Scegli **Avvia esecuzione** e inserisci il seguente codice JSON nella `Input - optional` sezione: ``` { "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" } } ] } ] } ``` 1. La macchina a `dr-orchestrator-stepfunction-FAILOVER` stati legge il tipo di risorsa come `PlannedFailoverAuroraMySQ` L e chiama la macchina a `dr-orchestrator-stepfunction-planned-Aurora-failover` stati per eseguire il failover del database globale Aurora. ![Diagramma della macchina a stati per. PlannedFailoverAurora](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/automate-dr-solution-relational-database/images/dr-orchestrator-stepfunction-planned-aurora-failover.jpg) 1. La macchina a `dr-orchestrator-stepfunction-planned-Aurora-failover` stati esegue i seguenti passaggi per passare al ruolo di database globale compatibile con Aurora MySQL. ![Diagramma della macchina a stati per il controllo dello stato del failover.](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/automate-dr-solution-relational-database/images/dr-orchestrator-stepfunction-planned-aurora-failover-switchover.jpg) [See the AWS documentation website for more details](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/automate-dr-solution-relational-database/aurora-state-machines.html) 1. Accedi alla console Amazon RDS. **In **Status**, i valori per il database globale Aurora cambieranno da **Disponibile** a **Commutazione** o Modifica.** 1. Una volta completata, la macchina a `dr-orchestrator-stepfunction-planned-Aurora-failover` stati invia un token di successo alla macchina a `dr-orchestrator-stepfunction-FAILOVER` stati. ![Diagramma della macchina a stati che mostra l'invio del token di successo.](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/automate-dr-solution-relational-database/images/dr-orchestrator-stepfunction-FAILOVER.jpg) 1. La macchina a `dr-orchestrator-stepfunction-FAILOVER` stati è completata. ![Diagramma della macchina a stati che mostra che la macchina a stati è completata.](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/automate-dr-solution-relational-database/images/dr-orchestrator-stepfunction-FAILOVER-completed.jpg) Sulla console, il ruolo del **cluster secondario (`dbcluster-02`) è ora cluster** **primario e il cluster** è pronto per servire carichi di lavoro di lettura/scrittura. **Il ruolo del cluster primario originale (`dbcluster-01`) è ora elencato come Cluster secondario.** ### Failover manuale non pianificato In rare occasioni, il database globale Aurora potrebbe subire un'interruzione imprevista del database primario. Regione AWS In questo caso, il cluster di database Aurora primario e il relativo nodo di scrittura non sono disponibili e la replica tra il cluster primario e i secondari cessa. Per ridurre al minimo sia i tempi di inattività (RTO) che la perdita di dati (RPO), lavora rapidamente per eseguire un failover tra regioni e ricostruire il database globale Aurora. Per ulteriori informazioni, consulta [Ripristino di un database globale Amazon Aurora da un'](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-disaster-recovery.html#aurora-global-database-failover)interruzione non pianificata. Per eseguire un failover non pianificato è necessario scollegare il cluster secondario dal database globale Aurora. Prima di eseguire il failover non pianificato, interrompi le scritture delle applicazioni sul cluster Aurora DB primario. Una volta completato correttamente il failover, riconfigura l'applicazione per la scrittura sul nuovo cluster DB primario. Questo approccio aiuta a prevenire la perdita di dati. Inoltre, aiuta a evitare incongruenze nei dati se il nodo di scrittura principale torna online durante il processo di failover. Per eseguire il failover non pianificato, chiamate la macchina a stati. `dr-orchestrator-stepfunction-FAILOVER` In questo esempio, il **cluster secondario** (`db-cluster-02`*)***** si trova nella regione DR (`us-west-2`) in stato stazionario. Per eseguire il failover, effettuate le seguenti operazioni: 1. Accedi alla console . 1. Cambiate la regione nella regione DR (`us-west-2`). 1. Vai a **Services** e scegli **Step Functions**. 1. Passa alla macchina a `dr-orchestrator-stepfunction-FAILOVER` stati. 1. *Scegli **Avvia esecuzione** e inserisci il seguente codice JSON nella `Input - optional` sezione, usando `UnPlannedFailoverAurora` come: `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" } } ] } ] } ``` 1. La macchina a `dr-orchestrator-stepfunction-FAILOVER` stati legge il tipo di risorsa `UnPlannedFailoverAuroraMySQL` e chiama l'operazione `Detach Cluster from Global Database` dalla macchina a `dr-orchestrator-stepfunction-unplanned-Aurora-failover` stati. ![Diagramma della macchina a stati con tipo di risorsa. UnPlannedFailoverAurora](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/automate-dr-solution-relational-database/images/manual-unplanned-aurora-failover.jpg) 1. L'`Detach Cluster from Global Database`attività scollega (rimuove) il cluster secondario dal database globale. ![Diagramma della macchina a stati per scollegare il cluster e inviare il token di successo.](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/automate-dr-solution-relational-database/images/manual-detach-cluster-task.jpg) 1. Il cluster secondario (`dbcluster-02`) viene promosso a diventare un cluster autonomo e può servire carichi di lavoro di lettura/scrittura. 1. La macchina a `dr-orchestrator-stepfunction-FAILOVER` stati è completata. ![Diagramma della macchina a stati che mostra l'operazione completata.](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/automate-dr-solution-relational-database/images/manual-failover-completed.jpg) 1. Il cluster secondario (`dbcluster-02`) viene scollegato dal database globale Aurora e diventa un cluster autonomo per servire il carico di lavoro di lettura/scrittura. 1. Riconfigura l'applicazione per inviare tutte le operazioni di scrittura a questo nuovo cluster Aurora DB autonomo utilizzando il suo nuovo endpoint del cluster. ## Failback Un failback riporta il database alla posizione principale originale (o nuova) dopo la risoluzione di un disastro (o di un evento pianificato). Una volta risolta l'interruzione non pianificata, potresti voler aggiungere nuovamente la tua regione principale precedente al database globale di Aurora. È necessario innanzitutto eliminare il cluster DB esistente dalla precedente regione primaria, creare un nuovo cluster DB dalla nuova regione primaria e quindi utilizzare il processo di failover pianificato gestito per passare al ruolo del nuovo cluster. Questa può essere considerata un'attività pianificata che è possibile eseguire durante le ore non di punta o nei fine settimana. È necessario [modificare manualmente il cluster Amazon Aurora DB](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Modifying.html) e disabilitarlo `DeletionProtection`**** prima di eseguire la macchina a `DR Orchestrator FAILBACK` stati dalla precedente regione primaria (`us-east-1`) perché è stata creata con. `DeletionProtection` DR Orchestrator Framework utilizza la macchina a `dr-orchestrator-stepfunction-FAILBACK` stati per automatizzare i passaggi per eliminare il cluster esistente e creare un nuovo cluster nella precedente regione primaria. Per disabilitarlo`DeletionProtection`, procedi come segue: 1. Accedi alla console . 1. Cambia la regione con la precedente regione principale (`us-east-1`). 1. Accedi alla console Amazon RDS, seleziona il nome del cluster (`dbcluster-01`) e scegli **Modifica**. 1. In **Protezione da eliminazione**, deseleziona la casella di controllo **Abilita protezione dall'eliminazione** e scegli **Continua**. 1. Scegli **Applica immediatamente**, quindi scegli **Modifica cluster**. La macchina a `DR Orchestrator FAILBACK` stati viene richiamata durante il processo di failback dalla precedente regione primaria ()`us-east-1`. Per eseguire il failback, effettuate le seguenti operazioni: 1. Accedi alla console . 1. Cambia la regione con la precedente regione principale (`us-east-1`). 1. Vai a **Servizi**, quindi scegli **Step Functions**. 1. Passa alla macchina a `DR Orchestrator FAILBACK` stati. 1. Scegli **Avvia esecuzione** e inserisci il seguente codice JSON nella `Input - optional` sezione: ``` { "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" } } ] } ] } ``` 1. La macchina a `DR Orchestrator FAILBACK` stati legge il tipo di risorsa come `CreateAuroraSecondaryDBCluster` e chiama la macchina a `dr-orchestrator-stepfunction-create-Aurora-Secondary-cluster` stati. ![Diagramma della macchina a stati che mostra il tipo di risorsa come. CreateAuroraSecondaryCluster](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/automate-dr-solution-relational-database/images/create-aurora-secondary-cluster.jpg) 1. La macchina a `dr-orchestrator-stepfunction-create-Aurora-Secondary-cluster` stati elimina il cluster esistente (`dbcluster-01`) dalla precedente regione primaria (`us-east-1`). ![Diagramma della macchina a stati dell'eliminazione del cluster esistente dal database globale.](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/automate-dr-solution-relational-database/images/delete-existing-aurora-cluster.jpg) 1. Dopo l'eliminazione del cluster (`dbcluster-01`), la macchina a stati crea un nuovo cluster (`dbcluster-01`) insieme all'istanza DB e si unisce al database globale Aurora come cluster secondario per servire carichi di lavoro di sola lettura. ![Diagramma della macchina a stati che mostra la creazione del cluster di database secondario.](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/automate-dr-solution-relational-database/images/create-new-aurora-cluster.jpg) 1. Una volta che il cluster secondario è disponibile, la `dr-orchestrator-stepfunction-create-Aurora-Secondary-cluster` macchina a stati viene completata e invia un token di successo alla macchina a `DR Orchestrator Failback` stati. ![Macchina a stati che mostra che il token di successo è stato inviato.](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/automate-dr-solution-relational-database/images/create-secondary-cluster-success-token.jpg) 1. La `dr-orchestrator-stepfunction-FAILBACK` macchina a stati è completata. ![Diagramma della macchina a stati di CreateAuroraSecondary DbCluster completato.](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/automate-dr-solution-relational-database/images/create-aurora-secondary-cluster-completed.jpg) 1. Puoi verificare il database globale Aurora sulla console Amazon RDS. [Se desideri trasferire il cluster DB primario su us-east-1, puoi seguire i passaggi indicati nella sezione Switchover.](#switchover)