As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Máquinas de estados do Aurora e Step Functions
Esta seção aborda as máquinas de processo e estado específicas para o failover e o failback dos clusters do Amazon Aurora. Os clusters são configurados como um banco de dados global.
**nota**
Para fins de demonstração, este exemplo usa a edição compatível com o Aurora MySQL. Você pode usar etapas semelhantes para a edição compatível com o Aurora PostgreSQL.
## Estado estacionário
No estado estável, um banco de dados global compatível com Amazon Aurora MySQL `dr-globaldb-cluster-mysql` () foi criado com dois clusters de banco de dados. O primeiro cluster de banco de dados (`db-cluster-01`) foi criado no primary Região da AWS (`us-east-1`) para atender à carga de trabalho de leitura/gravação. O segundo cluster de banco de dados (`db-cluster-02`)**** foi criado na região secundária (`us-west-2`) para atender à carga de trabalho somente para leitura.
Além de fornecer a solução de DR, você pode reduzir a carga em seu cluster de banco de dados primário roteando consultas de leitura de seus aplicativos para o cluster de banco de dados secundário. Cada um desses clusters contém uma instância de banco de dados chamada `dbcluster-01-use1-instance-1` e`dbcluster-02-usw2-instance-2`, respectivamente.
## Estado do evento
Ao usar um banco de dados global do Amazon Aurora, você pode planejar e se recuperar de um desastre com bastante rapidez. A recuperação de desastres geralmente é medida usando valores para objetivo de tempo de recuperação (RTO) e objetivo de ponto de recuperação (RPO). Para obter mais informações, consulte [Uso de alternância ou failover em um banco de dados global do Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-disaster-recovery.html).
Com um banco de dados global Aurora, há duas abordagens diferentes para o failover:
+ Transição (failover planejado gerenciado)
+ Failover (failover manual não planejado ou *desanexar* e promover)
### Transição
A transição é destinada a ambientes controlados, como manutenção operacional e outros procedimentos operacionais planejados. Ao usar um failover planejado gerenciado, você pode realocar o cluster de banco de dados principal do seu banco de dados global Aurora para uma das regiões secundárias. Como o switchover espera até que os clusters de banco de dados secundários sejam sincronizados com o banco de dados primário, o RPO é 0 (sem perda de dados). Para saber mais, consulte [Execução de transições para bancos de dados globais do Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-disaster-recovery.html#aurora-global-database-disaster-recovery.managed-failover).
A máquina de `dr-orchestrator-stepfunction-FAILOVER` estado é invocada durante o *estado do evento* para alternar seu cluster primário para a região secundária escolhida (`us-west-2`).
Para realizar a transição, faça o seguinte:
1. Faça login no Console de gerenciamento da AWS.
1. Altere a região para a região DR (`us-west-2`).
1. Navegue até **Services** e escolha **Step Functions**.
1. Navegue até a máquina de `dr-orchestrator-stepfunction-FAILOVER` estado.
1. Escolha **Iniciar execução** e insira o seguinte código JSON na `Input - optional` seção:
```
{
"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. A máquina de `dr-orchestrator-stepfunction-FAILOVER` estado lê o tipo de recurso como `PlannedFailoverAuroraMySQ` L e chama a máquina de `dr-orchestrator-stepfunction-planned-Aurora-failover` estado para fazer o failover do banco de dados global Aurora.
1. A máquina de `dr-orchestrator-stepfunction-planned-Aurora-failover` estado executa as etapas a seguir para alternar a função de banco de dados global compatível com o Aurora MySQL.
[See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/automate-dr-solution-relational-database/aurora-state-machines.html)
1. Navegue até o console do Amazon RDS. **Em **Status**, os valores do banco de dados global do Aurora mudarão de **Disponível** para **Alternância ou Modificação**.**
1. Depois que a máquina de `dr-orchestrator-stepfunction-planned-Aurora-failover` estado é concluída, ela envia um token de sucesso de volta para a máquina de `dr-orchestrator-stepfunction-FAILOVER` estado.
1. A máquina de `dr-orchestrator-stepfunction-FAILOVER` estado está concluída.
No console, a função do **cluster secundário (`dbcluster-02`) agora é cluster** **primário, e o cluster** está pronto para atender cargas de trabalho de leitura/gravação. A função do cluster primário original (`dbcluster-01`) agora está listada como **cluster secundário**.
### Failover manual não planejado
Em raras ocasiões, seu banco de dados global Aurora pode sofrer uma interrupção inesperada em seu banco de dados primário. Região da AWS Se isso acontecer, seu cluster de banco de dados Aurora primário e seu nó de gravador não estarão disponíveis, e a replicação entre o cluster primário e os secundários cessará. Para minimizar o tempo de inatividade (RTO) e a perda de dados (RPO), trabalhe rapidamente para realizar um failover entre regiões e reconstruir seu banco de dados global Aurora. Para obter mais informações, consulte [Recuperação de um banco de dados global do Amazon Aurora após uma interrupção não planejada](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-disaster-recovery.html#aurora-global-database-failover).
A execução de um failover não planejado exige que você separe seu cluster secundário do banco de dados global Aurora. Antes de realizar o failover não planejado, interrompa as gravações do aplicativo em seu cluster de banco de dados Aurora primário. Depois que o failover for concluído com êxito, reconfigure o aplicativo para gravar no novo cluster de banco de dados primário. Essa abordagem ajuda a evitar a perda de dados. Também ajuda a evitar inconsistências de dados se o nó do gravador primário voltar a ficar on-line durante o processo de failover.
Para realizar o failover não planejado, ligue para a máquina de `dr-orchestrator-stepfunction-FAILOVER` estado. Neste exemplo, o **cluster secundário** (`db-cluster-02`*)***** está na região DR (`us-west-2`) em estado estável.
Para realizar o failover, faça o seguinte:
1. Faça login no console do .
1. Altere a região para a região DR (`us-west-2`).
1. Navegue até **Services** e escolha **Step Functions**.
1. Navegue até a máquina de `dr-orchestrator-stepfunction-FAILOVER` estado.
1. *Escolha **Iniciar execução** e insira o seguinte código JSON na `Input - optional` seção, usando `UnPlannedFailoverAurora` como: `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. A máquina de `dr-orchestrator-stepfunction-FAILOVER` estado lê o tipo de recurso como `UnPlannedFailoverAuroraMySQL` e chama a tarefa `Detach Cluster from Global Database` da máquina de `dr-orchestrator-stepfunction-unplanned-Aurora-failover` estado.
1. A `Detach Cluster from Global Database` tarefa separa (remove) o cluster secundário do banco de dados global.
1. O cluster secundário (`dbcluster-02`) é promovido para se tornar um cluster independente e pode atender cargas de trabalho de leitura/gravação.
1. A máquina de `dr-orchestrator-stepfunction-FAILOVER` estado está concluída.
1. O cluster secundário (`dbcluster-02`) é separado do banco de dados global Aurora e se torna um cluster independente para atender à carga de trabalho de leitura/gravação.
1. Reconfigure seu aplicativo para enviar todas as operações de gravação para esse novo cluster de banco de dados Aurora independente usando seu novo endpoint de cluster.
## Failback
Um failback retorna seu banco de dados para o local principal original (ou novo) após a resolução de um desastre (ou evento programado). Quando a interrupção não planejada for resolvida, talvez você queira adicionar sua antiga região primária de volta ao banco de dados global da Aurora. Primeiro, você deve excluir o cluster de banco de dados existente da antiga região primária, criar um novo cluster de banco de dados da nova região primária e, em seguida, usar o processo de failover planejado gerenciado para mudar a função do novo cluster.
Isso pode ser considerado uma atividade planejada que você pode realizar fora do horário de pico ou em um fim de semana.
Você deve [modificar manualmente o cluster de banco de dados Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Modifying.html) e desativá-lo `DeletionProtection`**** antes de executar a máquina de `DR Orchestrator FAILBACK` estado da antiga região primária (`us-east-1`) porque ela foi criada com. `DeletionProtection`
O DR Orchestrator Framework usa a máquina de `dr-orchestrator-stepfunction-FAILBACK` estado para automatizar as etapas para excluir o cluster existente e criar um novo cluster na antiga região primária.
Para desativar`DeletionProtection`, faça o seguinte:
1. Faça login no console do .
1. Altere a região para a antiga região primária (`us-east-1`).
1. Navegue até o console do Amazon RDS, selecione o nome do cluster (`dbcluster-01`) e escolha **Modificar**.
1. **Em **Proteção contra exclusão**, desmarque a caixa de seleção **Ativar proteção contra exclusão** e escolha Continuar.**
1. Escolha **Aplicar imediatamente** e, em seguida, escolha **Modificar cluster**.
A máquina de `DR Orchestrator FAILBACK` estado é invocada durante o processo de failback da antiga região primária ()`us-east-1`.
Para realizar o failback, faça o seguinte:
1. Faça login no console do .
1. Altere a região para a antiga região primária (`us-east-1`).
1. Navegue até **Services** e escolha **Step Functions**.
1. Navegue até a máquina de `DR Orchestrator FAILBACK` estado.
1. Escolha **Iniciar execução** e insira o seguinte código JSON na `Input - optional` seção:
```
{
"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. A máquina de `DR Orchestrator FAILBACK` estado lê o tipo de recurso como `CreateAuroraSecondaryDBCluster` e chama a máquina de `dr-orchestrator-stepfunction-create-Aurora-Secondary-cluster` estado.
1. A máquina de `dr-orchestrator-stepfunction-create-Aurora-Secondary-cluster` estado exclui o cluster existente (`dbcluster-01`) da antiga região primária (`us-east-1`).
1. Depois que o cluster (`dbcluster-01`) é excluído, a máquina de estado cria um novo cluster (`dbcluster-01`) junto com a instância de banco de dados e se junta ao banco de dados global Aurora como cluster secundário para atender cargas de trabalho somente para leitura.
1. Depois que o cluster secundário estiver disponível, a máquina de `dr-orchestrator-stepfunction-create-Aurora-Secondary-cluster` estado será concluída e enviará um token de sucesso de volta para a máquina de `DR Orchestrator Failback` estado.
1. A máquina de `dr-orchestrator-stepfunction-FAILBACK` estado está concluída.
1. Você pode verificar o banco de dados global do Aurora no console do Amazon RDS.
[Se você quiser realocar o cluster de banco de dados primário para us-east-1, siga as etapas mencionadas na seção Switchover.](#switchover)