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, a primeira coluna, Slave_IO_State, vai 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 incluem:
| 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 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 é 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.
Recriar réplica atrasada
Recrie uma réplica atrasada quando a replicação ficar abaixo de um período aceitável.
Com o Cloud SQL, é possível configurar a réplica de leitura para se recriar se a replicação ficar atrasada (ou for adiada) por um período de tempo inaceitável e esse atraso persistir por pelo menos cinco minutos.
Se você definir um atraso de replicação aceitável como sendo inferior a 360 segundos (seis minutos) e um atraso de replicação de pelo menos 361 segundos persistir por mais de cinco minutos, após cinco minutos, a instância principal vai criar um novo snapshot dela mesma, e a réplica de leitura será recriada usando esse snapshot.
Recriar uma réplica de leitura atrasada oferece os seguintes benefícios:
- Você controla o que é considerado um intervalo aceitável para o atraso de replicação.
- É possível reduzir o tempo gasto na solução de problemas de atraso de replicação em horas ou até dias.
Outros detalhes do recurso:
- Compatível com as seguintes versões:
- MySQL 5.7
- MySQL 8.0
- MySQL 8.4
- Um intervalo aceitável para atraso ou demora na replicação precisa ser definido 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 um ano.
- Se você ativar a recriação de réplica atrasada para uma instância, mas não definir o atraso máximo aceitável de replicação, o Cloud SQL usará o valor padrão de um ano.
- Tipos de instâncias compatíveis:
- Réplica de leitura
- 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, você poderá definir cada uma com um valor diferente. - Quando uma réplica é recriada, os usuários podem esperar um tempo de inatividade enquanto as seguintes
operações são concluídas:
- A replicação é interrompida.
- A réplica é excluída.
- Um snapshot da instância principal é criado.
- A réplica é recriada com base nesse snapshot mais recente. A nova réplica usa o mesmo nome e endereço IP da anterior. Como resultado, o MySQL precisa ser interrompido e reiniciado.
- A nova réplica começa a replicar dados.
- O
replicationLagMaxSecondsé um campo no nível da instância. Cada instância tem um valor próprio. Se você tiver várias réplicas de leitura para a mesma instância principal, poderá definir um valor exclusivo para o campo
replicationLagMaxSecondsem cada réplica.Definir diferentes limites de tempo para diferentes réplicas pode ajudar a evitar um cenário em que todas as réplicas fiquem inativas ao mesmo tempo.
Ativar a recriação de réplica atrasada
O recurso de recriação de réplica atrasada fica desativado por padrão. Para ativar esse recurso ao criar uma instância, use um dos seguintes métodos:
gcloud
Use o comando gcloud sql instances create para criar uma nova instância de réplica de leitura com a flag
--replication-lag-max-seconds-for-recreate:
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
Em que:
REPLICA_INSTANCE_NAMEé o nome da instância de réplica.PRIMARY_INSTANCE_NAMEé o nome da instância principal.DATABASE_VERSIONé a versão do banco de dados da instância. Por exemplo,MYSQL_8_0_31.TIERé o tipo de máquina que você quer usar para a instância de réplica. Por exemplo,db-perf-optimized-N-4. Para mais informações, consulte Configurações de instância personalizadas.EDITIONé a edição que você quer usar para a instância de réplica. Por exemplo,ENTERPRISE_PLUS. Para mais informações, consulte Criar uma instância.REGIONé a região que você quer usar para a instância de réplica. Por exemplo,us-central1.PASSWORDé a senha de root da instância.REPLICATION_LAG_MAX_SECONDSé o atraso ou a defasagem máxima aceitável da replicação em segundos. Por exemplo,600. O valor mínimo aceitável é de 300 segundos ou cinco minutos. O valor máximo aceitável é de 31.536.000 segundos ou um ano.
API REST
O campo replicationLagMaxSeconds está localizado no recurso DatabaseInstance. Adicione este campo ao corpo da solicitação:
{ "settings": { "replicationLagMaxSeconds" :REPLICATION_LAG_MAX_SECONDS, } ... }
Em que:
REPLICATION_LAG_MAX_SECONDSé o atraso ou a defasagem máxima aceitável de replicação em segundos. Por exemplo,600.
Atualizar o período de recriação do atraso de replicação
Para conferir as configurações de uma instância, use qualquer um dos métodos descritos em Ver informações resumidas da instância.
Com essas informações, você pode escolher se quer ou não atualizar o período de atraso de replicação especificado como aceitável antes da recriação da réplica.
gcloud
Use o comando gcloud sql instances patch
para atualizar o período de recriação da instância com base no
atraso de replicação:
gcloud beta sql instances patch INSTANCE_NAME \ --replication-lag-max-seconds-for-recreate=REPLICATION_LAG_MAX_SECONDS
Em que:
INSTANCE_NAMEé o nome da instância;REPLICATION_LAG_MAX_SECONDSé o atraso ou a defasagem máxima aceitável da replicação em segundos. Por exemplo,700. Se você quiser reverter para o valor padrão de um ano, insira31536000. O valor mínimo aceitável é de 300 segundos ou cinco minutos. O valor máximo aceitável é de 31.536.000 segundos ou um ano.
API REST
A política pode ser atualizada usando instances.patch
e instance.insert.
Para ver um exemplo de como atualizar a configuração usando a API REST, consulte Editar uma instância.
Limitações
As seguintes limitações se aplicam à recriação de réplicas atrasadas:
- Os valores de
replicationLagMaxSecondssó 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 um índice existir, crie um índice secundário depois que a réplica for recriada.
- Para evitar tempos de inatividade frequentes nas réplicas de leitura, as recriações são limitadas a uma por dia por instância.
- Réplicas de servidores externos não são compatíveis com esse recurso.
- Se você ativar a recriação de réplicas atrasadas em uma réplica em cascata, o Cloud SQL vai recriar primeiro as réplicas de folha para manter a consistência da replicação.
- A recriação de uma réplica entre regiões gera um custo adicional.
- Não é possível ativar a recriação de réplicas atrasadas no console Google Cloud .