Esta página apresenta a recuperação de desastres no Cloud SQL.
Vista geral
Na Google Cloud, a recuperação de desastres (RD) da base de dados consiste em fornecer continuidade do processamento, especificamente quando uma região falha ou fica indisponível. O Cloud SQL é um serviço regional (quando o Cloud SQL está configurado para alta disponibilidade (HA)). Por conseguinte, se a Google Cloud região que aloja uma base de dados do Cloud SQL ficar indisponível, a base de dados do Cloud SQL também fica indisponível.
Para continuar o processamento, tem de disponibilizar a base de dados numa região secundária assim que possível. O plano de DR requer que configure uma réplica de leitura entre regiões no Cloud SQL. Também é possível uma comutação por falha baseada na exportação/importação ou na cópia de segurança/restauro, mas esta abordagem demora mais tempo, especialmente para bases de dados grandes.
Os seguintes cenários empresariais são exemplos que justificam uma configuração de comutação por falha entre regiões:
- O contrato de nível de serviço da aplicação empresarial é superior ao contrato de nível de serviço do Cloud SQL regional (disponibilidade de 99,99% consoante a sua edição do Cloud SQL). Ao fazer a comutação por falha para outra região, pode mitigar uma indisponibilidade.
- Todos os níveis da aplicação empresarial já são multirregionais e podem continuar o processamento quando ocorre uma indisponibilidade regional. A configuração de comutação por falha entre regiões ajuda a suportar a disponibilidade contínua de uma base de dados.
- O objetivo de recuperação de tempo (RTO) e o objetivo de ponto de recuperação (RPO) necessários são em minutos e não em horas. A comutação para outra região é mais rápida do que recriar uma base de dados.
Em geral, existem duas variantes para o processo de DR:
- Uma base de dados comuta para uma região secundária. Depois de a base de dados estar pronta e ser usada por uma aplicação, torna-se a nova base de dados principal e permanece a base de dados principal.
- Uma base de dados comutou para uma região secundária, mas voltou à região principal depois de esta ter sido recuperada da respetiva falha.
Esta Google Cloud vista geral da recuperação de desastres da base de dados SQL descreve a segunda variante: quando uma base de dados com falhas é recuperada e volta a usar a região principal. Esta variante do processo de recuperação de desastres é especialmente relevante para bases de dados que têm de ser executadas na região principal devido à latência da rede ou porque alguns recursos só estão disponíveis na região principal. Com esta variante, a base de dados é executada na região secundária apenas durante a indisponibilidade na região principal.
Dois tutoriais estão associados a este documento de DR:- Recuperação de desastres do Cloud SQL para MySQL: um processo completo de comutação por falha e retorno
- Recuperação de desastres do Cloud SQL para PostgreSQL: um processo completo de comutação por falha e reversão
Arquitetura de recuperação de desastres
O diagrama seguinte mostra a arquitetura mínima que suporta a DR da base de dados para uma instância do Cloud SQL de alta disponibilidade:
A arquitetura funciona da seguinte forma:
- Duas instâncias do Cloud SQL (uma instância principal e uma instância em espera) estão localizadas em duas zonas separadas numa única região (a região principal). As instâncias são sincronizadas através de discos persistentes regionais.
- Uma instância do Cloud SQL (a réplica de leitura entre regiões) está localizada numa segunda região (a região secundária). Para a recuperação de desastres, a réplica de leitura entre regiões é configurada para sincronizar (através da replicação assíncrona) com a instância principal através de uma configuração de réplica de leitura.
As instâncias principal e de standby partilham o mesmo disco regional, pelo que os respetivos estados são idênticos.
Uma vez que esta configuração usa a replicação assíncrona, é possível que a réplica de leitura entre regiões fique atrasada em relação à instância principal. Como resultado, quando ocorre uma comutação por falha, é provável que o RPO da réplica de leitura entre regiões seja diferente de zero.
Processo de recuperação de desastres (RD)
O processo de recuperação de desastres (RD) é iniciado quando a região principal fica indisponível. Para retomar o processamento numa região secundária, aciona uma comutação por falha da instância principal promovendo uma réplica de leitura entre regiões. O processo de DR prescreve os passos operacionais que têm de ser realizados, manual ou automaticamente, para mitigar a falha da região e estabelecer uma instância principal em execução numa região secundária.
O diagrama seguinte mostra o processo de DR:
O processo de recuperação de desastres consiste nos seguintes passos:
- A região principal (R1), que está a executar a instância principal, fica indisponível.
- A equipa de operações reconhece e confirma formalmente o desastre e decide se é necessária uma comutação por falha.
- Se for necessária uma comutação por falha, pode promover a réplica de leitura entre regiões na região secundária (R2) para ser a nova instância principal.
- As ligações de clientes são reconfiguradas para retomar o processamento na nova instância principal e aceder à instância principal no R2.
Este processo inicial estabelece novamente uma base de dados principal funcional. No entanto, não estabelece uma arquitetura de DR completa, em que a nova instância principal tem uma instância de reserva e uma réplica de leitura entre regiões.
Um processo de DR completo garante que a instância única, a nova instância principal, está ativada para HA e tem uma réplica de leitura entre regiões. Um processo de DR completo também oferece uma alternativa à implementação original na região primária original.
Realizar uma comutação por falha para uma região secundária
Um processo de DR completo expande o processo de DR básico adicionando passos para estabelecer uma arquitetura de DR completa após a comutação por falha. O diagrama seguinte mostra uma arquitetura de DR de base de dados completa após a comutação por falha:
O processo de recuperação de desastres da base de dados completo consiste nos seguintes passos:
- A região principal (R1), que está a executar a base de dados principal, fica indisponível.
- A equipa de operações reconhece e confirma formalmente o desastre e decide se é necessária uma comutação por falha.
- Se for necessária uma comutação por falha, pode promover a réplica de leitura entre regiões na região secundária (R2) para ser a nova instância principal.
- As ligações de cliente são reconfiguradas para aceder e processar na nova instância principal (R2).
- É criada e iniciada uma nova instância de espera no R2 e adicionada à instância principal. A instância de espera está numa zona diferente da instância principal. A instância principal está agora altamente disponível porque foi criada uma instância de espera para a mesma.
- Numa terceira região (R3), é criada uma nova réplica de leitura entre regiões e anexada à instância principal. Neste ponto, é recriada uma arquitetura de recuperação de desastres completa e operacional.
Se a região principal original (R1) ficar disponível antes da implementação do passo 6, a réplica de leitura entre regiões pode ser colocada na região R1, em vez da região R3, imediatamente. Neste caso, o recurso à região principal original (R1) é menos complexo e requer menos passos.
Evitar um estado de divisão cerebral
Uma falha na região principal (R1) não significa que a instância principal original e a respetiva instância de espera sejam encerradas, removidas ou, de outra forma, tornadas inacessíveis automaticamente quando a R1 ficar novamente disponível. Se o R1 ficar disponível, os clientes podem ler e escrever dados (mesmo por acidente) na instância principal original. Neste caso, pode desenvolver-se uma situação de divisão de cérebros, em que alguns clientes acedem a dados desatualizados na base de dados principal antiga e outros clientes acedem a dados atualizados na nova base de dados principal, o que leva a problemas na sua empresa.
Para evitar uma situação de divisão de cérebros, tem de garantir que os clientes já não conseguem aceder à instância principal original depois de o R1 ficar disponível. Idealmente, deve tornar o original principal inacessível antes de os clientes começarem a usar a nova instância principal e, em seguida, eliminar o original principal imediatamente após torná-lo inacessível.
Estabelecer uma cópia de segurança inicial após a comutação por falha
Quando promove a réplica de leitura entre regiões para ser a nova principal numa transferência de controlo após falha, as transações na nova principal podem não estar totalmente sincronizadas com as transações da principal original. Por conseguinte, essas transações estão indisponíveis na nova instância.
Como prática recomendada, recomendamos que faça imediatamente uma cópia de segurança da nova instância principal no início da comutação por falha e antes de os clientes acederem à base de dados. Esta cópia de segurança representa um estado consistente e conhecido no ponto da comutação por falha. Estas cópias de segurança podem ser importantes para fins regulamentares ou para a recuperação para um estado conhecido se os clientes encontrarem problemas ao acederem ao novo servidor principal.
Voltar à região principal original
Conforme descrito anteriormente, este documento indica os passos para reverter para a região original (R1). Existem duas versões diferentes do processo de alternativa.
- Se criou a nova réplica de leitura entre regiões numa região terciária (R3), tem de criar outra (segunda) réplica de leitura entre regiões na região principal (R1).
- Se criou a nova réplica de leitura entre regiões na região principal (R1), não precisa de criar outra réplica de leitura entre regiões adicional em R1.
Depois de a réplica de leitura entre regiões em R1 existir, a instância do Cloud SQL pode reverter para R1. Uma vez que esta alternativa é acionada manualmente e não se baseia numa indisponibilidade, pode escolher um dia e uma hora adequados para esta atividade de manutenção.
Assim, para alcançar uma DR completa com uma réplica de leitura principal, em espera e entre regiões, precisa de duas comutações por falha. A primeira comutação por falha é acionada pela indisponibilidade (uma verdadeira comutação por falha) e a segunda comutação por falha restabelece a implementação inicial (uma reversão).
A alternativa à região principal original (R1) consiste nos seguintes passos:
- Promova a réplica entre regiões recém-criada na região principal original (R1).
- Se a instância promovida não tiver sido criada originalmente como uma réplica de HA, ative o HA na instância para proteção contra falhas zonais.
- Reconfigure as suas aplicações para estabelecer ligação à nova instância principal.
- Crie uma réplica entre regiões para a nova instância principal na região de recuperação de desastres (R2).
- (Opcional) Para evitar a execução de várias instâncias principais independentes, limpe a instância principal na região de recuperação de desastres (R2).
Recuperação de desastres (RD) avançada
Se estiver a usar a edição Cloud SQL Enterprise Plus, pode tirar partido da recuperação de desastres avançada. A recuperação de desastres avançada simplifica a recuperação e o alternativo após uma transferência de recursos entre regiões. Conforme descrito no processo de recuperação de desastres, quando faz a RD, remove a associação entre a região com falhas da instância principal antiga e a região operacional da nova instância principal. Com a DR, para restaurar as ligações à região de implementação original e recuperar a sua antiga instância principal, tem de executar uma série de passos de replicação manual.
Com a recuperação de desastres avançada, quando ocorre uma falha na região, pode invocar uma transferência de replicação. Com a comutação por falha de réplicas, promove uma réplica de leitura entre regiões semelhante à execução da recuperação de desastres normal, exceto que promove a réplica de recuperação de desastres (DR) designada. A promoção da réplica de DR é imediata.
Em vez de remover a instância principal antiga, a instância permanece parte da topologia de replicação assíncrona do Cloud SQL. A instância principal antiga (instância A) torna-se, eventualmente, uma réplica da respetiva réplica de DR (instância B) depois de a réplica de DR ter sido promovida à nova instância principal.
Depois de a instância principal antiga (A) ter sido transformada numa réplica, pode executar o passo final da recuperação de desastres avançada. Pode devolver a implementação do Cloud SQL ao estado original e restaurar a instância principal antiga (A) à sua função anterior como instância principal sem perda de dados. Para realizar esta restauração sem perda de dados da instância principal antiga (A), pode usar a operação de mudança. Quando faz uma comutação, não há perda de dados porque a instância principal (B) permanece no modo só de leitura até que a réplica de DR designada (A) alcance a instância principal (B). Depois de a réplica de recuperação de desastres (A) ter recebido todas as atualizações de replicação, a réplica de recuperação de desastres (A) assume a função da instância principal, enquanto a instância principal anterior (B) é reconfigurada automaticamente como a réplica de recuperação de desastres da instância principal atual (A). As instâncias são devolvidas às respetivas funções originais, o que devolve a topologia ao estado original antes da recuperação de desastres e da comutação por falha de réplicas.
Durante a DR avançada, todas as instâncias envolvidas nas operações de comutação por falha de réplica e de comutação mantêm os respetivos endereços IP.
Também pode usar a operação de comutação da recuperação de desastres avançada para realizar exercícios de recuperação de desastres de rotina para testar e preparar a sua topologia do Cloud SQL para uma comutação por falha entre regiões antes de ocorrer um desastre. Se ocorrer um desastre real, pode fazer a comutação por falha da réplica entre regiões que já testou.
Réplica de recuperação de desastres (RD)
Como componente obrigatório da recuperação de desastres avançada, a réplica de RD tem as seguintes características:
- Uma réplica de DR é uma réplica de leitura entre regiões ligada diretamente.
- Pode alterar a designação da réplica de recuperação de desastres várias vezes.
- Pode alterar a designação da réplica de recuperação de desastres em qualquer altura, exceto durante uma operação de comutação ou de replicação de recurso alternativo.
Além disso, para reduzir o RTO após usar a DR avançada, recomendamos que faça o seguinte:
- Configure a réplica de recuperação de desastres com o mesmo tamanho da instância principal.
- Se a instância principal tiver a HA ativada, recomendamos que ative a HA na réplica de DR também. Para o fazer, verifique primeiro se o servidor principal tem a HA ativada. Em seguida, faça a comutação para a réplica de recuperação de desastres. Após a operação de comutação estar concluída, ative a HA na nova instância principal. Em seguida, pode voltar à instância principal antiga. A réplica de recuperação de desastres mantém a respetiva configuração de HA, mesmo depois de voltar a ser uma réplica.
Ativação pós-falha da réplica
Em resumo, uma comutação por falha de réplica consiste nos seguintes eventos:
- Cria e atribui uma réplica de DR.
- A região principal fica indisponível.
- Executa a comutação por falha da réplica para a réplica de recuperação de desastres.
- O ponto final de escrita é atualizado e começa a apontar para a nova instância principal.
- Quando a instância principal original volta a ficar online, torna-se uma réplica de leitura da nova instância principal.
- Pode usar a operação de comutação para restaurar a implementação à topologia original.
Para ver os detalhes e os diagramas de uma operação de ativação pós-falha de réplica, clique nos separadores seguintes.
Atribua uma réplica de RD
Antes de realizar uma comutação por falha da réplica, atribuiu uma réplica de DR à instância principal e, possivelmente, testou o processo realizando uma comutação.
Ocorre uma indisponibilidade
A região principal, que está a executar a base de dados principal, fica indisponível.
Ativação pós-falha da réplica
Depois de determinar que a recuperação de desastres é necessária, faz uma comutação por falha de réplica para a réplica de RD designada entre regiões.
A réplica de RD designada entre regiões torna-se imediatamente a instância principal e começa a aceitar leituras e escritas recebidas. O ponto final de escrita é atualizado e começa a apontar para a instância principal nova.
O original primário torna-se uma réplica
Depois de a réplica ser promovida, o Cloud SQL verifica periodicamente se a instância principal original está novamente online. Se a instância principal original estiver online, o Cloud SQL recria a instância principal antiga como uma réplica da instância promovida. A instância principal antiga mantém o respetivo endereço IP.
Retorno à versão original
Depois de fazer uma comutação por falha da réplica, pode restaurar a instância principal na região original fazendo a operação de comutação, revertendo o mesmo par de réplica de DR e instância principal.
Comutação
Em resumo, uma operação de comutação consiste nos seguintes eventos:
- Cria e atribui uma réplica de DR.
- Inicia uma comutação.
- Quando o atraso de replicação desce para zero, as novas instâncias principais começam a aceitar ligações recebidas.
- A instância principal antiga torna-se uma réplica de leitura.
- Se estiver a ser usado um ponto final de gravação de DNS, o ponto final de gravação de DNS é atualizado para apontar para a nova instância principal.
Para ver os detalhes e os diagramas de uma operação de comutação, clique nos seguintes separadores.
Atribua uma réplica de RD
Antes de iniciar a operação de *transferência*, tem de atribuir uma réplica de recuperação de desastres à instância principal.
Verifique se a instância principal está em bom estado. Só pode fazer uma comutação quando a instância principal e a réplica de recuperação de desastres estiverem online.
Inicie a comutação
Inicia a comutação. Quando inicia uma comutação, a instância principal deixa de aceitar gravações e passa a ser só de leitura. O Cloud SQL aguarda que os registos de transações sejam copiados para o Cloud Storage. A réplica de RD designada alcança a instância principal.
Quando o atraso de replicação desce para zero, a réplica de DR é promovida como a nova instância principal. A nova instância principal começa a aceitar ligações recebidas, incluindo leituras e escritas de aplicações.
Ponto final atualizado
Depois de a réplica de DR ser promovida à nova instância principal, o ponto final de gravação de DNS é atualizado e começa a apontar para a nova instância principal. Se não estiver a usar um ponto final de gravação de DNS, tem de configurar as suas aplicações para apontarem para o endereço IP da nova instância principal.
A instância principal antiga é reconfigurada como uma réplica de leitura.
A PITR é ativada automaticamente para a nova instância principal. A PITR só é possível após a primeira cópia de segurança automática.
Ponto final de escrita
Um ponto final de gravação é um nome de serviço de nomes de domínio (DNS) global que é resolvido automaticamente para o endereço IP da instância principal atual. Este ponto final redireciona as ligações recebidas para a nova instância principal automaticamente em caso de uma operação de comutação por falha ou comutação de uma réplica. Pode usar o ponto final de gravação numa string de ligação SQL em vez de um endereço IP. Ao usar um ponto final de gravação, pode evitar ter de fazer alterações à ligação da aplicação quando ocorre uma indisponibilidade da região.
Um ponto final de gravação requer que a API Cloud DNS esteja ativada no projeto onde cria ou tem a sua instância principal da edição Cloud SQL Enterprise Plus existente. Quando cria uma instância da edição Enterprise Plus do Cloud SQL com um endereço IP privado e redes autorizadas, o Cloud SQL gera automaticamente um ponto final de gravação para a instância. Se já tiver uma instância principal da edição Cloud SQL Enterprise Plus, o Cloud SQL gera o ponto final de gravação quando cria a réplica de DR (uma réplica entre regiões que designa para a instância principal). Se a instância principal for alterada devido a uma operação de comutação ou de replicação de tolerância a falhas, o Cloud SQL atribui o ponto final de gravação à réplica de DR quando a réplica de DR se torna a nova instância principal.
Para mais informações sobre como usar um ponto final de escrita para se ligar a uma instância, consulte o artigo Ligue-se a uma instância através de um ponto final de escrita.
O que se segue?
- Use a recuperação de desastres (RD) avançada.
- Experimente o tutorial de recuperação de desastres do Cloud SQL para MySQL.
- Explore arquiteturas de referência, diagramas, tutoriais e práticas recomendadas sobre Google Cloud. Consulte o nosso Centro de arquitetura na nuvem.