Gerenciar réplicas de leitura

Nesta página, você verá como gerenciar réplicas de leitura. Essas operações incluem desativar e ativar a replicação, promover uma réplica, configurar a replicação paralela e verificar o status da replicação.

Para mais informações sobre como funciona a replicação, consulte Replicação no Cloud SQL.

Desativar replicação

Por padrão, uma réplica começa com a replicação ativada. No entanto, é possível desativar a replicação, por exemplo, para depurar ou analisar o estado de uma instância. Ao terminar, reative a replicação explicitamente. Desativar ou reativar a replicação não reinicia a instância da réplica.

Quando a replicação é desativada, isso não interrompe a instância da réplica: ela se torna uma instância somente leitura que não é mais replicada da instância principal. Você continuará sendo cobrado pela instância. Na réplica desativada, é possível reativar a replicação, excluir a réplica ou promovê-la a uma instância autônoma.

Para desativar a replicação:

Console

  1. No console do Google Cloud, acesse a página Instâncias do Cloud SQL.

    Acesse "Instâncias do Cloud SQL"

  2. Selecione uma instância de réplica clicando no nome dela.
  3. Clique em Desativar replicação na barra de botões.
  4. Clique em OK.

gcloud

gcloud sql instances patch REPLICA_NAME \
--no-enable-database-replication

REST v1

Para executar esse comando cURL em um prompt de linha de comando, adquira um token de acesso. Basta usar o comando gcloud auth print-access-token. Use também o APIs Explorer na página "Instâncias: patch" para enviar a solicitação da API REST.

Antes de usar os dados da solicitação abaixo, faça as substituições a seguir:

  • project-id: o ID do projeto
  • replica-name: o nome da instância da réplica

Método HTTP e URL:

PATCH https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name

Corpo JSON da solicitação:

{
  "settings":
  {
    "databaseReplicationEnabled": "False"
  }
}

Para enviar a solicitação, expanda uma destas opções:

Você receberá uma resposta JSON semelhante a esta:

REST v1beta4

Para executar esse comando cURL em um prompt de linha de comando, adquira um token de acesso. Basta usar o comando gcloud auth print-access-token. Use também o APIs Explorer na página "Instâncias: patch" para enviar a solicitação da API REST.

Antes de usar os dados da solicitação abaixo, faça as substituições a seguir:

  • project-id: o ID do projeto
  • replica-name: o nome da instância da réplica

Método HTTP e URL:

PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name

Corpo JSON da solicitação:

{
  "settings":
  {
    "databaseReplicationEnabled": "False"
  }
}

Para enviar a solicitação, expanda uma destas opções:

Você receberá uma resposta JSON semelhante a esta:

Ativar replicação

Se uma réplica não for replicada por muito tempo, ela demorará mais para alcançar a instância principal. Nesse caso, exclua a réplica e crie uma nova.

Para ativar a replicação:

Console

  1. No console do Google Cloud, acesse a página Instâncias do Cloud SQL.

    Acesse "Instâncias do Cloud SQL"

  2. Selecione uma instância de réplica clicando no nome dela.
  3. Clique em Ativar replicação.
  4. Clique em OK.

gcloud

gcloud sql instances patch REPLICA_NAME \
--enable-database-replication

REST v1

Para executar esse comando cURL em um prompt de linha de comando, adquira um token de acesso. Basta usar o comando gcloud auth print-access-token. Use também o APIs Explorer na página "Instâncias: patch" para enviar a solicitação da API REST.

Antes de usar os dados da solicitação abaixo, faça as substituições a seguir:

  • project-id: o ID do projeto
  • replica-name: o nome da instância da réplica

Método HTTP e URL:

PATCH https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name

Corpo JSON da solicitação:

{
  "settings":
  {
    "databaseReplicationEnabled": "True"
  }
}

Para enviar a solicitação, expanda uma destas opções:

Você receberá uma resposta JSON semelhante a esta:

REST v1beta4

