Sobre a replicação no Cloud SQL

A replicação é a capacidade de criar cópias de uma instância do Cloud SQL ou de um banco de dados local e distribuir o trabalho para as cópias.

Introdução

O principal motivo para usar a replicação é a possibilidade de escalonar o uso dos dados em um banco de dados sem prejudicar o desempenho.

Outros motivos incluem:

  • migrar dados entre regiões;
  • migrar dados entre plataformas;
  • migrar dados de um banco de dados local para o Cloud SQL.

Além disso, uma réplica poderá ser promovida se a instância original for corrompida.

Ao se referir a uma instância do Cloud SQL, a instância que é replicada é chamada de instância primária, e as cópias são chamadas de réplicas de leitura. A instância primária e as réplicas de leitura residem no Cloud SQL.

Ao se referir a um banco de dados local, o cenário de replicação é chamado de replicação a partir de um servidor externo. Nesse cenário, o banco de dados que é replicado é o servidor do banco de dados de origem. As cópias que residem no Cloud SQL são chamadas de réplicas do Cloud SQL. Há também uma instância que representa o servidor do banco de dados de origem no Cloud SQL chamada de instância de representação de origem.

Em um cenário de recuperação de desastres, você pode promover uma réplica para a converter em uma instância principal. Dessa forma, é possível usá-la em vez de uma instância que esteja em uma região com uma falha temporária. Também é possível promover uma réplica para substituir uma instância corrompida.

O Cloud SQL é compatível com os seguintes tipos de réplica:

Também é possível usar o Database Migration Service para replicação contínua de um servidor de banco de dados de origem para o Cloud SQL.

O Cloud SQL não oferece suporte à replicação entre dois servidores externos. No entanto, o Cloud SQL é compatível com a replicação baseada em identificador global de transação (GTID, na sigla em inglês). Os GTIDs identificam cada transação de forma exclusiva no servidor e em uma configuração de replicação. Como cada transação tem um identificador exclusivo, o servidor MySQL pode rastrear as transações executadas. O GTID usa coordenadas absolutas para que a réplica de uma instância do Cloud SQL possa apontar para a instância principal. Não é necessário especificar um nome de arquivo para o registro binário ou uma posição na instrução CHANGE MASTER. Há menos erros com réplicas e com recuperação pontual. Devido a esses benefícios, não é possível desativar a replicação baseada em GTID no Cloud SQL.

Réplicas de leitura

Você usará uma réplica de leitura para distribuir o trabalho de uma instância do Cloud SQL. A réplica de leitura é uma cópia exata da instância primária. Os dados e outras alterações na instância primária são atualizados quase em tempo real na réplica de leitura.

As réplicas de leitura são somente para leitura. Portanto, não é possível fazer gravações nelas. A réplica de leitura processa consultas, solicitações de leitura e tráfego de análise, reduzindo a carga na instância primária.

Você se conecta a uma réplica diretamente usando o nome de conexão e o endereço IP dela. Caso esteja se conectando a uma réplica usando um endereço IP particular, você não precisará criar mais uma conexão particular da VPC para a réplica, porque ela é herdada da instância principal.

Para informações sobre como criar uma réplica de leitura, consulte Como criar réplicas de leitura. Para informações sobre como gerenciar uma réplica de leitura, consulte Como gerenciar réplicas de leitura.

Como prática recomendada, coloque réplicas de leitura em uma zona diferente da instância principal quando usar a alta disponibilidade nessa instância. Essa prática garante que as réplicas de leitura continuem a operar quando a zona que contém a instância principal tiver uma interrupção. Consulte a Visão geral da alta disponibilidade para mais informações.

Como selecionar um tipo de máquina apropriado

As réplicas de leitura podem ter um tipo de máquina diferente da principal. É necessário monitorar métricas na instância, como o uso de CPU e memória, para garantir que a instância da réplica esteja dimensionada corretamente para a carga de trabalho, especialmente se ela for menor do que a instância principal. Uma instância de réplica que tiver um tamanho menor é mais propensa a um desempenho ruim, como eventos frequentes de memória insuficiente (OOM, na sigla em inglês).

Réplicas de leitura entre regiões

A replicação entre regiões permite criar uma réplica de leitura em uma região diferente da instância primária. Você cria uma réplica de leitura entre regiões da mesma maneira que cria uma réplica na região.

Réplicas entre regiões:

  • melhoram o desempenho de leitura disponibilizando réplicas mais próximas da região do aplicativo;
  • fornecem capacidade adicional de recuperação de desastres para oferecer proteção contra uma falha regional;
  • permitem migrar dados de uma região para outra.

