ApsaraDB RDS:O que fazer se minha instância somente leitura do ApsaraDB RDS for MySQL apresentar latência na sincronização de dados com a instância primária?

Por que uma latência de 1 segundo costuma ser uma leitura falsa

O ApsaraDB RDS arredonda todos os pontos de amostragem para baixo, até o segundo mais próximo. Quando uma transação atravessa o limite de um segundo, o cálculo da latência resulta em 1 segundo, mesmo que o atraso real seja apenas uma fração de segundo.

Exemplo:

Se o intervalo de monitoramento estiver definido para 3 horas ou mais, a granularidade padrão pode chegar a 30 segundos. Para obter granularidade de 1 segundo, acesse a aba Performance Trends no console do ApsaraDB RDS e defina o intervalo de tempo para menos de 6 minutos. Para mais detalhes, consulte Usar o recurso de painel para uma instância do ApsaraDB RDS for MySQL.

Padrão 1: Instância somente leitura sob pressão de recursos

A instância somente leitura usa uma thread de I/O e uma thread SQL para replicar dados. Ambas competem por recursos de I/O. Se as operações de entrada e saída por segundo (IOPS) da instância já estiverem altas devido a consultas de leitura, a replicação sofre atrasos.

Como confirmar: Na página Monitoring and Alerting da instância somente leitura no console do ApsaraDB RDS, verifique a utilização de CPU, o uso de memória, a largura de banda de I/O e a contagem de conexões para identificar gargalos de recursos. Compare o tipo da instância com a primária: se a instância somente leitura tiver especificações menores, essa é provavelmente a causa. Consulte Tipos de instância para instâncias somente leitura padrão do ApsaraDB RDS for MySQL e Tipos de instância para instâncias somente leitura YiTian do ApsaraDB RDS for MySQL.

Padrão 2: Alta taxa de gravação na instância primária

A instância somente leitura utiliza uma única thread para aplicar transações. Se a primária processar gravações multithread simultâneas com alta taxa de transações por segundo (TPS), o aplicador single-thread não consegue acompanhar.

Como confirmar: Visualize o TPS na página Dashboard da instância. Para mais detalhes, consulte Usar o recurso de painel para uma instância do ApsaraDB RDS for MySQL.

Padrão 3: Execução de transação grande

Quando Seconds_Behind_Master aumenta continuamente enquanto Exec_Master_Log_Pos permanece estagnado, a thread SQL aplica uma transação grande ou uma operação de linguagem de definição de dados (DDL). Operações como UPDATE, DELETE, INSERT...SELECT e REPLACE...SELECT em tabelas grandes geram volume substancial de dados de binary log. A instância somente leitura leva o mesmo tempo para concluir a transação que a primária. Por exemplo, uma exclusão de 80 segundos na primária resulta em uma exclusão de 80 segundos na instância somente leitura.

Apenas uma thread pode replicar transações para uma determinada tabela por vez, mesmo durante a replicação simultânea de várias tabelas.

Como confirmar:

1. Execute SHOW SLAVE STATUS \G e verifique se Seconds_Behind_Master aumenta enquanto Exec_Master_Log_Pos permanece inalterado.

2. Execute SHOW PROCESSLIST; para identificar a thread específica causadora do atraso.

3. Se o formato de binary logging for ROW, execute SHOW BINARY LOGS; e verifique File_size. Se File_size exceder max_binlog_size, há transações grandes presentes.

Padrão 4: Operação DDL bloqueando a replicação

Como confirmar:

1. Verifique se os arquivos de binary log crescem sem truncamento. Isso indica uma operação DDL em andamento.

2. Execute SHOW PROCESSLIST; e verifique se o status da thread SQL mostra waiting for table metadata lock. Em caso afirmativo, uma consulta ou transação aberta na instância somente leitura bloqueia a instrução DDL replicada da primária.

3. Execute SHOW ENGINE INNODB STATUS \G ou SHOW OPEN TABLES; e procure tabelas com in_use = 1. Essas tabelas sofrem modificação sem chave primária, o que força a replicação linha a linha.

4. Verifique nos logs de consultas lentas se há operações DDL como OPTIMIZE, ALTER, REPAIR e CREATE. Consulte Análise de log de consultas lentas.

Instruções DDL comuns que causam latência prolongada: CREATE INDEX, REPAIR TABLE, ALTER TABLE ADD COLUMN.

Padrão 5: Tabela sem chave primária

Tabelas com apenas um índice único contendo valor NULL e sem chave primária fazem a replicação usar o plano de execução do índice único em vez do plano do otimizador, mesmo com cláusula WHERE especificada.

Como confirmar: Use a view sys.schema_index_statistics para verificar se a tabela não tem chaves primárias e possui apenas um índice único. Verifique também se o índice único contém valor NULL.

Correção para o padrão 1: Atualizar o tipo da instância

Atualize a instância somente leitura para um tipo que corresponda ou supere a instância primária. Isso evita que a contenção de recursos cause atraso na replicação. Consulte Alterar as especificações de uma instância do ApsaraDB RDS for MySQL.

Correção para o padrão 2: Reduzir a pressão de gravação na primária

Se o TPS da primária permanecer consistentemente alto, divida grandes operações de gravação em lotes menores para reduzir a carga de replicação na instância somente leitura.

Correção para o padrão 3: Dividir transações grandes

Divida transações grandes em transações menores. Para operações DELETE, adicione uma cláusula WHERE para limitar o número de linhas excluídas por lote. Isso permite que a instância somente leitura processe cada transação menor rapidamente, sem acumular latência.

Correção para o padrão 4: Resolver latência relacionada a DDL

Se operações DDL causarem latência:

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

• Ative a expansão automática de armazenamento ou defina o limiar de expansão manual para 90% a fim de evitar esgotamento do armazenamento durante o DDL. Consulte Como dimensionar uma instância do ApsaraDB RDS?

• Use o SQL Explorer para auditar regularmente instruções SQL de execução lenta. Consulte Usar o recurso SQL Explorer e Audit em uma instância do ApsaraDB RDS for MySQL.

• Configure um alerta de uso de disco, configure a expansão automática de armazenamento ou atualize manualmente o tipo da instância.

Se um bloqueio de metadados impedir a replicação:

1. Execute SHOW PROCESSLIST; na instância somente leitura e confirme se o status da thread SQL é waiting for table metadata lock.

2. Encerre a sessão bloqueante para retomar a replicação. Consulte Usar o DMS para liberar bloqueios de metadados.

Correção para o padrão 5: Adicionar uma chave primária

Adicione uma chave primária explícita a qualquer tabela que não possua uma. Isso permite que a replicação use buscas de índice eficientes em vez de varreduras completas de tabela.