Para executar esse comando cURL em um prompt de linha de comando, adquira um token de acesso. Basta usar o comando gcloud auth print-access-token. Use também o APIs Explorer na página "Instâncias: patch" para enviar a solicitação da API REST.

Antes de usar os dados da solicitação abaixo, faça as substituições a seguir:

  • project-id: o ID do projeto
  • replica-name: o nome da instância da réplica

Método HTTP e URL:

PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name

Corpo JSON da solicitação:

{
  "settings":
  {
    "databaseReplicationEnabled": "True"
  }
}

Para enviar a solicitação, expanda uma destas opções:

Você receberá uma resposta JSON semelhante a esta:

Promover uma réplica

Promover uma réplica de leitura interrompe a replicação e converte a instância em uma instância primária independente do Cloud SQL com recursos de leitura e gravação.

Quando promovidas, as réplicas de leitura são configuradas automaticamente com backups, mas não são configuradas automaticamente como instâncias de alta disponibilidade (HA, na sigla em inglês). É possível ativar a alta disponibilidade depois de promover a réplica, assim como faria para qualquer instância que não seja réplica. Configurar uma réplica de leitura para alta disponibilidade é feito da mesma maneira que em uma instância principal. Saiba mais sobre como configurar a instância para alta disponibilidade.

Antes de promover uma réplica de leitura, se a principal ainda estiver disponível e atendendo aos clientes, faça o seguinte:

  1. Interrompa todas as gravações na instância principal.
  2. Verifique o status da replicação. Siga as instruções na guia MySQL Client.
  3. Verifique se a réplica está replicando e aguarde até que o atraso da replicação relatado pela métrica Seconds_Behind_Master seja 0.

Caso contrário, uma instância recém-promovida pode não ter algumas transações confirmadas na instância principal.

Para promover uma réplica a uma instância autônoma:

Console

  1. No console do Google Cloud, acesse a página Instâncias do Cloud SQL.

    Acesse "Instâncias do Cloud SQL"

  2. Selecione uma instância de réplica clicando no nome dela.
  3. Clique em Promover réplica.
  4. Clique em OK.

gcloud

gcloud sql instances promote-replica REPLICA_NAME

REST v1

Para executar esse comando cURL em um prompt de linha de comando, adquira um token de acesso. Basta usar o comando gcloud auth print-access-token. Use também o APIs Explorer na página "Instâncias: promoteReplica" para enviar a solicitação da API REST.

Antes de usar os dados da solicitação abaixo, faça as substituições a seguir:

  • project-id: o ID do projeto
  • replica-name: o nome da instância da réplica

Método HTTP e URL:

POST https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name/promoteReplica

Para enviar a solicitação, expanda uma destas opções:

Você receberá uma resposta JSON semelhante a esta:

REST v1beta4

Para executar esse comando cURL em um prompt de linha de comando, adquira um token de acesso. Basta usar o comando gcloud auth print-access-token. Use também o APIs Explorer na página "Instâncias: promoteReplica" para enviar a solicitação da API REST.

Antes de usar os dados da solicitação abaixo, faça as substituições a seguir:

  • project-id: o ID do projeto
  • replica-name: o nome da instância da réplica

Método HTTP e URL:

POST https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name/promoteReplica

Para enviar a solicitação, expanda uma destas opções:

Você receberá uma resposta JSON semelhante a esta:

Confirme se a instância promovida está configurada corretamente. Em particular, configure a instância para alta disponibilidade, se necessário.

Configurar a replicação paralela

Reduzir o atraso da replicação é importante para gerenciar o desempenho da replicação. O atraso de replicação ocorre quando as atualizações em uma réplica de leitura são realizadas depois das atualizações na instância principal. Nesta seção, descrevemos como os usuários podem ativar a replicação paralela, o que pode reduzir o atraso da replicação.

Na replicação do MySQL, uma thread de replicação SQL é usada para executar as transações coletadas no registro de redirecionamento na réplica de leitura. A replicação paralela reduz o atraso da replicação ao aumentar o número de threads do SQL que trabalham para executar essas transações. Réplicas de leitura com replicação paralela ativada às vezes são chamadas de réplicas multithread.

A replicação paralela está disponível nestes três cenários no Cloud SQL para MySQL:

Para simplificar, esta página usa os termos "instância primária" e "réplica de leitura".

Etapas básicas para alterar sinalizações de replicação paralela

As etapas para ativar a replicação paralela são as seguintes:

  1. Em uma réplica de leitura, desative a replicação.
  2. Na réplica de leitura, defina as sinalizações da replicação paralela. Use o gcloud comando para definir a sinalização. A opção do Console do Google Cloud fica desativada enquanto a replicação estiver desativada.
  3. Na réplica de leitura, ative a replicação.
  4. Opcionalmente, na instância primária, defina as sinalizações para otimizar o desempenho para replicação paralela.

Réplicas de leitura: sinalizações para replicação paralela

O Cloud SQL para MySQL aceita várias sinalizações para replicação paralela em réplicas de leitura. Para informações sobre as sinalizações, clique nestes links para a documentação do MySQL 8.0:

A alteração dessas sinalizações não reinicia a réplica de leitura.

A tabela a seguir contém os intervalos permitidos e os valores padrão para essas sinalizações:

Sinalização da réplica de leitura Valores permitidos Valor padrão do MySQL 5.7 Valor padrão do MySQL 8.0 e versões mais recentes
replica_parallel_workers 0-1024 0 0 (MySQL 8.0.26 e versões anteriores)
4 (MySQL 8.0.27 e versões mais recentes)
replica_parallel_type DATABASE, LOGICAL_CLOCK DATABASE DATABASE (MySQL 8.0.26 e versões anteriores)
LOGICAL_CLOCK (MySQL 8.0.27 e versões mais recentes)
replica_preserve_commit_order ON, OFF OFF OFF (MySQL 8.0.26 e versões anteriores)
ON (MySQL 8.0.27 e versões mais recentes)
replica_pending_jobs_size_max 1024-1 GB 16 MB 128 MB

A sinalização replica_preserve_commit_order impede lacunas na sequência de transações executadas do registro de redirecionamento da réplica.

A configuração replica_preserve_commit_order=1 requer o seguinte:

A sinalização replica_pending_jobs_size_max define a memória máxima, em bytes, disponível para filas de aplicadores que contêm eventos que ainda não foram aplicados.

Instância principal: sinalizações para replicação paralela

O Cloud SQL para MySQL é compatível com várias sinalizações para uso em uma instância primária. Use essas sinalizações para ajustar o desempenho da replicação das réplicas de leitura associadas com a replicação paralela ativada. Para informações sobre as sinalizações, clique nestes links para a documentação do MySQL 8.0:

A alteração dessas sinalizações não reinicia a instância primária.

A tabela a seguir contém os intervalos permitidos e os valores padrão para essas sinalizações:

Sinalização de instância primária Valores permitidos Valor padrão do MySQL 5.7 Valor padrão do MySQL 8.0 Valor padrão do MySQL 8.4
binlog_transaction_dependency_history_size 1-1000000 25.000 25.000 25.000
binlog_transaction_dependency_tracking COMMIT_ORDER, WRITESET, WRITESET_SESSION COMMIT_ORDER WRITESET n/a (descontinuado no MySQL 8.4)
transaction_write_set_extraction OFF, MURMUR32, XXHASH64 OFF XXHASH64 n/a (descontinuado no MySQL 8.4)

No MySQL 5.7, se binlog_transaction_dependency_tracking estiver definido como WRITESET ou WRITESET_SESSION, transaction_write_set_extraction precisará ser definido como um valor que não seja OFF (XXHASH64 ou MURMUR32).

Verificar o status da replicação

Ao visualizar uma instância de réplica usando o Console do Google Cloud ou fazer login na instância usando um cliente de administração, você recebe detalhes sobre a replicação, incluindo o status e as métricas. Ao usar a CLI gcloud, você recebe um breve resumo da configuração de replicação.

Antes de verificar o status da replicação de uma instância de réplica do Cloud SQL, use o comando
gcloud sql instances describe para exibir o status da instância. Como resultado, é possível ver se a replicação está ativada para a instância de réplica.

As métricas a seguir estão disponíveis para instâncias de réplica. Saiba mais sobre outras métricas disponíveis para todas as instâncias, incluindo instâncias que não são de réplica.

MétricaDescrição
Estado de replicação
(cloudsql.googleapis.com/database/replication/state)

Indica se a replicação está transmitindo registros ativamente da primária para a réplica. Valores possíveis:

  • Running
  • Stopped
  • Error

Essa métrica mostrará Running se a E/S e as linhas de execução SQL da réplica informarem que estão em execução. Veja as métricas do Estado de execução das linhas de execução subordinadas da E/S e do Estado de execução das linhas de execução subordinadas do SQL abaixo para mais informações ou consulte Como verificar o status de replicação (em inglês) no Manual de referência do MySQL.
Lag de replicação
(cloudsql.googleapis.com/database/replication/replica_lag)

O tempo que o estado da réplica está atrasando se comparado ao estado da instância principal. Essa é a diferença entre (1) a hora atual e (2) o carimbo de data/hora original em que a principal confirmou a transação que está sendo aplicada na réplica. Em especial, as gravações podem ser consideradas atrasadas, mesmo que tenham sido recebidas pela réplica, caso a réplica ainda não tenha aplicado a gravação ao banco de dados.

Para réplicas em cascata, cada par de réplicas primárias é monitorado separadamente, e não há uma única métrica que produza o atraso completo (principal para réplica).

Essa métrica informa o valor de Seconds_Behind_Master quando SHOW REPLICA STATUS é executado na réplica. Para mais informações, consulte Como verificar o status da replicação no Manual de referência do MySQL.
Lag da rede
(cloudsql.googleapis.com/database/replication/network_lag)

O tempo, em segundos, desde a gravação do binlog no banco de dados primário até a linha de execução de E/S na réplica.

Se network_lag for zero ou insignificante, mas `replica_lag` for alto, isso indica que a linha de execução SQL não pode aplicar mudanças de replicação com rapidez suficiente.
Estado de execução da linha subordinada de E/S
(cloudsql.googleapis.com/database/mysql/replication/slave_io_running_state)

Indica se a linha de execução de E/S para leitura do registro binário da instância principal está sendo executada na réplica. Valores possíveis:

  • Yes
  • No
  • Connecting

Essa métrica informa o valor de Slave_IO_Running quando SHOW REPLICA STATUS é executado na réplica. Para mais informações, consulte Como verificar o status da replicação no Manual de referência do MySQL.
Estado de execução da linha subordinada de SQL
(cloudsql.googleapis.com/database/mysql/replication/slave_sql_running_state)

Indica se a linha de execução do SQL para executar eventos no registro de retransmissão está em execução na réplica. Valores possíveis:

  • Yes
  • No
  • Connecting

Essa métrica informa o valor de Slave_SQL_Running quando SHOW REPLICA STATUS é executado na réplica. Para mais informações, consulte Como verificar o status da replicação no Manual de referência do MySQL.

Para verificar o status da replicação:

Console

O Cloud SQL informa as métricas Replication State e Replication Lag no painel padrão de monitoramento do Cloud SQL.

Para visualizar outras métricas de réplicas regionais e entre regiões, além de réplicas de servidores externos, crie um painel personalizado e adicione as métricas que você quer monitorar a ele:

  1. No console do Google Cloud, acesse a página Monitoring.

    Acessar Monitoring

  2. Selecione a guia Painéis.
  3. Clique em Criar painel.
  4. Dê um nome ao painel e clique em OK.
  5. Clique em Adicionar gráfico.
  6. Para Tipo de recurso, selecione Cloud SQL Database.
  7. Execute um dos seguintes procedimentos:
    1. Para monitorar a métrica do estado de replicação: no campo Selecione uma métrica, digite Replication state. Em seguida, adicione um filtro para state = "Running". O gráfico mostrará 1 se a replicação estiver em execução e 0 se não estiver.
    2. Para monitorar a métrica de atraso de replicação: no campo Selecione uma métrica, digite replica_lag. O gráfico mostra a quantidade de tempo decorrido pelo estado da réplica em relação à principal.
    3. Para monitorar o status da linha de execução de E/S da réplica: no campo Selecione uma métrica, digite Slave I/O thread running state. Em seguida, adicione um filtro a state = "Yes". O gráfico mostra 1 se a linha de execução estiver em execução e 0 se não estiver.
    4. Para monitorar o status da linha de execução do SQL da réplica: no campo Selecione uma métrica, digite Slave SQL thread running state. Em seguida, adicione um filtro a state = "Yes". O gráfico mostra 1 se a linha de execução estiver em execução e 0 se não estiver.

gcloud

Na instância da réplica, verifique o status da replicação com:

gcloud sql instances describe REPLICA_NAME

Na saída, procure as propriedades databaseReplicationEnabled e masterInstanceName.

Para uma instância principal, verifique se há réplicas com:

gcloud sql instances describe PRIMARY_INSTANCE_NAME

Na saída, procure a propriedade replicaNames.

Cliente MySQL

  1. Conecte-se à réplica com um cliente MySQL.

    Para mais informações, consulte Opções de conexão para aplicativos externos,

  2. Verifique o status da réplica: 
    SHOW REPLICA STATUS \G

    Procure as seguintes métricas na saída do comando:

    • Master_Host: o nome da instância principal.
    • Slave_IO_Running, Slave_SQL_Running: se as linhas de execução de E/S e SQL, respectivamente, estão em execução. Essas conversas são responsáveis por transferir eventos da principal para o registro de redirecionamento da réplica e executá-los nesse registro. O valor da métrica será Yes se a linha de execução estiver em execução. As duas linhas de execução precisam estar em execução para que a replicação fique ativa.
    • Seconds_Behind_Master: o tempo, em segundos, pelo qual a réplica atrasa no processamento das transações da principal, ou seja, a diferença entre (1) o horário atual e (2) o carimbo de data/hora original em que a principal confirmou a transação que está sendo aplicada no momento na réplica. O valor será NULL se a replicação for inválida.
    • Master_Log_file, Read_Master_Log_Pos, Relay_Master_Log_File, Exec_Master_Log_Pos: essas métricas mostram as coordenadas (nome do arquivo e deslocamento) em que a linha de execução de E/S tem eventos de leitura (Master_Log_file e Read_Master_Log_Pos) e em que a linha de execução SQL executou eventos (Relay_Master_Log_File e Exec_Master_Log_Pos). Se forem iguais (ou seja, Master_Log_file for igual a Relay_Master_Log_File e Read_Master_Log_Pos for igual a Exec_Master_Log_Pos) a réplica processou todos os eventos recebidos da principal.

Para mais detalhes sobre a saída desse comando, consulte a documentação do MySQL sobre Como verificar o status da replicação.

Resolver problemas

Problema Solução de problemas
A réplica de leitura não começou a ser replicada na criação. Provavelmente há um erro mais específico nos arquivos de registro. Inspecione os registros no Cloud Logging para encontrar o erro real.
Não foi possível criar a réplica de leitura: erro invalidFlagValue. Uma das sinalizações na solicitação é inválida. Pode ser uma sinalização fornecida explicitamente ou uma que foi definida como um valor padrão.

Primeiro, verifique se o valor da sinalização max_connections é maior ou igual ao valor na instância principal.

