Atraso da replicação

Esta página descreve como resolver problemas e corrigir o atraso na replicação de réplicas de leitura do Cloud SQL.

Vista geral

O atraso na replicação pode ocorrer em alguns cenários, como:

• A instância principal não consegue enviar as alterações com rapidez suficiente para a réplica.
• A réplica não consegue receber as alterações com rapidez suficiente.
• A réplica não consegue aplicar as alterações com rapidez 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 pelo qual a réplica não consegue aplicar as alterações de replicação com rapidez suficiente. Estas métricas são descritas na secção Monitorize o atraso da replicação abaixo.

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

Temos duas formas de fazer com que uma réplica do MySQL aplique as alterações mais rapidamente. Os utilizadores podem configurar as respetivas réplicas com as seguintes opções:

• Replicação paralela
• Limpeza de alto desempenho

Replicação paralela

A replicação paralela pode ajudar a reduzir o atraso de replicação configurando a réplica para usar vários threads que atuam em paralelo para aplicar alterações na réplica. Para ver informações sobre a utilização da replicação paralela, consulte o artigo Configurar a replicação paralela.

Descarga de alto desempenho

Por predefinição, o Cloud SQL para MySQL descarrega os registos de repetição para o disco após cada transação. A descarga de alto desempenho reduz a frequência com que os registos de refazer são descarregados para o disco para uma vez por segundo, o que melhora o desempenho de escrita.

Defina o sinalizador innodb_flush_log_at_trx_commit na réplica de leitura como 2. Também tem de definir a flag sync_binlog para um valor superior para que a flag innodb_flush_log_at_trx_commit seja eficaz.

Consulte o artigo Sugestões para trabalhar com flags para mais informações acerca desta flag.

Quando a flag innodb_flush_log_at_trx_commit está definida na réplica de leitura e o Cloud SQL deteta que pode ter ocorrido uma falha, o Cloud SQL recria automaticamente a réplica.

Otimize as consultas e o esquema

Esta secção sugere algumas otimizações comuns de consultas e esquemas que pode fazer 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ções REPEATABLE READ e SERIALIZABLE adquirem bloqueios que podem bloquear as alterações de replicação. Considere reduzir o nível de isolamento das suas consultas na réplica. O nível de isolamento de transações READ COMMITTED pode ter um melhor desempenho.

Transações de longa duração na base de dados principal

Se um grande número de linhas for atualizado numa única transação, pode causar um aumento súbito no número de alterações que têm de ser aplicadas à instância principal e, em seguida, enviadas para a réplica. Isto aplica-se a atualizações ou eliminações de declarações únicas que afetam muitas linhas de uma só vez. As alterações são enviadas para a réplica após serem confirmadas. A aplicação de um aumento súbito de alterações na réplica pode aumentar a possibilidade de contenção de bloqueios na réplica se a carga de consultas na réplica também for elevada, o que leva a um atraso na replicação.

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

Chaves principais em falta

As réplicas de leitura do Cloud SQL usam a replicação baseada em linhas, que tem um desempenho fraco se as tabelas do MySQL replicadas não tiverem chaves primárias. Recomendamos que todas as tabelas replicadas tenham chaves primárias.

Para o MySQL 8 ou posterior, recomendamos que defina a flag sql_require_primary_key como ON para exigir que as tabelas na sua base de dados tenham chaves primárias.

Bloqueios exclusivos devido a DDL

Os comandos de linguagem de definição de dados (LDD), como ALTER TABLE e CREATE INDEX, podem causar um intervalo de tempo de replicação na réplica devido a bloqueios exclusivos. Para evitar a contenção de bloqueios, considere agendar a execução de DDL durante períodos em que a carga de consultas seja inferior nas réplicas.

Réplica sobrecarregada

Se uma réplica de leitura estiver a receber demasiadas consultas, a replicação pode ser bloqueada. Considere dividir as leituras entre várias réplicas para reduzir a carga em cada uma.

Para evitar picos de consultas, pondere limitar as consultas de leitura de réplicas na lógica da aplicação ou numa camada de proxy, se usar uma.

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

Base de dados principal monolítica

Pondere dividir a base de dados principal verticalmente (ou horizontalmente) para evitar que uma ou mais tabelas com atraso impeçam o processamento de todas as outras tabelas.

Monitorize o atraso da replicação

Pode usar as métricas replica_lag e network_lag para monitorizar o atraso na replicação e identificar se a causa do atraso está na base de dados principal, na rede ou na réplica.

Valide a replicação

Para verificar se a replicação está a funcionar, execute a seguinte declaraçã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 a ocorrer, a primeira coluna, Slave_IO_State, mostra 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 a ocorrer, a coluna Slave_IO_State mostra o estado Connecting to master e a coluna Last_IO_Error mostra o estado error connecting to master cloudsqlreplica@x.x.x.x:3306.

De acordo com a documentação do MySQL, existem mais alguns campos interessantes relacionados com o atraso na replicação, incluindo os seguintes:

No exemplo anterior, Relay_Master_Log_File tem o valor mysql-bin.199898. Master_Log_File tem o valor mysql-bin.199927. O sufixo numérico 199898 é inferior a 199927. Isto significa que, embora a réplica tenha recebido um ficheiro de registo mysql-bin.199927 mais recente, continua a aplicar o mysql-bin.199898 mais antigo.

Neste caso, a thread SQL está atrasada na réplica.

Também pode estabelecer ligação à base de dados principal e executar:

  SHOW MASTER STATUS;

Este comando mostra-lhe em que ficheiro binlog está a ser feita a escrita na base de dados principal.

