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

Esta página apresenta uma visão geral de como funciona a configuração de alta disponibilidade para instâncias do MySQL Segunda Geração. Para configurar uma instância nova ou existente para alta disponibilidade, consulte Como configurar uma instância para alta disponibilidade.

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

A configuração de alta disponibilidade, também chamada de cluster, fornece redundância de dados. A configuração é composta de uma instância principal (mestre) na zona principal e uma réplica de failover na zona secundária. Por meio da replicação semissíncrona, todas as alterações feitas nos dados da instância principal e nas tabelas do usuário são copiadas na réplica de failover. No caso de uma falha de instância ou zona, essa configuração reduz o tempo de inatividade e seus dados continuam disponíveis para aplicativos cliente.

A réplica de failover é faturada como uma instância separada. Para mais informações, consulte a página de preços.

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

Réplicas de failover

A réplica de failover é configurada com os mesmos sinalizadores do banco de dados, usuários (incluindo o root) e senhas, aplicativos e redes autorizados e bancos de dados contidos na instância principal.

Limitações

As réplicas de failover têm as seguintes limitações:

  • É necessário que a réplica de failover esteja na mesma região da instância principal, mas em uma zona diferente.
  • Você pode criar apenas uma réplica de failover para cada instância primária.
  • Não é possível alterar a política de ativação ou a janela de manutenção da réplica de failover. As réplicas de failover têm a mesma janela de manutenção da instância principal.
  • Não é possível ativar backups na réplica de failover. Os backups precisam ser realizados na instância principal.
  • Você pode criar uma réplica de failover somente a partir da instância principal, não de réplicas de leitura.

Visão geral de failover

Se uma instância configurada para alta disponibilidade deixar de responder, o Cloud SQL alternará automaticamente para a disponibilização de dados da réplica de failover. É isso que chamamos de failover. Para ver se ocorreu algum, verifique o histórico de failover do seu registro de operações.

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

Normal

Diagrama do MySQL de uma instância íntegra antes do failover

Failover

Diagrama do MySQL da instância quando o failover ocorre

Resultado

Diagrama MySQL da instância após o failover com resultados

Processo

O processo a seguir ocorre:

  1. A instância principal falha.

    A cada segundo, a instância principal grava em um banco de dados do sistema como um sinal de funcionamento. Se vários sinais de funcionamento não forem detectados, e a réplica de failover estiver íntegra, o failover é iniciado. Isso ocorre se a instância principal não responder por aproximadamente 60 segundos ou se a zona principal sofrer uma interrupção.

  2. O Cloud SQL aguarda a réplica de failover alcançar o estado da instância principal.

    A quantidade de tempo que essa etapa leva é afetada pelo atraso de replicação.

  3. A réplica de failover é promovida para a função de instância principal.

    Agora, a réplica de failover disponibiliza dados da zona secundária, e o nome da instância e o endereço IP são movidos para a antiga réplica de failover. O aplicativo cliente se reconecta à nova instância primária sem precisar alterar a sequência de conexão porque o endereço IP da instância principal foi movido automaticamente. Para ver de que zona sua instância está disponibilizando dados, acesse a página Visão geral no console do GCP.

  4. Uma réplica de failover é recriada.

    A nova réplica de failover retém o endereço IP da réplica de failover de entrada e é recriada automaticamente em uma zona íntegra.

  5. As réplicas de leitura são recriadas.

    Novas réplicas de leitura retêm o endereço IP da réplica de leitura recebida e são recriadas automaticamente em uma zona íntegra.

Requisitos

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

  • A replicação precisa apresentar um estado íntegro.
  • A instância principal precisa estar em um estado operacional normal (em oposição a um estado de interrupção, de manutenção ou de uma operação de longa duração).
  • Não pode haver operações administrativas em andamento na réplica de failover. Se o failover for iniciado imediatamente após ou durante uma operação administrativa, como uma exportação, a solicitação de failover falhará.
  • A réplica de failover precisa estar disponível. Caso contrário, a solicitação de failover falhará se o procedimento for iniciado. Se a solicitação for devida a uma instância principal não íntegra, essa instância sofrerá uma interrupção.
  • O atraso de replicação precisa ser aceitável. Se o atraso de replicação for superior a 10 minutos, o failover de uma instância não íntegra não será iniciado pelo Cloud SQL. Failovers iniciados pelo usuário e failovers devidos a uma interrupção zonal ainda serão tentados.

