Atraso da replicação

Nesta página, descrevemos como resolver problemas e corrigir atrasos de replicação para réplicas de leitura do Cloud SQL.

Visão geral

As réplicas de leitura do Cloud SQL usam a replicação baseada em linha do MySQL usando identificadores globais de transação (GTIDs, na sigla em inglês). As alterações são gravadas no registro binário da instância principal e enviadas à réplica, onde são recebidas e aplicadas ao banco de dados.

O atraso da replicação pode acontecer em alguns cenários, como:

  • A instância principal não pode enviar as alterações com rapidez suficiente para a réplica.
  • A réplica não recebe as alterações com rapidez suficiente.
  • A réplica não pode aplicar as alterações com rapidez suficiente.
Use a métrica network_lag para monitorar os dois primeiros cenários em que a instância principal não pode enviar alterações com rapidez suficiente ou a réplica não pode receber alterações rápido o suficiente.

O atraso total é observado com a métrica replica_lag. A diferença entre replica_lag e network_lag pode indicar o terceiro motivo quando a réplica não pode aplicar as alterações de replicação com rapidez suficiente. Essas métricas são descritas na seção Monitorar atraso da replicação abaixo.

Configuração de réplica mais rápida

Há duas maneiras de fazer uma réplica do MySQL aplicar alterações com mais rapidez. Os usuários podem configurar as réplicas com as seguintes opções:

  • Replicação paralela
  • Limpeza de alto desempenho

Replicação paralela

A replicação paralela pode ajudar o atraso de replicação configurando a réplica para usar várias linhas de execução em paralelo para aplicar alterações na réplica. Para mais informações sobre como usar a replicação paralela, consulte Como configurar a replicação paralela.

Limpeza de alto desempenho

Por padrão, o Cloud SQL para MySQL limpa os registros de refazer no disco após cada transação. A limpeza de alto desempenho reduz a frequência com que os registros de refazer são apagados para o disco uma vez por segundo, o que melhora o desempenho de gravação.

Defina a sinalização innodb_flush_log_at_trx_commit na réplica de leitura como 2. Também é necessário definir a sinalização sync_binlog como um valor mais alto para que a sinalização innodb_flush_log_at_trx_commit funcione.

Para mais informações sobre esta sinalização, consulte Dicas para trabalhar com sinalizações.

Quando a sinalização innodb_flush_log_at_trx_commit é definida na réplica de leitura e o Cloud SQL detecta que pode ter ocorrido uma falha, o Cloud SQL recria automaticamente a réplica.

Otimizar consultas e esquema

Nesta seção, sugerimos algumas otimizações comuns de consulta e esquema que podem ser feitas para melhorar o desempenho da replicação.

Nível de isolamento da consulta na réplica de leitura

Os níveis de isolamento de transação REPEATABLE READ e SERIALIZABLE adquirem bloqueios que possam bloquear as mudanças de replicação. Considere reduzir o nível de isolamento das consultas na réplica. O nível de isolamento da transação READ COMMITTED pode ter um desempenho melhor.

Transações de longa duração no banco de dados principal

Se um grande número de linhas for atualizado em uma única transação, isso poderá causar um pico repentino no número de alterações que precisam ser aplicadas à instância principal e enviadas para a réplica. Isso se aplica a atualizações ou exclusões de instruções únicas que afetam muitas linhas de uma vez. As alterações são enviadas à réplica depois de serem confirmadas. Aplicar um pico repentino de alterações na réplica pode aumentar a possibilidade de contenção de bloqueio na réplica se a carga de consulta na réplica também for alta, levando a atraso na replicação.

Considere dividir transações grandes em várias transações menores.

Chaves primárias ausentes

As réplicas de leitura do Cloud SQL usam a replicação baseada em linha, que tem um desempenho insatisfatório se as tabelas MySQL replicadas não têm chaves primárias. Recomendamos que todas as tabelas replicadas tenham chaves primárias.

Para o MySQL 8 ou versões posteriores, recomendamos que você defina a sinalização sql_require_primary_key como ON para exigir que as tabelas no seu banco de dados tenham chaves primárias.

Bloqueios exclusivos devido a DDL

Os comandos da linguagem de definição de dados (DDL), como ALTER TABLE e CREATE INDEX, podem causar atraso de replicação na réplica devido a bloqueios exclusivos. Para evitar a contenção de bloqueio, programe a execução do DDL quando a carga da consulta for menor nas réplicas.

Réplica sobrecarregada

Se uma réplica de leitura estiver recebendo muitas consultas, a replicação poderá ser bloqueada. Divida as leituras entre várias réplicas para reduzir a carga em cada uma.

Para evitar picos de consulta, limite as consultas de leitura de réplica na lógica do aplicativo ou em uma camada de proxy, se usar uma.

Se houver picos de atividade na instância principal, considere distribuir as atualizações.

Banco de dados primário monolítico

Considere fragmentar o banco de dados primário verticalmente (ou horizontalmente) para impedir que uma ou mais tabelas atrasadas retenham todas as outras tabelas.

Monitorar atraso de replicação

Use as métricas replica_lag e network_lag para monitorar a atraso da replicação e identificar se a causa do atraso está no banco de dados principal, na rede ou na réplica.

MétricaDescrição
Atraso da replicação
(cloudsql.googleapis.com/database/replication/replica_lag)