Se o ficheiro de registo binário da base de dados principal for mais recente do que o Master_Log_File na réplica, significa que o processo de E/S está atrasado. A réplica continua a ler um ficheiro de registo binário mais antigo da base de dados principal.

Quando o segmento de E/S está atrasado, a métrica network_lag também é elevada. Quando o processo SQL está atrasado, mas o processo de E/S não está, a métrica network_lag não é tão elevada, mas a métrica replica_lag é elevada.

Os comandos anteriores permitem-lhe observar os detalhes do atraso enquanto este está a ocorrer, mas as métricas network_lag e replica_lag oferecem-lhe uma forma de analisar as ocorrências passadas do atraso.

Recrie a réplica com atraso

Recrie uma réplica com atraso quando a replicação ficar atrás de um período aceitável.

Com o Cloud SQL, pode configurar a réplica de leitura para se recriar se a replicação ficar atrasada durante um período inaceitável e esse atraso persistir durante, pelo menos, cinco minutos.

Se definir um atraso de replicação aceitável como inferior a 360 segundos (seis minutos) e um atraso de replicação de, pelo menos, 361 segundos persistir durante mais de cinco minutos, após cinco minutos, a instância principal cria um novo instantâneo de si própria e a réplica de leitura é recriada com este instantâneo.

A recriação de uma réplica de leitura com atraso oferece as seguintes vantagens:

• Controla o que é considerado um intervalo aceitável para o atraso na replicação.
• Pode reduzir o tempo gasto na resolução de problemas de atraso na replicação em horas ou até dias.

Aplicam-se detalhes de funcionalidades adicionais:

• Compatível com as seguintes versões:
  • MySQL 5.7
  • MySQL 8.0
  • MySQL 8.4
• Tem de ser definido um intervalo aceitável para o atraso ou o tempo de espera da replicação em segundos.
• O valor mínimo aceitável é de 300 segundos ou cinco minutos.
• O valor máximo aceitável é de 31 536 000 segundos ou 1 ano.
  • Se ativar a opção Recreate lagging replica para uma instância, mas não definir o atraso de replicação máximo aceitável, o Cloud SQL usa o valor predefinido de um ano.
• Tipos de instâncias suportadas:
  • Ler réplica
  • Réplica de leitura entre regiões
  • Réplica em cascata
• O valor definido para o campo replicationLagMaxSeconds é específico de cada instância de réplica. Se uma instância principal tiver várias instâncias de réplica, pode definir cada réplica com um valor diferente.
• Quando uma réplica é recriada, os utilizadores podem esperar alguma indisponibilidade enquanto as seguintes operações são concluídas:
  • A replicação foi interrompida.
  • A réplica é eliminada.
  • É criado um instantâneo da instância principal.
  • A réplica é recriada a partir deste instantâneo mais recente. A nova réplica usa o mesmo nome e endereço IP que a réplica anterior. Como resultado, o MySQL tem de ser parado e reiniciado.
  • A nova réplica começa a replicar dados.
• O campo replicationLagMaxSeconds é um campo ao nível da instância. Cada instância tem o seu próprio valor.

• Se tiver várias réplicas de leitura para a mesma instância principal, pode definir um valor único para o campo replicationLagMaxSeconds para cada réplica.

  A definição de diferentes limites de tempo para diferentes réplicas pode ajudar a evitar um cenário em que todas as réplicas ficam inativas ao mesmo tempo.

Ative a opção Recriar réplica com atraso

A funcionalidade de recriação de réplica com atraso está desativada por predefinição. Para o ativar quando criar uma instância, use um dos seguintes métodos:

gcloud beta sql instances create REPLICA_INSTANCE_NAME \
  --master-instance-name=PRIMARY_INSTANCE_NAME \
  --database-version=DATABASE_VERSION \
  --tier=TIER \
  --edition=EDITION \
  --region=REGION \
  --root-password=PASSWORD \
  --replication-lag-max-seconds-for-recreate=REPLICATION_LAG_MAX_SECONDS

{
  "settings": {
  "replicationLagMaxSeconds" :REPLICATION_LAG_MAX_SECONDS,
  }
  ...
}

Atualize o período de recriação para o atraso na replicação

Para ver as definições de uma instância, use qualquer um dos métodos descritos no artigo Ver informações de resumo da instância.

Com estas informações, pode optar por atualizar ou não o período de tempo de atraso de replicação que especificou como aceitável antes de a réplica ser recriada.

gcloud beta sql instances patch INSTANCE_NAME \
  --replication-lag-max-seconds-for-recreate=REPLICATION_LAG_MAX_SECONDS

Limitações

Aplicam-se as seguintes limitações à recriação de réplicas com atraso:

• Os valores de replicationLagMaxSeconds só podem ser definidos em segundos.
• Os índices criados na réplica de leitura antes de uma operação de recriação não são mantidos. Se existir um índice, crie um índice secundário após a réplica ser recriada.
• Para evitar tempos de inatividade frequentes em réplicas de leitura, as recriações estão limitadas a uma por dia por instância.
• As réplicas de servidores externos não são suportadas com esta funcionalidade.
• Se ativar a recriação de réplicas com atraso numa réplica em cascata, o Cloud SQL recria primeiro as réplicas finais para manter a consistência da replicação.
• A recriação de uma réplica entre regiões incorre em custos adicionais.
• Não é possível ativar a recriação de réplicas com atraso na Trusted Cloud consola.

O que se segue:

• Promova réplicas para migração regional ou recuperação de desastres