Se a sinalização max_connections estiver definida corretamente, inspecione os registros no Cloud Logging para encontrar o erro real.
Não foi possível criar a réplica de leitura: erro desconhecido. Provavelmente há um erro mais específico nos arquivos de registro. Inspecione os registros no Cloud Logging para encontrar o erro real.

Se o erro for: set Service Networking service account as servicenetworking.serviceAgent role on consumer project, desative e reative o Service Networking API. Essa ação cria a conta de serviço necessária para continuar com o processo.
O disco está cheio. O tamanho do disco da instância principal pode ficar cheio durante a criação da réplica. Edite a instância principal com upgrade para um tamanho de disco maior.
A instância da réplica está usando memória demais. A réplica usa memória temporária para armazenar em cache as operações de leitura solicitadas com frequência, o que pode fazer com que ela use mais memória do que a instância principal.

Reinicie a instância da réplica para recuperar o espaço de memória temporário.
Replicação interrompida. O limite máximo de armazenamento foi atingido e o aumento automático de armazenamento não está ativado.

Edite a instância para ativar automatic storage increase.
O atraso da replicação é consistentemente alto. A carga de gravação é alta demais para a réplica processar. O atraso de replicação ocorre quando a linha de execução SQL em uma réplica não consegue acompanhar a linha de execução de E/S. Alguns tipos de consultas ou cargas de trabalho podem causar um atraso de replicação temporário ou permanente para um determinado esquema. Estas são algumas das causas comuns do atraso de replicação:
  • Consultas lentas na réplica. Encontre e corrija esses problemas.
  • Todas as tabelas precisam ter uma chave primária/exclusiva. Cada atualização em uma tabela sem uma chave exclusiva/principal resulta em varreduras completas na tabela da réplica.
  • Consultas como DELETE ... WHERE field < 50000000 causam atraso de replicação com base em linha, já que um grande número de atualizações é acumulado na réplica.

Algumas soluções possíveis incluem:
De repente, o atraso de replicação aumenta. Isso é causado por transações de longa duração. Quando uma transação (instrução única ou várias instruções) é confirmada na instância de origem, o horário de início da transação é gravado no registro binário. Quando a réplica recebe esse evento do binlog, ela compara esse carimbo de data/hora com aquele atual para calcular o atraso da replicação. Dessa forma, uma transação de longa duração na origem resultaria em um grande atraso de replicação imediato na réplica. Se a quantidade de mudanças de linhas na transação for grande, a réplica também levará muito tempo para executá-la. Durante esse período, o atraso da replicação está aumentando. Quando a réplica termina essa transação, o período de recuperação depende da carga de trabalho de gravação na origem e da velocidade de processamento da réplica.

Para evitar uma transação longa, veja algumas soluções possíveis:

  • Dividir a transação em várias transações pequenas
  • Divida uma única consulta de gravação grande em lotes menores
  • Tente separar consultas de SELECT longas de uma transação combinada com DMLs.
Alterar sinalizações paralelas de replicação resulta em um erro. Um valor incorreto é definido para uma ou mais dessas sinalizações.

Na instância principal exibindo a mensagem de erro, defina as sinalizações de replicação paralela:

  1. Modifique as sinalizações binlog_transaction_dependency_tracking e transaction_write_set_extraction:
    • binlog_transaction_dependency_tracking=COMMIT_ORDER
    • transaction_write_set_extraction=OFF
  2. Adicione a sinalização slave_pending_jobs_size_max:

    slave_pending_jobs_size_max=33554432

  3. Modifique a sinalização transaction_write_set_extraction:

    transaction_write_set_extraction=XXHASH64

  4. Modifique a sinalização binlog_transaction_dependency_tracking:

    binlog_transaction_dependency_tracking=WRITESET
A criação da réplica falha com o tempo limite. Transações não confirmadas de longa duração na instância primária podem causar falha na criação da réplica de leitura.

Recrie a réplica depois de interromper todas as consultas em execução.

A seguir