O Amazon Aurora Global Database foi desenvolvido para aplicativos de nuvem distribuídos globalmente na AWS. Ele oferece alta disponibilidade e resiliência de banco de dados por meio de sua capacidade de fazer failover para outra região da AWS. Ele permite que um banco de dados abranja várias regiões (a AWS limita as regiões a um máximo de seis) e consiste em uma região primária e até cinco regiões secundárias em um cluster de banco de dados global. A região primária pode executar operações de leitura e gravação, enquanto a segunda região pode executar apenas operações de leitura. A maneira como a AWS facilita esse recurso é ativando endpoints de gravador na região primária e desativando endpoints de gravador em regiões secundárias. Além disso, o Aurora replica dados da região primária para regiões secundárias, geralmente em menos de um segundo.
PRÉ-REQUISITOS
Para implantar esta solução, você deve ter os seguintes pré-requisitos:
- Uma conta da AWS.
- AWS CLI com permissões de administrador.
- Python 3, de preferência a versão mais recente.
- Conhecimento básico do AWS SDK para python (boto3).
- Conhecimento básico de modelos do CloudFormation.
- Conhecimento básico das funções Lambda e Step.
CRIANDO UM BANCO DE DADOS GLOBAL DO RDS
Para criar um banco de dados global do RDS, precisamos definir clusters de banco de dados globais e regionais. Em seguida, precisamos definir instâncias de banco de dados em cada cluster regional.
Vamos ter em mente que, para definir um banco de dados global RDS, precisamos Grupo de sub-rede, grupo de segurança RDS e grupo de parâmetros de banco de dados.
A representação de amostra de uma topologia do Amazon Aurora Global Database descrita acima envolve os seguintes componentes e recursos em sua configuração:
1. RDS Global Stack – Esta é a pilha base do CloudFormation (CFN) para criar RDS Aurora Global, clusters de banco de dados regionais e instâncias em cada cluster regional. Essa pilha define a sub-rede RDS, o cluster global e regional do banco de dados Lambda, o Step Function, a pilha de instâncias de banco de dados RDS do Lambda e o status da pilha CFN Lambda como recursos a serem criados.
2. Cluster global e regional de banco de dados Lambda – Este Lambda cria primeiro clusters de banco de dados regionais e, em seguida, cria um cluster de banco de dados global atribuindo os clusters regionais recém-criados ao cluster global.
3. Função Step – Esta máquina de estado é responsável por criar a pilha de instâncias do banco de dados como uma tarefa, aguardando e verificando o status desta tarefa até a conclusão.
4. RDS DB Instance Stack Lambda – Este Lambda é responsável por criar uma pilha do CloudFormation que cria instâncias de banco de dados.
5. CFN Stack Status Lambda – Este Lambda é responsável por verificar o status da pilha de instâncias do RDS e retornar o status para a Step Function.
CENÁRIO DE FAILOVER
Com o Aurora Global Database, pode-se esperar dois cenários de failover – failover planejado gerenciado e failover não planejado.
FALHA PLANEJADA GERENCIADA
Um cenário de failover planejado gerenciado funciona melhor quando ambas as regiões do cluster global estão em operação normal. Ao executar esta operação, o endpoint do gravador na região ativa é substituído por um endpoint do leitor. O vice-versa acontece na região passiva, ou seja, o endpoint do leitor na região passiva é substituído pelo endpoint do gravador. Isso garante que as regiões ativas e passivas sejam invertidas após a execução da operação de failover.
O failover planejado pode ser executado de várias maneiras. Algumas das formas são:
- Usando o console da AWS
- AWS CLI
- Scripts que usam o AWS SDK
FALHA NÃO PLANEJADA
Realizamos failover não planejado quando o cluster de banco de dados ativo atual fica inativo. As seguintes etapas precisam ser executadas:
- Remova o cluster de banco de dados da região passiva (região secundária) do cluster global. Depois de removê-lo do cluster de banco de dados global, ele funciona como um cluster de banco de dados autônomo e uma das instâncias de leitor se transforma em uma instância de gravador. Podemos atribuí-lo de volta ao cluster global, permitindo-nos realizar operações de gravação e leitura em um cluster de banco de dados autônomo.
- Exclua o cluster de banco de dados afetado, que estava sendo executado como um cluster ativo no banco de dados global quando a região afetada da AWS estiver operacional. Em seguida, atribua um cluster independente ao banco de dados global como um cluster de região ativo. Por fim, crie um novo cluster de banco de dados secundário na região afetada anteriormente e atribua-o ao cluster de banco de dados global como um cluster de região passiva.