Integridade da configuração

Disponibilidade de réplica de failover

A disponibilidade da réplica de failover é fornecida como uma métrica da instância principal, não como uma métrica da réplica de failover:

cloudsql.googleapis.com/database/available_for_failover

Esse estado também é incluído na resposta da solicitação Get da instância principal no campo failoverReplica.available.

Você pode usar o Stackdriver para visualizar suas métricas de configuração de alta disponibilidade. Para uma lista completa das métricas do Cloud SQL fornecidas pelo Stackdriver, consulte a lista de métricas do Cloud SQL. Para mais informações sobre como usar o Stackdriver com o GCP, consulte a documentação do Stackdriver.

Atraso da replicação

Visão geral

Por meio da replicação semissíncrona, toda operação de gravação para a instância principal exige que a mesma atualização seja feita na respectiva réplica de failover. Para minimizar o impacto no desempenho da instância principal e, ao mesmo tempo, garantir que as alterações nunca sejam perdidas, a réplica de failover registra os eventos de atualização e, em seguida, executa as atualizações em ordem. Se os eventos de atualização chegarem mais rápido do que a réplica de failover consegue executá-los, ela estará atrasada em relação à instância principal. A diferença de tempo entre o momento em que a instância principal faz uma atualização e o momento em que a réplica de failover alcança essa atualização do respectivo registro é chamada de atraso da replicação.

Embora o atraso da replicação possa aumentar o tempo de failover, todas as transações gerenciadas pela instância principal também são inseridas nos registros da réplica de failover. O atraso da replicação não causa perda de dados.

Como resolver o atraso da replicação

Se o atraso da replicação for causado por um pico incomum de gravações na instância principal, geralmente a réplica de failover pode alcançar a instância principal depois que a carga diminuir novamente. Se esse atraso for longo, mas constante, você poderá excluir a réplica de failover e criá-la novamente. No entanto, se a carga de gravação continuar e o atraso da replicação aumentar ainda mais, será necessário intervir. Se o atraso da replicação se elevar demais, isso poderá afetar a cobertura do SLA da sua instância. Saiba mais.

Como as réplicas recebem as gravações pendentes de maneira serial, elas funcionam como uma instância de thread único. Aumentar a RAM na réplica de failover ou aumentar o disco dela para permitir maior capacidade de E/S pode ajudar em algumas situações. Porém, se a réplica de failover estiver cronicamente atrasada em relação à instância principal, será necessário fragmentar seu banco de dados para que as operações de gravação sejam compartilhadas entre várias instâncias principais.

Métrica

O estado de atraso da replicação é fornecido como uma métrica de réplica de failover:

cloudsql.googleapis.com/database/mysql/replication/seconds_behind_master

O valor dessa métrica representa o número de segundos que a réplica está atrasada em relação à instância principal.

Para informações sobre como configurar um alerta do Stackdriver para essa métrica, consulte Como criar um alerta para o atraso da replicação.

Backups e restaurações

Configurar uma instância para alta disponibilidade não afeta sua necessidade de backups ou como você os cria, mas afeta a maneira como você restaura uma instância. Antes de poder restaurar sua instância principal usando um backup ou executar uma recuperação pontual em sua instância principal, é necessário excluir todas as réplicas de failover e de leitura. Após a conclusão da restauração, é necessário recriar seu failover e ler as réplicas.

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 são fechadas. No entanto, seu aplicativo pode se reconectar usando a mesma sequência de conexão ou endereço IP. Você não precisa atualizar seu aplicativo após o failover. Por algum tempo, durante o failover, a conexão com o banco de dados não será possível para os aplicativos.

Para ver exatamente como seus aplicativos são afetados pelo failover, você deve iniciá-lo manualmente.

A seguir

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Cloud SQL para MySQL