Consulte Como promover réplicas para migração regional ou recuperação de desastres para mais informações sobre réplicas entre regiões.

Réplicas de leitura em cascata

A replicação em cascata permite criar uma réplica de leitura sob outra réplica de leitura na mesma região ou em uma região diferente. Veja abaixo alguns casos de uso de réplicas em cascata:

  • Recuperação de desastres: é possível usar uma hierarquia em cascata de réplicas de leitura para simular a topologia da instância principal e das réplicas de leitura. Durante uma falha temporária, sua réplica de leitura selecionada é promovida para primária e as réplicas de leitura sob a nova primária continuam a ser replicadas e estão prontas para uso.
  • Melhorias de desempenho: reduza a carga na instância principal descarregando o trabalho de replicação em várias réplicas de leitura.
  • Leituras em escala: é possível ter mais réplicas para compartilhar a carga de leitura.
  • Redução de custos: é possível reduzir custos de rede usando uma única réplica em cascata com replicação entre regiões em outras regiões.

Terminologia

  • Réplica em cascata: uma réplica de leitura que pode ter a própria réplica.
  • Níveis: é possível criar níveis de réplicas em uma hierarquia de réplicas em cascata. Por exemplo, se você adicionar quatro réplicas a uma instância, essas quatro réplicas estarão no mesmo nível.
  • Instâncias semelhantes: várias réplicas que se replicam da mesma instância principal. As semelhantes estão no mesmo nível na hierarquia de réplicas. Uma réplica pode ter oficialmente até oito semelhantes.
  • Réplica de folha: uma réplica de leitura que não tem réplicas próprias. Em uma hierarquia de replicação com vários níveis, a réplica de folha é o último nível.
  • Promover: uma ação que converte uma réplica, em qualquer nível na hierarquia, em uma instância principal. Quando promovida, a hierarquia de réplica em cascata da réplica é retida.

Configurar réplicas em cascata

As réplicas em cascata permitem adicionar réplicas de leitura a qualquer réplica atual. É possível adicionar até quatro níveis de réplicas, incluindo a instância principal. Quando você promove a réplica no topo de uma hierarquia de réplicas em cascata, ela se torna uma instância principal e as réplicas em cascata continuam a ser replicadas.

Para planejar sua configuração, é preciso ter uma meta para o que as réplicas de leitura pretendem fazer. As duas seções a seguir descrevem as configurações para recuperação de desastres e replicação multirregional.

Recuperação de desastres

Para entender como as réplicas em cascata ajudam você a se recuperar rapidamente durante uma falha temporária, considere o seguinte cenário de replicação:

Configuração

Diagrama de uma configuração de réplica em cascata com a réplica em cascata em uma região separada

Falha temporária

Diagrama da promoção durante uma falha temporária

Promoção

Diagrama da nova instância com réplicas

Se você quiser usar uma instância da Região B em uma configuração de recuperação de desastres e tiver:

  • réplicas na mesma região anexada à instância principal (Réplica A)
  • réplicas em outras regiões (réplica em cascata) anexadas à primária.

É possível criar réplicas de leitura na réplica em cascata na Região B.

Na guia Falha temporária, se houver uma interrupção na Região A, a réplica em cascata será promovida a uma instância principal. Ela já tem réplicas de leitura abaixo dela, reduzindo o objetivo de tempo de recuperação (RTO, na sigla em inglês).

Na guia Promover, você vê que, quando uma réplica em cascata é promovida, as réplicas dela também são promovidas e continuam a ser replicadas sob ela.

Replicação multirregional

Outro caso de uso de réplicas em cascata é distribuir a capacidade de leitura para uma segunda região de maneira econômica. É possível criar réplicas em C e D em cascata que replicam a partir da réplica B. Os clientes podem distribuir consultas de leitura entre as réplicas B, C e D para reduzir a carga em cada réplica. O custo do tráfego de rede entre regiões é gerado apenas uma vez, desde a instância principal até a réplica B. A replicação de B para C e D usa a transferência de rede dentro da região, que é gratuita.

É possível criar uma hierarquia de até quatro instâncias usando réplicas em cascata para replicação multirregional:

Principal A → Réplica B → Réplica C e Réplica D

Restrições

  • Não é possível excluir uma réplica que tenha réplicas sob ela. Para excluir a réplica, comece com as réplicas de folha e siga para cima na hierarquia.
  • A dependência de região circular não é compatível. Para ter a réplica de uma réplica em cascata na mesma região da instância principal, a réplica em cascata também precisa estar na mesma região.

