Visão geral da configuração de alta disponibilidade

Esta página é uma visão geral da configuração de alta disponibilidade (HA, na sigla em inglês) de instâncias do Cloud SQL. Para configurar uma nova instância de alta disponibilidade ou para ativá-la em uma instância existente, consulte Como ativar e desativar a alta disponibilidade em uma instância.

Visão geral da configuração de alta disponibilidade

A finalidade de uma configuração de alta disponibilidade é reduzir a inatividade quando uma zona ou instância fica indisponível. Isso pode acontecer durante uma interrupção de zona ou quando uma instância está corrompida. A alta disponibilidade permite que seus dados continuem disponíveis para aplicativos cliente.

A configuração de alta disponibilidade, também chamada de cluster, fornece redundância de dados. Uma instância do Cloud SQL configurada para HA também é chamada de instância regional e está localizada em uma zona principal e secundária dentro da região configurada. Em uma instância regional, a configuração é composta de uma instância primária e uma instância de espera. Por meio da replicação síncrona no disco permanente de cada zona, todas as gravações feitas na instância principal são replicadas nos discos nas duas zonas antes que uma transação seja relatada como confirmada. Em caso de falha da instância ou zona, o disco permanente é anexado à instância de espera e se torna a nova instância principal. Os usuários são redirecionados para a nova rede principal. Esse processo é chamado de failover.

Após um failover, a instância que recebeu o failover continua sendo a instância principal, mesmo depois que a instância original fique on-line novamente. Quando a zona ou instância que apresentou uma interrupção fica novamente disponível, a instância primária original é destruída e recriada. Em seguida, ela se torna a nova instância de espera. Se ocorrer um failover no futuro, a nova instância primária fará o failover para a instância original na zona original.

Se a instância principal estiver na zona que teve a interrupção, será possível fazer um failback. O failback executa as mesmas etapas do failover, mas somente na direção oposta, para redirecionar o tráfego de volta para a instância original. Para executar um failback, use o procedimento em Como iniciar o failover.

A compatibilidade com discos permanentes regionais do Cloud SQL e a configuração de alta disponibilidade do Cloud SQL têm a cobertura completa do Contrato de nível de serviço (SLA, na sigla em inglês). Uma instância configurada com alta disponibilidade é cobrada ao dobro do preço de uma instância independente. Esse preço inclui CPU, RAM e armazenamento. Para mais informações, consulte a página de preços.

Visão geral do diagrama da configuração de alta disponibilidade do Cloud SQL. Descrita no texto abaixo.

Réplicas de leitura

As réplicas de leitura não podem ser altamente disponíveis, como as instâncias principais. Durante uma interrupção de zona, o tráfego para ler as réplicas nessa zona é interrompido. Quando a zona ficar disponível novamente, qualquer réplica de leitura na zona retomará a replicação da instância principal. Se as réplicas de leitura estiverem em uma zona que não esteja interrompida, elas serão conectadas à instância de espera quando ela se tornar a instância principal.

Como prática recomendada, coloque as réplicas de leitura em uma zona diferente das zonas das instâncias principal e de espera. Por exemplo, se você tiver uma instância principal na zona A e uma instância em espera na zona B, coloque as réplicas de leitura na zona C. Essa prática garante que as réplicas de leitura continuem a operar mesmo que a zona da instância primária fique inativa. Você também precisa adicionar lógica de negócios no aplicativo cliente para enviar leituras à instância principal quando as réplicas de leitura estiverem indisponíveis.

Observação: a instância de espera não pode ser usada para consultas de leitura. Isso é diferente da configuração de alta disponibilidade legada do Cloud SQL para MySQL.

Visão geral de failover

Se uma instância configurada para alta disponibilidade deixar de responder, o Cloud SQL passará a disponibilizar dados automaticamente a partir da instância de espera. Para ver se ocorreu um failover, verifique o histórico de failover do seu registro de operação.

Clique nas guias para ver como o failover afeta sua instância.

Normal

