Automatize o banco de dados global do Amazon Aurora usando o CloudFormation
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:
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:
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:
