Diagnóstico de Indisponibilidade no Nó Primário

Em arquiteturas de alta disponibilidade, o orquestrador de failover assume a responsabilidade de redirecionar o tráfego de escrita para o secundário quando o nó principle deixa de responder. A eficácia desse mecanismo depende exclusivamente da precisão do algoritmo de detecção de falhas.

Ineficácia da Validação com Consultas Triviais

Executar uma instrução como SELECT 1 parece ser a verificação mais direta, porém o retorno bem-sucedido apenas comprova que o processo mysqld está residente na memória. Isso não assegura a capacidade real de processar transações. Quando o limite de paralelismo do motor InnoDB é alcançado, novas requisições entram em estado de espera, enquanto consultas leves continuam sendo despachadas imediatamente. Esse comportamento mascara uma degradação severa do serviço.

Consequentemente, mesmo com múltiplas consultas em execução ultrapassando o teto configurado, o mecanismo de verificação por consulta nula continua retornando êxito, falhando em sinalizar a falha operacional.

Validação por Acesso a Tabela e Operação de Escrita

Para capturar o esgotamento real do InnoDB, a verificação deve acessar objetos gerenciados pelo motor. A abordagem padrão envolve consultar uma tabela de monitoramento dedicada:

CREATE TABLE `sys_monitor_state` (
  `node_ref` VARCHAR(32) PRIMARY KEY,
  `last_pulse` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP
) ENGINE=InnoDB;

-- Sondagem passiva
SELECT last_pulse FROM mysql.sys_monitor_state LIMIT 1;

Contudo, essa estratégia colapsa quando o volume de binlog ocupa 100% do armazenamento. Nesse cenário, operações de escrita são travadas pelo sistema operacional, mas leituras permanecem viáveis. A correção lógica é transformar o health check em uma operação de atualização:

UPDATE mysql.sys_monitor_state SET last_pulse = NOW() WHERE node_ref = 'primary_node';

Em topologias dual-master, aplicar a mesma atualização em ambos os nós gera conflitos de replicação e pode interromper o fluxo de sincronização. A mitigação utiliza o identificador único do servidor como chave de particionamento, aplicando a cláusula ON DUPLICATE KEY UPDATE para evitar colisões e manter a integridade do log binário:

INSERT INTO mysql.sys_monitor_state (node_ref, last_pulse)
VALUES (CAST(@@server_id AS CHAR), CURRENT_TIMESTAMP)
ON DUPLICATE KEY UPDATE last_pulse = NOW();

Limitações da Sondagem Externa e Métricas Internas

O mecanismo de escrita periódica ainda sofre com a aleatoriedade inerente às verificações assíncronas. Em situações de saturação extrema de disco (utilização de I/O em 100%), o escalonador do sistema operacional continua distribuindo fatias de tempo para tarefas leves. Como a consulta de saúde consome poucos recursos, ela pode ser concluída com sucesso antes do timeout configurado, fazendo o orquestrador classificar erroneamente o nó como íntegro, enquanto a camada de aplicação experimenta latência crítica e timeouts de conexão.

Para eliminar a subjetividade da sondagem externa, é possível extrair métricas de latência diretamente do motor. A tabela performance_schema.file_summary_by_event_name agrega tempos de espera para operações de arquivo desde a versão 5.6.

UPDATE performance_schema.setup_instruments 
SET ENABLED = 'YES', TIMED = 'YES' 
WHERE NAME LIKE '%wait/io/file/innodb/innodb_log_file%';

Com os instrumentos de redo log e binlog ativos, a detecção de anomalias pode ser automatizada comparando a latência máxima de pico contra um limiar definido (ex: 250ms). Consultas que ultrapassem esse valor indicam gargalos físicos ou de agendamento de disco:

SELECT event_name, MAX_TIMER_WAIT AS peak_latency_ns
FROM performance_schema.file_summary_by_event_name 
WHERE event_name IN ('wait/io/file/innodb/innodb_log_file', 'wait/io/file/sql/binlog') 
  AND MAX_TIMER_WAIT > 250000000000;

Após a coleta e o disparo do alerta, os acumuladores devem ser zerados para que o próximo ciclo de monitoramento capture novas ocorrências sem distorção histórica e permita a reinicialização dos contadores de pico:

TRUNCATE TABLE performance_schema.file_summary_by_event_name;