Diagrama da instância íntegra antes do failover

Failover

Diagrama da instância quando ocorre failover

Pós-failover

Diagrama da instância após o failover

Failback

Diagrama da instância após o failback

Process

Ocorre o seguinte processo:

  • A instância ou zona primária falha.

    A cada segundo, a instância primária grava em um banco de dados do sistema como um sinal de funcionamento. Se não forem detectados vários sinais de funcionamento, o failover será iniciado. Isso ocorre se a instância principal não responder por aproximadamente 60 segundos ou se a zona que contém a instância principal passar por uma interrupção.

  • Agora, a instância de espera disponibiliza dados logo após a reconexão.

    Por meio de um endereço IP estático compartilhado com a instância primária, a instância de espera agora disponibiliza dados da zona secundária.

Requisitos

Para o Cloud SQL permitir um failover, a configuração deve atender aos seguintes requisitos:

  • A instância primária precisa estar em um estado operacional normal (em oposição a um estado de execução, manutenção ou execução de uma operação de instância do Cloud SQL de longa duração, como operação de backup, importação ou exportação).
  • A zona secundária e a instância de espera devem estar em estado íntegro. Quando a instância de espera não responde e/ou a replicação para a zona secundária é interrompida, as operações de failover são bloqueadas. Após o Cloud SQL consertar a instância de espera e a zona secundária é disponibilizada, a replicação é retomada e o Cloud SQL permite o failover.

Backup e restauração

Os backups automatizados e a recuperação pontual precisam ser ativados para alta disponibilidade (a recuperação pontual usa a geração de registros binários).

Aplicativos e instâncias

Não há diferença entre trabalhar com instâncias de alta disponibilidade e instâncias comuns, portanto, seu aplicativo não precisa ser configurado de alguma maneira específica. Quando ocorre um failover, todas as conexões existentes com a instância principal e as réplicas de leitura são fechadas, e leva aproximadamente de 2 a 3 minutos para que as conexões com a instância principal sejam restabelecidas. As conexões com réplicas podem levar mais tempo. Seu aplicativo é reconectado usando a mesma string de conexão ou endereço IP, portanto, não é necessário atualizar seu aplicativo após o failover.

Para ver exatamente como seus aplicativos são afetados pelo failover, inicie-o manualmente.

Inatividade de manutenção

Os eventos de manutenção afetam as instâncias principais configuradas com alta disponibilidade da mesma forma que qualquer outra instância. As instâncias principais podem ficar inativas durante esse período. Para minimizar o impacto no serviço, é necessário definir uma janela de manutenção para controlar quando o tempo de inatividade ocorre.

Quando uma manutenção é feita em uma instância, ela não faz o failover para a instância de espera. As atualizações de manutenção são aplicadas à instância de espera ao mesmo tempo que à instância primária.

Desempenho

O desempenho do disco permanente regional depende de muitos fatores. Veja especificamente o tamanho do tipo de instância da VM e a entrada e a saída da sua carga de trabalho. Outra métrica a ser observada é que a latência do disco permanente regional com unidades de estado sólido (SSDs, na sigla em inglês) será maior do que aquela do disco permanente com SSD local. Isso significa que, se a carga de trabalho não for de streaming e sensível à latência, ela não alcançará o limite de operações de entrada/saída por segundo (IOPS), já que o disco permanente regional com SSD tem uma latência maior do que um disco permanente com SSD local. Isso acontece porque a redundância necessária para gravar duas cópias aumenta a latência de cauda.

Opção de alta disponibilidade legada do MySQL

Até o 1º trimestre de 2021, você tem a opção de usar o processo legado para adicionar a alta disponibilidade às instâncias do MySQL, o que usa uma réplica de failover. A funcionalidade legada não está disponível no Console do Cloud. Em vez disso, use os comandos gcloud ou cURL. Consulte Configuração legada: como criar uma nova instância configurada para alta disponibilidade ou Configuração legada: como configurar uma instância atual para alta disponibilidade.

A seguir