Recuperação de desastres do Cloud SQL para MySQL: um processo completo de comutação por falha e reversão

Este tutorial descreve um processo completo de comutação por falha e reversão de recuperação de desastres (RD) no Cloud SQL para MySQL através da utilização de réplicas de leitura entre regiões.

Neste tutorial, vai configurar uma instância do Cloud SQL para MySQL de alta disponibilidade (HA) para recuperação de desastres e simular uma indisponibilidade. Em seguida, segue o processo de DR para recuperar a implementação inicial após a resolução da indisponibilidade.

Este tutorial destina-se a arquitetos, administradores e engenheiros de bases de dados.

Para ler uma vista geral de como funciona a recuperação de desastres do SQL, consulte o artigo Acerca da recuperação de desastres no Cloud SQL.

Objetivos

  • Crie uma instância do Cloud SQL para MySQL de HA.
  • Implemente uma réplica de leitura entre regiões no Google Cloud usando o Cloud SQL para MySQL.
  • Simule um desastre e uma comutação por falha com o Cloud SQL para MySQL.
  • Compreenda os passos para recuperar a implementação inicial através de uma alternativa com o Cloud SQL para MySQL.

Este documento foca-se apenas nos processos de comutação por falha e alternativos de DR entre regiões. Para obter informações sobre um processo de comutação por falha de HA de região única, consulte o artigo Vista geral da configuração de alta disponibilidade.

Custos

Neste documento, usa os seguintes componentes faturáveis do Google Cloud:

Para gerar uma estimativa de custos com base na sua utilização projetada, use a calculadora de preços.

Os novos Google Cloud utilizadores podem ser elegíveis para uma avaliação gratuita.

Quando terminar as tarefas descritas neste documento, pode evitar a faturação contínua eliminando os recursos que criou. Para mais informações, consulte o artigo Limpe.

Antes de começar

  1. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  2. Verify that billing is enabled for your Google Cloud project.

  3. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    Fase 1: configurar uma instância de base de dados de AD para RD

    As seguintes fases (1 a 3) explicam um processo completo de comutação por falha e reversão. Executa todos os comandos através do comando gcloud no Cloud Shell. Para simplificar o processo, o tutorial usa as predefinições sempre que possível (por exemplo, a versão predefinida do Cloud SQL). No ambiente de produção, pode adicionar outras configurações.

    Defina variáveis de ambiente

    Esta secção fornece exemplos de variáveis de ambiente que definem os vários nomes e regiões necessários para os comandos que executa neste tutorial. Pode ajustar estas variáveis de exemplo de acordo com as suas necessidades.

    As tabelas seguintes descrevem os nomes das instâncias, as respetivas funções e as regiões de implementação para cada fase do processo de recuperação de desastres e reversão neste tutorial. Também pode indicar os seus próprios nomes e regiões.

    Fase inicial
    Nome da instância Role Região
    instance-1 Primary us-west1
    instance-2 Modo de espera us-west1
    instance-3 Réplica de leitura entre regiões us-west2
    Fase de desastre
    Nome da instância Role Região
    instance-3 Primary us-west2
    instance-4 Modo de espera us-west2
    instance-5 Réplica de leitura entre regiões us-west3
    instance-6 Réplica de leitura entre regiões us-west1
    Fase de alternativa (final)
    Nome da instância Role Região
    instance-6 Primary us-west1
    instance-7 Modo de espera us-west1
    instance-8 Réplica de leitura entre regiões us-west2

    Os nomes das instâncias nas tabelas anteriores não estão codificados com as respetivas funções. Numa situação de DR, a função de uma instância pode mudar. Por exemplo, uma réplica pode tornar-se a principal. Se o nome do novo principal contiver a palavra replica, podem surgir confusões e conflitos. Por conseguinte, recomendamos que não codifique os nomes das instâncias com a função ou o papel que desempenham.

    As tabelas anteriores apresentam os nomes das instâncias de espera. Embora este tutorial não exerça uma comutação por falha de HA, o tutorial inclui os nomes das instâncias de espera para fins de integridade.

    A fase de alternativa recria a implementação original da fase inicial nas mesmas regiões originais. No entanto, numa alternativa, os nomes das instâncias têm de ser alterados porque os nomes originais não estão imediatamente disponíveis, mesmo depois de a instância original ser eliminada. Para suportar a criação rápida de instâncias na fase de alternativa, deve usar nomes de instâncias que não correspondam aos nomes usados na fase inicial.

    • No Cloud Shell, defina variáveis de ambiente com base nas especificações nas tabelas anteriores:

      export primary_name=instance-1