Réplicas de leitura externas

Réplicas de leitura externas são instâncias externas do MySQL replicadas de uma instância primária do Cloud SQL. Por exemplo, uma instância do MySQL em execução no Compute Engine é considerada uma instância externa.

As réplicas de leitura externas têm as seguintes restrições:

  • A replicação para uma instância do MySQL hospedada por outra plataforma de nuvem talvez não seja possível. Verifique a documentação do outro fornecedor. Por exemplo, a definição do campo de configuração replicate-ignore-db é obrigatória, e provedores de nuvem em que isso não é permitido não são compatíveis. Consulte Como configurar réplicas externas para ver outros campos de configuração obrigatórios.
  • Se a replicação for interrompida por algumas horas, por causa de uma interrupção da rede ou do servidor, por exemplo, a réplica ficará atrasada em relação à instância primária. Assim que a réplica se reconectar à instância principal, ela perderá o atraso e começará a replicar novamente. Porém, se a replicação for interrompida por um tempo maior que o período de preservação dos registros de replicação do Cloud SQL (sete backups), você precisará excluir a réplica e criar uma nova.
  • Os dados que fluem da instância primária para a réplica externa são cobrados como transferência de dados de saída. Consulte a página de preços para conferir os valores de transferência de dados do tipo de instância do Cloud SQL.

Casos de uso da replicação

Os casos de uso a seguir se aplicam a cada tipo de replicação.

Nome Linha Réplica Benefícios e casos de uso Mais informações
Réplica de leitura Instância do Cloud SQL Instância do Cloud SQL
  • Capacidade de leitura adicional
  • Destino do Analytics
Réplica de leitura entre regiões Instância do Cloud SQL Instância do Cloud SQL
  • Capacidade de leitura adicional
  • Destino do Analytics
  • Capacidade adicional de recuperação de desastres
  • Melhorar o desempenho da leitura
  • Migrar dados entre regiões
Réplica de leitura externa Instância do Cloud SQL Instância do MySQL externa ao Cloud SQL
  • Latência reduzida para conexões externas
  • Destino do Analytics
  • Caminho de migração para outras plataformas
Replicação de um servidor externo Instância do MySQL externa ao Cloud SQL Instância do Cloud SQL para MySQL
  • Caminho de migração para o Cloud SQL
  • Replicação de dados para o Google Cloud Platform
  • Destino do Analytics

Pré-requisitos para criar uma réplica de leitura

Antes de criar uma réplica de leitura usando uma instância primária do Cloud SQL, essa instância precisa atender aos seguintes requisitos:

  • Os backups automáticos precisam estar ativados.
  • A geração de registros binários precisa estar ativada, o que exige que a recuperação pontual também esteja ativada. Saiba mais sobre o impacto desses registros.
  • Pelo menos um backup precisa ser criado após a ativação da geração de registros binários.

Requisitos adicionais para a réplica externa:

  • A versão do MySQL da réplica precisa ser igual ou mais nova do que à da instância principal. Saiba mais.
  • Por questões de segurança, configure o SSL/TLS na instância principal. Saiba mais.

Impacto da ativação da geração de registros binários

É preciso ativar a recuperação pontual para ativar a geração de registros binários na instância primária para ter compatibilidade com as réplicas de leitura. Fazer isso causa os seguintes impactos:

  • Sobrecarga no desempenho

    O Cloud SQL usa a replicação baseada em linhas com as sinalizações sync_binlog=1 e innodb_support_xa=true do MySQL. Por isso, um disco extra fsync (em inglês) é obrigatório para cada operação de gravação, o que reduz o desempenho.

  • Sobrecarga no armazenamento

    O armazenamento dos registros binários é cobrado com a mesma taxa dos dados regulares. Os registros binários são automaticamente truncados para a idade do backup automático mais antigo. Atualmente, o Cloud SQL mantém os sete backups automatizados mais recentes e todos os backups sob demanda. O tamanho dos registros binários e, portanto, do valor cobrado, depende da carga de trabalho. Por exemplo, uma carga de trabalho com muita gravação consome mais espaço do registro binário do que uma de muita leitura.

    Use o comando do MySQL SHOW BINARY LOGS (em inglês) para ver o tamanho dos registros binários.

    Quando os backups são realizados, os registros são armazenados neles com os dados.

