Sobre a alta disponibilidade

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

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 falha temporária zonal ou quando uma instância fica sem memória. A alta disponibilidade permite que seus dados continuem disponíveis para aplicativos cliente.

A configuração de alta disponibilidade oferece redundância de dados. Uma instância do Cloud SQL configurada para alta disponibilidade também é chamada de instância regional e tem uma zona primária 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. No caso de uma falha na instância ou zona, a instância em espera se tornará a nova instância primária. Os usuários então serão redirecionados para a nova rede principal. Esse processo é chamado de failover.

Observação: em alguns casos, o Cloud SQL emite um reinício em vez de um failover. Quando isso acontece, você vê Reiniciar como uma operação na instância quando visualiza o painel Operações e registros na instância Visão geral ou na página Operações da instância.

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. Depois que a zona ou instância que apresentou uma interrupção ficar novamente disponível, a instância primária original será 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 de alta disponibilidade custa o dobro de uma instância autônoma. 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

Se a disponibilidade for uma consideração para suas réplicas de leitura, é possível ativar a alta disponibilidade nas réplicas. Quando você promove essa réplica para se tornar uma instância principal, ela já está configurada como uma instância altamente disponível.

Durante uma falha temporária zonal, o tráfego para de ler réplicas na zona. 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 não estiverem localizadas em uma zona que está passando por uma falha temporária, elas se conectarão à instância em espera quando ela se tornar a instância principal.

Como prática recomendada, coloque algumas das réplicas de leitura em uma zona diferente das instâncias primária e de espera. Por exemplo, se você tiver uma instância primária na zona A e uma instância em espera na zona B, coloque uma réplica de leitura na zona C para melhorar a confiabilidade. 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 algum failover, consulte o histórico de failover do registro de operações.

Saiba mais sobre como criar consultas no Explorador de registros. Se você precisar de informações mais detalhadas sobre uma operação, como o usuário que a executou, ative a geração de registros de auditoria.

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, o sistema de batimento cardíaco detecta se a instância principal está integrada. Se não forem detectados vários sinais de funcionamento, o failover será iniciado.

  • 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).
  • A zona secundária e a instância de espera devem estar em estado íntegro. Quando a instância em espera não responde, as operações de failover são bloqueadas. Depois que o Cloud SQL repara a instância de espera e a zona secundária está disponível, o Cloud SQL permite failover.

Backup e restauração

Os backups automatizados e a recuperação pontual precisam ser ativados para alta disponibilidade (a recuperação pontual usa 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. 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 maneira que outras instâncias. As instâncias principais podem ficar inativas por um breve período. Para mais informações sobre como a manutenção afeta as instâncias de alta disponibilidade, consulte Como funciona a manutenção. Para minimizar o impacto no serviço, altere as configurações de manutenção para controlar quando o tempo de inatividade ocorre.

Desempenho

O desempenho do disco permanente regional depende de muitos fatores. As operações de entrada/saída por segundo (IOPS) podem ser reduzidas com o disco permanente regional em comparação com o disco permanente zonal. Veja 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 o SSD zonal. Isso significa que, se a carga de trabalho não for de streaming e for sensível à latência, ela não conseguirá alcançar o limite de IOPS porque o disco permanente regional com SSD tem latência maior do que um disco permanente com SSD zonal. Isso se deve à replicação síncrona dos dados entre várias zonas envolvidas em um disco permanente regional para fornecer várias cópias de dados entre as zonas de uma região.

Opção de alta disponibilidade legada do MySQL

O processo legado para adicionar alta disponibilidade a instâncias do MySQL usa uma réplica de failover. A funcionalidade legada não está disponível no Console do Google Cloud. 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