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 da instância somente leitura insuficientes

O que acontece. A replicação utiliza uma thread de I/O (para buscar binary logs na primária) e uma thread SQL (para aplicá-los localmente). Ambas as threads 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. Visualize também o tipo da instância na seção Configuration Information da página Basic Information. Para mais informações, consulte Instance types for read-only ApsaraDB RDS for MySQL instances (x86) e Instance types for read-only ApsaraDB RDS for MySQL instances (ARM).

Como corrigir. Atualize a instância somente leitura para especificações iguais ou superiores às da instância primária. Para mais informações, consulte Change the specifications of an ApsaraDB RDS for MySQL instance.

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 Use the dashboard feature for an ApsaraDB RDS for MySQL instance.

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 nos binary logs. A instância somente leitura precisa gastar o mesmo tempo aplicando a transação que a primária gastou executando-a. 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 formato do binary log estiver definido como ROW, verifique se algum arquivo de binary log 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 metadata lock (MDL) examinando a saída de SHOW SLAVE STATUS \G em busca de estados de espera por locks.

Como corrigir. Divida transações grandes em lotes menores. Por exemplo, adicione uma cláusula WHERE com limite de linhas aos comandos 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 comandos de Data Definition Language (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. Queries lentas que geram um grande número de tabelas temporárias agravam o problema ao consumir I/O de disco.

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

Como confirmar.

• Verifique se os arquivos de binary log estão 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 locks:

  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 estar impedindo a replicação.

• Revise os logs de queries lentas em busca de operações relacionadas a DDL, como OPTIMIZE, ALTER, REPAIR e CREATE. Para mais informações, consulte Slow query log analysis.

Como corrigir.

• Agende operações DDL fora dos horários de pico.

• Ative o recurso de expansão automática de armazenamento ou defina o limiar para expansão manual em 90%. Para mais informações, consulte How do I scale an ApsaraDB RDS instance?

• Ative o SQL Explorer para monitorar regularmente o desempenho de SQL. Para mais informações, consulte Use the SQL Explorer and Audit feature on an ApsaraDB RDS for MySQL instance.

• Configure alertas de uso de disco, configure automatic storage expansion ou atualize as especificações da instância. Para mais informações, consulte Change the specifications of an ApsaraDB RDS for MySQL instance.

Se um comando DDL da primária estiver bloqueado por um metadata lock na instância somente leitura:

1. Execute SHOW PROCESSLIST; na instância somente leitura para encontrar a thread SQL aguardando um metadata lock.

2. Encerre a sessão que detém o lock para retomar a replicação. Para mais informações, consulte Use DMS to release metadata locks.

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 query 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 query, 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.