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.
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étrica | Descrição |
|---|---|
| Atraso da replicação ( cloudsql.googleapis.com) |
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 |
| Número do último erro da linha de execução de E/S ( cloudsql.googleapis.com) |
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 |
| Número do último erro de linha de execução SQL ( cloudsql.googleapis.com) |
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 |
| Atraso da rede ( cloudsql.googleapis.com) |
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 |
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:
| Campo | Descriçã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.