O número de segundos em que o estado da réplica está atrasado em relação ao estado da instância principal. Essa é a diferença entre o horário atual e o carimbo de data/hora original em que o banco de dados primário confirmou a transação que está sendo aplicada na réplica. Em particular, as gravações podem ser contadas com atraso, mesmo que tenham sido recebidas pela réplica, se a réplica ainda não tiver aplicado a gravação ao banco de dados.

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

Número do último erro da linha de execução de E/S
(cloudsql.googleapis.com/database/mysql/replication/last_io_errno)

Indica o último erro que causou a falha da linha de execução de E/S. Se ele for diferente de zero, a replicação estará corrompida. Isso é raro, mas pode acontecer. Verifique a documentação do MySQL para entender o que o código do erro indica. Por exemplo, os arquivos binlog na instância principal podem ter sido excluídos antes de serem recebidos pela réplica. O Cloud SQL geralmente recria automaticamente a réplica se a replicação estiver corrompida. Esta métrica last_io_errno pode explicar o motivo.

Número do último erro de linha de execução SQL
(cloudsql.googleapis.com/database/mysql/replication/last_sql_errno)

Indica o último erro que causou a falha da linha de execução SQL. Se ele for diferente de zero, a replicação estará corrompida. Isso é raro, mas pode acontecer. Verifique a documentação do MySQL para entender o que o código do erro indica. Normalmente, o Cloud SQL recriará automaticamente a réplica se a replicação estiver corrompida. Esta métrica last_sql_errno pode explicar o motivo.

Atraso 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 a network_lag for zero ou insignificante, mas a replica_lag for alta, isso indica que a linha de execução SQL não pode aplicar mudanças de replicação com rapidez suficiente.

Verificar a replicação

Para verificar se a replicação está funcionando, execute a seguinte instrução na réplica:

mysql> SHOW SLAVE STATUS\G;
*************************** 1. row ***************************
               Slave_IO_State: Queueing master event to the relay log
                  Master_Host: xx.xxx.xxx.xxx
                  Master_User: cloudsqlreplica
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.199927
          Read_Master_Log_Pos: 83711956
               Relay_Log_File: relay-log.000025
                Relay_Log_Pos: 24214376
        Relay_Master_Log_File: mysql-bin.199898
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 24214163
              Relay_Log_Space: 3128686571
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: Yes
           Master_SSL_CA_File: master_server_ca.pem
           Master_SSL_CA_Path: /mysql/datadir
              Master_SSL_Cert: replica_cert.pem
            Master_SSL_Cipher:
               Master_SSL_Key: replica_pkey.pem
        Seconds_Behind_Master: 2627
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 321071839
                  Master_UUID: 437d04e9-8456-11e8-b13d-42010a80027b
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: System lock
           Master_Retry_Count: 86400
                  Master_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp:
               Master_SSL_Crl:
           Master_SSL_Crlpath:
           Retrieved_Gtid_Set: 437d04e9-8456-11e8-b13d-42010a80027b:52111095710-52120776390
            Executed_Gtid_Set: 437d04e9-8456-11e8-b13d-42010a80027b:1-52113039508
                Auto_Position: 1
         Replicate_Rewrite_DB:
                 Channel_Name:
           Master_TLS_Version:
1 row in set (0.00 sec)

Se a replicação estiver acontecendo, o Slave_IO_State (primeira coluna) mostrará Waiting for master to send event ou uma mensagem semelhante. Além disso, o campo Last_IO_Error está vazio.

Se a replicação não estiver acontecendo, a coluna Slave_IO_State mostrará o status Connecting to master e a coluna Last_IO_Error mostrará o status error connecting to master cloudsqlreplica@x.x.x.x:3306.

De acordo com a documentação do MySQL (em inglês), alguns outros campos interessantes relacionados ao atraso de replicação são:

CampoDescrição
Master_Log_File
O nome do arquivo de registros binários de origem que a linha de execução de E/S está lendo no momento.
Read_Master_Log_Pos
A posição no arquivo de registros binário de origem atual que a linha de execução de E/S leu.
Relay_Log_File
O nome do arquivo de registros de redirecionamento que a linha de execução SQL lê e executa no momento.
Relay_Log_Pos
A posição no arquivo de registros de redirecionamento atual que a linha de execução SQL lê e executa até o momento.
Relay_Master_Log_File
O nome do arquivo de registros binários de origem que contém o evento mais recente executado pela linha de execução SQL.

No exemplo acima, Relay_Master_Log_File tem o valor mysql-bin.199898. Master_Log_File tem o valor mysql-bin.199927. O sufixo numérico 199898 é menor que 199927. Isso significa que, mesmo que a réplica tenha recebido um arquivo de registro mysql-bin.199927 mais recente, ela ainda está aplicando a mysql-bin.199898 mais antiga.

Nesse caso, a linha de execução do SQL está atrasada na réplica.

Você também pode se conectar ao banco de dados primário e executar:

SHOW MASTER STATUS;

Este comando mostra qual arquivo binlog está sendo gravado no banco de dados principal.

Se o arquivo de registros binários do banco de dados principal for mais recente que o Master_Log_File na réplica, isso significa que a linha de execução de E/S está atrasada. A réplica ainda está lendo um arquivo de registro binário mais antigo do banco de dados principal.

Quando a linha de execução de E/S estiver atrasada, a métrica network_lag também será alta. Quando a linha de execução do SQL estiver atrasada, mas a linha de execução de E/S não, a métrica network_lag não será tão alta, mas a replica_lag será alta.

Os comandos anteriores permitem observar os detalhes do atraso enquanto o atraso está acontecendo, mas as métricas network_lag e replica_lag fornecem uma maneira de analisar as ocorrências anteriores do atraso.