export primary_tier=db-n1-standard-2
export primary_region=us-west1
export primary_root_password=my-root-password
export primary_backup_start_time=22:00
export cross_region_replica_name=instance-3
export cross_region_replica_region=us-west2

      Se quiser usar um nível diferente para a sua instância principal, liste os níveis disponíveis e, em seguida, atribua um valor diferente a primary_tier:

      gcloud sql tiers list

      Para ver uma lista das regiões onde pode implementar o Cloud SQL, consulte as definições da instância.

    Crie uma instância de base de dados principal

    1. No Cloud Shell, crie uma única instância do Cloud SQL:

      gcloud sql instances create $primary_name \
    --tier=$primary_tier \
    --region=$primary_region

      O comando gcloud é pausado até a instância ser criada.

    2. Defina a palavra-passe de raiz:

      gcloud sql users set-password root \
    --host=% \
    --instance $primary_name \
    --password $primary_root_password

    Crie uma base de dados principal

    1. No Cloud Shell, inicie sessão na shell do MySQL e introduza a palavra-passe de raiz no comando:

      gcloud sql connect $primary_name --user=root

    2. No comando do MySQL, crie uma base de dados e carregue dados de teste:

      CREATE DATABASE guestbook;

USE guestbook;

CREATE TABLE entries (guestName VARCHAR(255), content VARCHAR(255), entryID INT NOT NULL AUTO_INCREMENT, PRIMARY KEY(entryID));

INSERT INTO entries (guestName, content) values ("first guest", "I got here!");
INSERT INTO entries (guestName, content) values ("second guest", "Me too!");

    3. Verifique se os dados foram enviados com êxito:

      SELECT * FROM entries;

      Verifique se são devolvidas duas linhas de dados.

    4. Saia da shell do MySQL:

      exit;

    Neste ponto, tem uma única base de dados que inclui uma tabela e alguns dados de teste.

    Altere a instância principal para uma instância de base de dados de HA

    Só pode configurar o Cloud SQL como um sistema de HA regional e não como um sistema inter-regional. (A configuração de uma réplica de leitura entre regiões é diferente da configuração do Cloud SQL como um sistema entre regiões.) Para mais informações, consulte Ativar e desativar a elevada disponibilidade numa instância.

    • No Cloud Shell, crie uma instância do Cloud SQL com HA:

      gcloud sql instances patch $primary_name \
    --availability-type REGIONAL \
    --enable-bin-log \
    --backup-start-time=$primary_backup_start_time

    Adicione uma réplica de leitura entre regiões para a recuperação de desastres com atualização automática

    Os passos seguintes são suficientes para criar uma réplica de leitura entre regiões para este tutorial:

    1. No Cloud Shell, configure uma réplica de leitura entre regiões:

      gcloud sql instances create $cross_region_replica_name \
    --master-instance-name=$primary_name \
    --region=$cross_region_replica_region

    2. (Opcional) Para verificar se a base de dados foi replicada, naGoogle Cloud consola, aceda à página Instâncias do Cloud SQL.

      Aceda a Instâncias

      A página Instances mostra o servidor principal com HA ativado e a réplica de leitura.

      A Google Cloud consola mostra que a instância principal (instance-1) está ativada para HA e que existe uma réplica de leitura entre regiões (instance-3).

    3. Usando a mesma palavra-passe de raiz para o principal, inicie sessão na réplica de leitura entre regiões:

      gcloud sql connect $cross_region_replica_name --user=root

    4. No comando do MySQL, selecione os dados para garantir que a replicação está a funcionar:

      USE guestbook;

