Como ler a saúde de um Galera cluster em cinco variáveis de estado

Um Galera cluster (Percona XtraDB Cluster ou MariaDB Galera) pode parecer perfeitamente bem do lado da aplicação enquanto, em silêncio, corre com duas pernas, se trava a si próprio ou mantém um nó que vai precisar de uma cópia completa para voltar a entrar. Cada um desses estados é visível num punhado de variáveis de estado. É assim que as lemos, e é isto que cada uma lhe diz.

O problema: «responde a queries» não é um health check

A maior parte da monitorização de uma base de dados em cluster verifica o mesmo que verificava num servidor isolado: a porta 3306 está aberta, o SELECT 1 devolve resultado. Um nó Galera que caiu fora do primary component continua a aceitar ligações. Um nó que está synced mas aplica as escritas demasiado devagar continua a responder a leituras. Um cluster de três que passou silenciosamente a cluster de dois continua a servir o website, até ao momento em que o nó seguinte desaparece e o quorum se perde.

O cluster sabe tudo isto sobre si próprio. Basta perguntar-lhe.

A única query a executar em todos os nós

SHOW GLOBAL STATUS WHERE Variable_name IN (
  'wsrep_cluster_status',
  'wsrep_cluster_size',
  'wsrep_local_state_comment',
  'wsrep_ready',
  'wsrep_cluster_state_uuid',
  'wsrep_flow_control_paused',
  'wsrep_local_recv_queue_avg',
  'wsrep_local_send_queue_avg',
  'wsrep_local_cert_failures',
  'wsrep_local_bf_aborts'
);

Execute-a em todos os membros, não apenas naquele a que o seu load balancer por acaso chega. Vários destes valores são locais ao nó, e as falhas interessantes são aquelas em que os nós discordam.

Pertença: este nó faz mesmo parte do cluster?

O wsrep_cluster_status tem de ser Primary. Qualquer outro valor (Non-Primary, Disconnected) significa que este nó perdeu o contacto com a maioria e vai recusar servir dados consistentes. Se o seu health check não olha para este valor, um nó particionado pode continuar a receber tráfego.

O wsrep_cluster_size tem de ser igual ao número de nós que construiu. É esta a variável que apanha o «corre com duas pernas». Um cluster de três nós que reporta dois continua a servir, continua em quorum e já não tem tolerância nenhuma. Crie um alerta de aviso no momento em que desce abaixo do tamanho de desenho, não quando chega a um.

O wsrep_local_state_comment deve indicar Synced. Donor/Desynced significa que o nó está a alimentar um joiner e pode estar mais lento; Joining e Joined significam que ainda está a recuperar o atraso. Um nó em qualquer estado que não Synced deve ser retirado do read pool pelo seu proxy até regressar.

O wsrep_cluster_state_uuid tem de ser idêntico em todos os nós. Dois valores diferentes significam que tem dois clusters, cada um convencido de que é o cluster. Isso só acontece depois de alguém fazer bootstrap do nó errado, pelo que vale a pena verificar após qualquer recuperação manual.

O wsrep_ready limita-se a confirmar que o nó aceita queries; se indicar OFF, os outros valores dir-lhe-ão porquê.

Desempenho: o cluster está a travar-se a si próprio?

A replicação do Galera baseia-se em certificação: todos os nós têm de concordar que um write set não entra em conflito antes de ele ser confirmado. Isso torna o cluster tão rápido quanto o seu applier mais lento, e o Galera impõe-no com flow control.

O wsrep_flow_control_paused é a fração de tempo, desde o último FLUSH STATUS, em que a replicação esteve em pausa porque algum nó não conseguia acompanhar. Leia-o como uma percentagem. Perto de zero é saudável. Qualquer valor persistentemente acima de alguns por cento significa que as escritas estão à espera de um nó lento, e a latência de escrita da sua aplicação está a pagar por isso. Faça flush, espere um intervalo conhecido, leia de novo, para que o número descreva o presente e não o mês passado.

O wsrep_local_recv_queue_avg diz-lhe qual é o nó lento. Um nó cuja média da fila de receção se mantém bem acima de zero é o que está a desencadear o flow control. Normalmente a causa é local: storage mais lento, um vizinho ruidoso, um relatório demorado ou poucos applier threads (wsrep_applier_threads, ou wsrep_slave_threads em versões mais antigas).