Geração de registros binários em réplicas de leitura

  • A geração de registros binários é compatível com instâncias de réplica de leitura (somente MySQL 5.7 e 8.0). É possível ativar a geração de registros binários em uma réplica com os mesmos comandos de API que a instância principal, usando o nome da instância da réplica em vez do nome da instância principal. Os termos enable binary logging e enable point-in-time recovery são intercambiáveis.

    A durabilidade da geração de registros binários na réplica (mas não na instância principal) pode ser definida com a sinalização sync_binlog, que controla com que frequência o servidor MySQL sincroniza o registro binário para o disco.

    A geração de registros binários pode ser ativada em uma réplica, mesmo quando o backup está desativado na principal.

    Se uma réplica que tiver esse valor definido for promovida a um servidor independente, a configuração será redefinida para o valor seguro 1 no servidor autônomo.

Faturamento

  • Uma réplica de leitura é cobrada segundo a mesma taxa de uma instância padrão do Cloud SQL. Não há cobrança pela replicação de dados.
  • Para réplicas externas, os dados que fluem da instância primária para a réplica externa são cobrados como transferência de dados. Consulte a página de preços para saber os valores da transferência de dados do seu tipo de instância do Cloud SQL.
  • O preço de uma réplica de leitura entre regiões é igual ao de criar uma nova instância do Cloud SQL na região. Consulte Preços de instâncias do Cloud SQL e selecione a região apropriada. Além do custo normal associado à instância, uma réplica entre regiões gera cobranças de transferência de dados entre regiões referentes aos registros de replicação enviados da instância primária para a de réplica, conforme descrito em Preços de saída da rede.

Referência rápida para réplicas de leitura do Cloud SQL

Tópico Discussão
Backups Você não pode configurar backups na réplica.
Núcleos e memória As réplicas de leitura podem usar um número diferente de núcleos e uma quantidade diferentes de memória daqueles da instância primária.
Como excluir a instância principal Antes de excluir uma instância principal, você precisa promover todas as réplicas de leitura dela para instâncias independentes ou remover as réplicas.
Como excluir a réplica Quando você exclui uma réplica, não há impacto no status da instância principal.
Como desativar a geração de registros binários Antes de desativar os registros binários em uma instância principal, é preciso promover ou excluir todas as réplicas de leitura dela.
Failover Uma instância principal pode fazer o failover para uma réplica somente se a réplica for uma réplica de DR. As réplicas de leitura não podem fazer failover de forma alguma durante uma interrupção.
Alta disponibilidade As réplicas de leitura permitem que você ative a alta disponibilidade nas réplicas.
Balanceamento de carga O Cloud SQL não fornece balanceamento de carga entre réplicas. É possível implementar o balanceamento de carga na instância do Cloud SQL. Também é possível usar o pool de conexão para distribuir consultas entre as réplicas com a configuração de balanceamento de carga para ter melhor desempenho.
Janelas de manutenção Não é possível configurar janelas de manutenção em uma réplica de leitura. No entanto, as réplicas de leitura compartilham janelas de manutenção com a instância principal. Durante a manutenção, o Cloud SQL atualiza todas as réplicas de leitura antes de atualizar a instância principal.
Várias réplicas de leitura O Cloud SQL tem suporte a réplicas em cascata. Como resultado, é possível criar até 10 réplicas para uma única instância principal, e as réplicas podem ser encadeadas para até quatro níveis, incluindo a principal.
Replicação paralela Para informações sobre o uso da replicação paralela para melhorias de desempenho, consulte Como configurar a replicação paralela.
IP privado Caso esteja se conectando a uma réplica usando um endereço IP particular, você não precisará criar mais uma conexão particular da VPC para a réplica, porque ela é herdada da instância principal.
Como restaurar a instância principal Enquanto uma réplica existir, não será possível restaurar a instância principal dela. Antes de restaurar uma instância de um backup ou executar uma recuperação pontual, é necessário promover ou excluir todas as réplicas da instância.
Configurações As configurações MySQL da instância principal são propagadas para a réplica, incluindo a senha raiz e as mudanças feitas na tabela do usuário. As alterações de CPU e memória não são propagadas para a réplica.
Como interromper uma réplica Não é possível interromper (stop) uma réplica, apenas instâncias principais. Ela pode ser restart, delete ou disable replication, mas não é possível interromper a réplica como interromper uma instância primária.
Como fazer upgrade de uma réplica É possível que as réplicas de leitura passem por um upgrade que as interrompa a qualquer momento.
Tabelas do usuário Não é possível fazer alterações na réplica. Todas as modificações do usuário precisam ser realizadas na instância primária.

A seguir