SELECT * FROM entries;

    5. Saia da shell do MySQL:

      exit;

    Para ver detalhes sobre como configurar uma réplica de leitura completa entre regiões, consulte a documentação do Cloud SQL

    Para grandes bases de dados num ambiente de produção, recomendamos que faça uma cópia de segurança da base de dados principal e crie a réplica de leitura entre regiões a partir da cópia de segurança. Este passo ajuda a reduzir o tempo necessário para a réplica de leitura sincronizar com a base de dados principal. Este processo é descrito na secção seguinte. No entanto, pode optar por ignorar este passo e continuar com a fase 2.

    Adicione uma réplica de leitura entre regiões com base num ficheiro de despejo

    Uma forma de otimizar a criação de uma réplica de leitura entre regiões é sincronizar a réplica a partir de um estado da base de dados principal consistente anterior, em vez de sincronizar no ponto de acesso à nova base de dados principal. Esta otimização requer a criação de um ficheiro de despejo que a réplica usa como estado inicial.

    Para ver os passos para criar uma réplica com base num ficheiro de despejo, consulte o artigo Fazer a replicação de um servidor externo para o Cloud SQL (v1.1). Esta abordagem pode ser útil para grandes bases de dados de produção. No entanto, este tutorial ignora este passo porque o conjunto de dados de teste é suficientemente pequeno para uma replicação completa.

    Fase 2: simular um desastre (indisponibilidade da região)

    Nesta fase, vai simular a indisponibilidade de uma região principal num ambiente de produção tornando a base de dados principal indisponível.

    Verifique o atraso da réplica de leitura entre regiões

    Nos passos seguintes, determina o atraso de replicação da réplica de leitura entre regiões:

    1. Na Google Cloud consola, aceda à página do Cloud SQL Instâncias.

      Aceda a Instâncias

    2. Clique na réplica de leitura (instance-3).

    3. Na lista pendente de métricas, clique em Atraso na replicação:

      A lista pendente de métricas mostra várias opções, incluindo Replication Delay.

      A métrica muda para Atraso de replicação. O gráfico não mostra atrasos:

      O gráfico de intervalo de tempo de replicação tem opções de visualização que variam entre uma hora e 30 dias.

    Idealmente, o atraso de replicação é zero quando ocorre uma indisponibilidade da região principal, uma vez que um atraso de zero garante que todas as transações são replicadas. Se não for zero, algumas transações podem não ser replicadas. Neste caso, a réplica de leitura entre regiões não vai conter todas as transações que foram confirmadas na base de dados principal.

    Indisponibilizar a instância principal

    Nos passos seguintes, simula um desastre parando o servidor principal. Se uma réplica de leitura entre regiões estiver anexada à instância principal, tem de desanexar primeiro a réplica. Caso contrário, não pode parar a instância do Cloud SQL.

    1. No Cloud Shell, remova a réplica de leitura entre regiões do principal:

      gcloud sql instances patch $cross_region_replica_name \
    --no-enable-database-replication

      Quando lhe for pedido, aceite a opção para continuar.

    2. Pare a instância de base de dados principal:

      gcloud sql instances patch $primary_name --activation-policy NEVER

    Implemente a RD

    1. Na Cloud Shell, promova a réplica de leitura entre regiões a uma instância autónoma:

      gcloud sql instances promote-replica $cross_region_replica_name

      Quando lhe for pedido, aceite a opção para continuar. A página Instâncias do Cloud SQL mostra a antiga réplica de leitura entre regiões (instance-3) como a nova instância principal e a antiga instância principal (instance-1) como interrompida:

      As páginas Instâncias mostram o estado de duas instâncias, a principal original e a nova principal.

      Depois de promover a réplica de leitura entre regiões como a nova principal, pode ativá-la para HA. Como prática recomendada, deve atualizar as variáveis de ambiente com a nomenclatura adequada.

    2. Atualize as variáveis de ambiente:

      export former_primary_name=$primary_name
