ApsaraDB RDS:Causas e soluções para latência de sincronização em instâncias somente leitura do RDS for MySQL

SHOW SLAVE STATUS \G

Causa 1: Especificações insuficientes da instância somente leitura

O que acontece. A replicação utiliza uma thread de I/O (para buscar logs binários na primária) e uma thread SQL (para aplicá-los localmente). Ambas competem por recursos de I/O, incluindo operações de entrada e saída por segundo (IOPS). Se a instância somente leitura não conseguir sustentar os IOPS necessários, ela ficará atrasada.

Como confirmar. No console do ApsaraDB RDS, acesse Monitoring and Alerts da instância somente leitura. Verifique se a utilização de CPU, uso de memória, largura de banda de I/O ou IOPS estão atingindo consistentemente seus limites. Você também pode visualizar o tipo da instância na seção Configuration Information da página Basic Information. Para mais informações, consulte Tipos de instância para instâncias somente leitura do ApsaraDB RDS for MySQL (x86) e Tipos de instância para instâncias somente leitura do ApsaraDB RDS for MySQL (ARM).

Como corrigir. Faça upgrade da instância somente leitura para especificações iguais ou superiores às da instância primária. Para mais informações, consulte Alterar as especificações de uma instância do ApsaraDB RDS for MySQL.

Causa 2: Alto volume de transações por segundo (TPS) na instância primária

O que acontece. Uma única thread SQL aplica todas as transações replicadas na instância somente leitura de forma serial. Se a instância primária processar um alto volume de escritas simultâneas, a instância somente leitura não conseguirá acompanhar.

Como confirmar. Acesse a página Dashboard da instância primária ou somente leitura e verifique a métrica de TPS. Para mais informações, consulte Usar o recurso de painel para uma instância do ApsaraDB RDS for MySQL.

Como corrigir. Otimize ou divida grandes transações na instância primária para reduzir o volume de escrita por transação e diminuir o tempo que cada transação ocupa a thread SQL.

Causa 3: Transações grandes na instância primária

O que acontece. Operações como UPDATE, DELETE, INSERT...SELECT e REPLACE...SELECT em grandes volumes de dados geram entradas extensas de log binário. A instância somente leitura precisa gastar o mesmo tempo aplicando a transação que a primária gastou para executá-la. Por exemplo, uma exclusão que leva 80 segundos na primária também levará 80 segundos para ser replicada.

Além disso, embora haja suporte a transações concorrentes em múltiplas tabelas, apenas uma thread replica transações em uma determinada tabela por vez, o que pode agravar o atraso.

Como confirmar. Execute SHOW SLAVE STATUS \G na instância somente leitura e observe se Seconds_Behind_Master aumenta continuamente enquanto Exec_Master_Log_Pos permanece inalterado. Em seguida, execute SHOW PROCESSLIST para identificar a thread SQL específica. Se o log binário estiver configurado para o formato ROW, verifique se algum arquivo de log binário excede o limiar de max_binlog_size:

SHOW BINARY LOGS;

Se File_size exceder max_binlog_size, é provável que transações grandes sejam a causa.

Verifique também se há contenção de bloqueio de metadados (MDL) examinando a saída de SHOW SLAVE STATUS \G em busca de estados de espera por bloqueio.

Como corrigir. Divida transações grandes em lotes menores. Por exemplo, adicione uma cláusula WHERE com limite de linhas às instruções DELETE para que cada lote processe uma quantidade gerenciável de linhas, permitindo que a instância somente leitura acompanhe o ritmo.

Causa 4: DDL de longa duração na instância primária

O que acontece. A replicação aplica instruções de Linguagem de Definição de Dados (DDL) de forma serial. Uma operação DDL em uma tabela grande — como CREATE INDEX, ALTER TABLE ADD COLUMN ou REPAIR TABLE — pode bloquear toda a replicação subsequente até sua conclusão. Consultas lentas que geram muitas tabelas temporárias agravam o problema ao consumir I/O de disco.

Separadamente, consultas em andamento ou transações abertas na instância somente leitura podem criar contenção de MDL que bloqueia instruções DDL vindas da primária.

Como confirmar.

• Verifique se os arquivos de log binário estão se acumulando sem serem truncados, o que indica um backlog de DDL.

• Execute o seguinte comando na instância somente leitura para verificar se há contenção de bloqueios:

  SHOW ENGINE INNODB STATUS \G

• Execute o seguinte comando para identificar tabelas atualmente em uso:

  SHOW OPEN TABLES;

  Tabelas com in_use = 1 estão bloqueadas e podem impedir a replicação.

• Revise os logs de consultas lentas em busca de operações relacionadas a DDL, como OPTIMIZE, ALTER, REPAIR e CREATE. Para mais informações, consulte Análise de log de consultas lentas.

Como corrigir.

• Agende operações DDL para horários de baixa demanda.

• Ative o recurso de expansão automática de armazenamento ou defina o limiar para expansão manual de armazenamento em 90%. Para mais informações, consulte Como dimensionar uma instância do ApsaraDB RDS?

• Ative o SQL Explorer para monitorar regularmente o desempenho do SQL. Para mais informações, consulte Usar o recurso SQL Explorer e Audit em uma instância do ApsaraDB RDS for MySQL.

• Configure alertas de uso de disco ou faça upgrade das especificações da instância. Para mais informações, consulte Alterar as especificações de uma instância do ApsaraDB RDS for MySQL.

Se uma instrução DDL da primária estiver bloqueada por um bloqueio de metadados na instância somente leitura:

1. Execute SHOW PROCESSLIST; na instância somente leitura para encontrar a thread SQL aguardando um bloqueio de metadados.

2. Encerre a sessão que detém o bloqueio para retomar a replicação. Para mais informações, consulte Usar o DMS para liberar bloqueios de metadados.

Causa 5: Tabela com índice único, mas sem chave primária

O que acontece. Quando uma tabela não possui chave primária e tem apenas um índice único contendo valores NULL, a thread SQL de replicação usa o plano de execução do índice único em vez do plano preferido pelo otimizador — mesmo que uma cláusula WHERE permita uma busca mais eficiente. Isso força varreduras completas na tabela durante a replicação, aumenta significativamente as leituras lógicas e desacelera a thread SQL.

Como confirmar. Execute a seguinte consulta na instância primária para identificar tabelas sem chave primária:

SELECT tab.table_schema AS database_name, tab.table_name
FROM information_schema.tables tab
LEFT JOIN information_schema.table_constraints tco
  ON tab.table_schema = tco.table_schema
  AND tab.table_name = tco.table_name
  AND tco.constraint_type = 'PRIMARY KEY'
WHERE tco.constraint_type IS NULL
  AND tab.table_schema NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys')
  AND tab.table_type = 'BASE TABLE'
ORDER BY tab.table_schema, tab.table_name;

Para as tabelas retornadas pela consulta, use a view sys.schema_index_statistics para confirmar se o índice único contém valores NULL.

Como corrigir. Adicione uma chave primária explícita a qualquer tabela que não possua uma.