O wsrep_local_send_queue_avg a subir aponta na direção oposta: este nó tem dificuldade em enviar os seus próprios write sets, o que normalmente significa latência ou perdas de rede entre membros. É por isso que os membros do cluster pertencem ao mesmo fabric de baixa latência, com as cópias fora do site a cargo de réplicas assíncronas.

Conflitos: está a escrever em mais do que um nó?

O wsrep_local_cert_failures e o wsrep_local_bf_aborts contam transações revertidas porque outro nó confirmou primeiro uma alteração em conflito. A aplicação vê-as como erros de deadlock. Um fluxo constante num cluster em que todos os nós aceitam escritas é a assinatura da contenção entre vários writers, e os plugins de WordPress e de e-commerce que atualizam as mesmas linhas de opções ou de contadores em cada pedido produzem-na em volume.

A solução é arquitetural, não um botão de afinação: envie todas as escritas para um nó e distribua as leituras. Com ProxySQL é uma única linha:

INSERT INTO mysql_galera_hostgroups
  (writer_hostgroup, backup_writer_hostgroup, reader_hostgroup,
   offline_hostgroup, active, max_writers, writer_is_also_reader,
   max_transactions_behind)
VALUES (10, 20, 30, 40, 1, 1, 1, 100);
LOAD MYSQL SERVERS TO RUNTIME; SAVE MYSQL SERVERS TO DISK;

max_writers = 1 elege um writer, os restantes passam a readers e backup writers, e max_transactions_behind permite ao ProxySQL retirar automaticamente do read pool um nó atrasado. Assim que as escritas forem para um nó, estes dois contadores devem ficar quase parados.

Se depois os editores se queixarem de que uma gravação «desapareceu» ao recarregar, a leitura foi para um nó que ainda não tinha aplicado a escrita. Definir wsrep_sync_wait para essas sessões faz a leitura esperar que o nó recupere o atraso, com um pequeno custo de latência.

Reentrada: um nó volta depressa ou devagar?

Um nó que sai e regressa recebe ou os write sets em falta a partir da cache de um donor (IST, incremental e rápido) ou uma cópia completa do dataset (SST, lento e pesado para o donor). Qual dos dois recebe depende de a cache de write sets do donor, gcache.size em wsrep_provider_options, ainda guardar tudo o que o joiner perdeu.

Pode dimensioná-la a partir dos próprios contadores do cluster. Leia wsrep_replicated_bytes e wsrep_received_bytes com uma hora de intervalo; a soma das diferenças é aproximadamente o volume de write sets por hora. Multiplique pela janela de manutenção mais longa que prevê, acrescente uma margem, e essa é a gcache de que precisa. Um nó pode então ser corrigido, reiniciado ou mantido parado durante horas de trabalho de hardware e ainda assim reentrar de forma incremental.

Quorum: a aritmética por trás do «três»

O quorum é uma maioria estrita. Três membros toleram a perda de um. Quatro membros também toleram apenas um, porque dois em quatro não é maioria, pelo que o quarto nó compra capacidade mas não resiliência. Dois membros não toleram nada: se se perderem de vista, param ambos. Se tem mesmo apenas dois nós de dados, acrescente o Galera arbitrator (garbd) num terceiro host independente, para que continue a existir uma maioria.

A mesma aritmética aplica-se ao sítio onde os membros vivem. Três nós num único host, ou três nós cujos dados estão num único array de storage, são um só domínio de falha com três nomes. No Kubernetes, combine pod anti-affinity rígida com um PodDisruptionBudget de minAvailable: 2, para que uma atualização progressiva dos nós nunca possa levar dois membros de uma vez.

O que verificar no seu cluster esta semana

• Todos os nós reportam Primary, Synced, o mesmo state UUID e o tamanho de cluster que desenhou.
• O seu health check e o seu proxy usam ambos esses valores, não apenas uma ligação TCP.
• O wsrep_flow_control_paused, medido num intervalo recente, está perto de zero.
• As falhas de certificação não estão a subir; se estiverem, as escritas estão a chegar a mais do que um nó.
• A sua gcache cobre a janela de manutenção planeada mais longa.
• Nenhum par de membros partilha um host, um array ou (no Kubernetes) uma disrupção sem budget.

Um Galera cluster lido desta forma raramente surpreende alguém. Se o seu surpreende, teremos todo o gosto em dar uma vista de olhos.

cta: Fale com um engenheiro

Related

• /what-we-do/data-web/clustered-databases/
• /what-we-do/data-web/database-replication/
• /what-we-do/data-web/high-availability-platforms/