export primary_name=$cross_region_replica_name
export primary_tier=db-n1-standard-2
export primary_region=$cross_region_replica_region
export primary_root_password=my-root-password
export primary_backup_start_time=22:00
export cross_region_replica_name=instance-5
export cross_region_replica_region=us-west3

    3. Inicie o novo primário:

      gcloud sql instances patch $primary_name --activation-policy ALWAYS

    4. Ative a nova instância principal como uma instância regional de HA:

      gcloud sql instances patch $primary_name \
    --availability-type REGIONAL \
    --enable-bin-log \
    --backup-start-time=$backup_start_time

    5. Crie uma réplica de leitura entre regiões numa terceira região:

      gcloud sql instances create $cross_region_replica_name \
    --master-instance-name=$primary_name \
    --region=$cross_region_replica_region

      Num passo anterior, definiu a variável de ambiente cross_region_replica_region como us-west3.

      Após a conclusão da comutação por falha, a página Instâncias do Google Cloud console mostra que a nova instância principal (instance-3) está ativada como HA e tem uma réplica de leitura entre regiões (instance-5):

      A página Instâncias mostra a nova instância principal ativada para HA e uma nova réplica de leitura.

    6. (Opcional) Se tiver cópias de segurança regulares, siga o processo descrito anteriormente para sincronizar o novo principal com a versão de cópia de segurança mais recente.

    7. (Opcional) Se estiver a usar um proxy do Cloud SQL, configure o proxy para usar o novo servidor principal de modo a retomar o processamento da aplicação.

    Resolva uma indisponibilidade regional de curta duração

    É possível que a indisponibilidade que aciona uma comutação por falha seja resolvida antes de a comutação por falha ser concluída. Neste caso, pode fazer sentido cancelar o processo de comutação por falha e continuar a usar a instância principal original do Cloud SQL na região onde ocorreu a indisponibilidade.

    Consoante o estado específico do processo de comutação por falha, a réplica de leitura entre regiões pode já ter sido promovida. Neste caso, tem de eliminá-la e recriar uma réplica de leitura entre regiões.

    Elimine o primário original para evitar uma situação de divisão de cérebros

    Para evitar uma situação de divisão de cérebros, tem de eliminar o original principal (ou torná-lo inacessível aos clientes da base de dados).

    Após uma comutação por falha, pode ocorrer uma situação de divisão de cérebros quando os clientes escrevem na base de dados principal original e na nova base de dados principal ao mesmo tempo. Neste caso, o conteúdo das duas bases de dados é inconsistente. Após uma ativação pós-falha, a base de dados primária original está desatualizada e não deve receber tráfego de leitura nem de escrita.

    • No Cloud Shell, elimine o principal original:

      gcloud sql instances delete $former_primary_name

      Quando lhe for pedido, aceite a opção para continuar.

      Na Google Cloud consola, a página Instâncias do Cloud SQL já não mostra a instância principal original (instance-1) como parte da implementação:

      A página Instâncias mostra apenas a nova instância principal e a réplica de leitura.

    Fase 3: implementar uma alternativa

    Para implementar uma alternativa à sua região original (R1) depois de ficar disponível, siga o mesmo processo descrito na Fase 2. Esse processo é resumido da seguinte forma:

    1. Crie uma segunda réplica de leitura entre regiões na região original (R1). Neste ponto, o servidor principal tem duas réplicas de leitura entre regiões, uma na região R3 e outra na região R1.

    2. Promova a réplica de leitura entre regiões em R1 como principal final.

    3. Ative a HA para o principal final.

    4. Crie uma réplica de leitura entre regiões do principal final em us-west2.

    5. Para evitar uma situação de divisão de cérebros, elimine todas as instâncias que já não são necessárias (a principal original e a réplica de leitura entre regiões em R3).

    Conforme referido anteriormente, é uma prática recomendada criar uma cópia de segurança inicial que contenha o estado de início definido para a nova base de dados principal.

    A implementação final tem agora um servidor primário de HA (com o nome instance-6) e uma réplica de leitura entre regiões (com o nome instance-8).

    Comparar as vantagens e as desvantagens de uma DR manual com uma DR automática

    A tabela seguinte aborda as vantagens e as desvantagens da implementação de um processo de DR manual ou automático. O objetivo não é determinar uma abordagem correta versus incorreta, mas fornecer critérios para ajudar a determinar a melhor abordagem para as suas necessidades.

    Execução manual Execução automática
    Vantagens:
    • Tem um controlo rigoroso sobre cada passo.
    • Pode ver, resolver e documentar imediatamente qualquer problema no processo.
    • Pode ver e rever cada passo do processo durante uma comutação por falha.
    		 Vantagens:
    • Pode implementar e testar processos de comutação por falha.
    • A automatização oferece a implementação mais rápida e minimiza os atrasos.
    • A implementação é independente dos operadores humanos, dos respetivos conhecimentos e da respetiva disponibilidade.
    Desvantagens:
    • A implementação manual dos passos do processo abranda o processo.
    • Os erros de digitação humanos podem introduzir problemas.
    • Normalmente, o teste do processo envolve várias funções e tempo, o que pode desmotivar os testes regulares.
    		 Desvantagens:
    • Se ocorrer um erro imprevisto, tem de depurar durante a comutação por falha de produção.
    • Se encontrar erros durante o processo, precisa de scripts para retomar (recuperar) o ponto em que o processo foi interrompido.
    • São necessários conhecimentos suficientes sobre o script e a respetiva implementação para compreender o comportamento do script, especialmente em situações de erro.

    Como prática recomendada, sugerimos que comece com uma implementação manual. Em seguida, execute voluntariamente a implementação com regularidade (de preferência, em produção) para garantir que o processo manual funciona e que todos os membros da equipa conhecem as respetivas funções e responsabilidades. Recomendamos que defina o seu processo manual num documento de processo passo a passo. Após cada implementação, deve confirmar ou refinar o documento do processo.

    Depois de otimizar o processo e ter a certeza de que é fiável, determina se o automatiza. Se selecionar e implementar um processo automatizado, tem de testar o processo regularmente em produção para garantir que o pode implementar de forma fiável.

    Limpar

    Para evitar incorrer em custos na sua Google Cloud conta pelos recursos usados neste tutorial, pode eliminar o Google Cloud projeto que criou para este tutorial.

    Elimine o projeto

    1. In the Google Cloud console, go to the Manage resources page.

      Go to Manage resources

    2. In the project list, select the project that you want to delete, and then click Delete.
    3. In the dialog, type the project ID, and then click Shut down to delete the project.

    O que se segue?