Projetos de rede Wi-Fi corporativo suportam alta disponibilidade do MySQL: guia prático

Seu cluster MySQL cai toda vez que um técnico anda pelo escritório com o laptop conectado ao Wi-Fi? Esse sintoma clássico revela que a camada de rede sem fio não foi projetada para sustentar os requisitos de tempo real da replicação síncrona. Muitas equipes tratam o Wi-Fi como ‘acesso à internet’ e esquecem que, em arquiteturas de alta disponibilidade, o meio de transporte dos pacotes de heartbeat e write-set é tão crítico quanto o próprio storage.

A boa notícia: com planejamento de RF, QoS adequado e ajustes nos timeouts do cluster, o Wi-Fi corporativo deixa de ser ponto de falha e passa a atuar como camada de redundância legítima. Este artigo mostra o caminho completo — do site survey à configuração do InnoDB Cluster — para que sua rede sem fio suporte SLAs de 99,99% sem surpresas.

Por que o Wi-Fi derruba clusters MySQL

A replicação Galera e o InnoDB Cluster dependem de heartbeats periódicos (geralmente a cada 1 s) e de entrega ordenada de write-sets. Em cabeamento estruturado, a latência é determinística (< 0,5 ms) e a perda de pacote é quase nula. No Wi-Fi, contudo, convivem retransmissões 802.11, contenção de canal, roaming entre APs e interferência de micro-ondas ou redes vizinhas. Cada milissegundo extra no RTT ou cada pacote perdido eleva a probabilidade de o grupo considerar o nó 'suspeito' e iniciar expulsão — o famoso *split-brain* evitável.

Além disso, muitos APs de entrada não suportam filas de prioridade WMM (Wi-Fi Multimedia) configuráveis, fazendo com que tráfego de backup, streaming ou Windows Update dispute o mesmo ar que o tráfego de replicação na porta 3306 ou 4567. O resultado é jitter de dezenas de milissegundos, suficiente para disparar evs.suspect_timeout padrão (5 s no Galera) e derrubar o nó.

Projeto de RF: a fundação invisível

Um site survey profissional — ativo e passivo — mapeia ruído de fundo, relação sinal/ruído (SNR ≥ 25 dB) e sobreposição de células (alvo 15–20% de overlap para roaming suave). Use canais de 20 MHz no 5 GHz (UNII-1 a UNII-3) e evite canais DFS em áreas onde estão os nós de banco; o *Channel Announcement* do radar força desconexão imediata de todos os clientes.

Distribua APs em modelo high-density (um AP a cada 80–100 m² em escritório típico) com potência de TX ajustada para criar células menores e mais determinísticas. Habilite Band Steering e Load Balancing no controlador, mas desative Airtime Fairness para o SSID do cluster — o tráfego de replicação deve ter prioridade absoluta de tempo de ar.

Roaming rápido: 802.11r/k/v na prática

O roaming tradicional (open authentication + reassociation) leva 100–300 ms, tempo demais para heartbeats de 1 s. A tríade 802.11r (Fast BSS Transition), 802.11k (Neighbor Report) e 802.11v (BSS Transition Management) reduz o *handoff* para < 50 ms, mantendo a sessão TCP do MySQL viva.

No controlador (Cisco, Aruba, Ubiquiti, Omada), crie um WPA3-Enterprise (ou WPA2-Enterprise) dedicado ao cluster, com VLAN isolada, raio de DHCP curto (lease 10 min) e Fast Roaming habilitado. Teste com iperf3 bidirecional e ping -i 0.2 durante walk test entre APs; não deve haver perda > 0,1% nem picos de latência > 10 ms.

QoS e isolamento de tráfego

Marque o tráfego MySQL com DSCP 46 (EF — Expedited Forwarding) na origem (servidor) e confie no mapa WMM do AP para colocar esses quadros na fila AC_VO (Voice). Se o controlador permitir, crie uma *ACL* ou *Policy* que garanta reserva mínima de *airtime* (ex.: 30%) para a VLAN do banco.

Evite misturar tráfego de guest, IoT e corporativo no mesmo rádio. Use Multi-SSID com VLANs distintas e, se possível, rádios dedicados (dual-band ou tri-band) para o SSID do cluster. O uplink do AP deve ser cabeado (Cat6a/6), PoE+ (802.3at) e conectado a switch com storm control e QoS trust dscp para preservar a marcação até o core.

Ajustes no MySQL para tolerar a rede real

Mesmo com RF perfeito, o Wi-Fi tem variabilidade inerente. Aumente `evs.suspect_timeout` para 8–10 s no Galera (`wsrep_provider_options`) e `group_replication_member_expel_timeout` para 10 s no InnoDB Cluster. Configure `group_replication_network_latency_threshold` (padrão 10 000 000 ns = 10 ms) para 20 ms se a mediana do RTT Wi-Fi for 5–8 ms.

Habilite wsrep_provider_options="gmcast.peer_timeout=PT10S;evs.keepalive_period=PT1S" no Galera. No InnoDB Cluster, use group_replication_flow_control_mode='QUOTA' e monitore Flow_control_paused — se subir, a rede é o gargalo.

Monitoramento contínuo e validação

Instale agentes de monitoramento (Prometheus + *node_exporter* + *blackbox_exporter*) em cada nó e nos APs (via SNMP/Streaming Telemetry). Colete: latência ICMP/TCP porta 3306, jitter, taxa de retransmissão 802.11 (`dot11RetryCount`), *roaming count* por cliente e *airtime utilization*.

Crie alertas: latência P99 > 15 ms por 2 min, retransmissão > 8%, roaming > 3/min por nó. Automatize failover de VIP apenas após confirmação de saúde da camada 2 (ex.: BFD sobre a VLAN Wi-Fi).

Validação em carga real

Antes de ir para produção, rode *sysbench* OLTP read-write (100 threads, 30 min) enquanto um engenheiro faz *walk test* contínuo entre APs. Verifique: zero *expel*, *Flow_control_paused* < 0,1%, latência de commit P99 < 5 ms. Documente os parâmetros finais no *runbook* de incidentes.

Uma infraestrutura de rede bem executada elimina a variabilidade que derruba clusters. Para projetos que exigem garantia de SLA em ambientes críticos, a JLA Informática suporte para empresas atua na camada de cabeamento e RF para que o DBA foque no banco, não no cabo. Consulte também nossas boas práticas de arquitetura de banco de dados para otimizar sistemas MySQL, o guia de diagnóstico de slow queries no MySQL e a leitura de como ler EXPLAIN no MySQL 8 para fechar o ciclo de performance.

Rede Wi-Fi corporativo deixa de ser ‘o cabo invisível que quebra’ e vira ativo de alta disponibilidade quando projetada com a mesma rigidez do storage. Aplique o checklist, meça, ajuste e durma tranquilo: seu cluster MySQL agradece.

Checklist prático

Perguntas frequentes

Por que o Wi-Fi corporativo impacta a alta disponibilidade do MySQL?

A replicação síncrona e semi-síncrona do MySQL exige latência baixa e jitter mínimo entre nós. Uma rede Wi-Fi mal dimensionada introduz perdas de pacote e variações de latência que disparam failovers desnecessários ou travam o commit das transações.

Quais métricas de rede devo monitorar para proteger o cluster MySQL?

Monitore latência média (alvo < 2 ms), jitter (< 1 ms), taxa de retransmissão 802.11 (< 5%) e tempo de roaming (< 50 ms). Alertas nessas métricas evitam que problemas de RF se tornem indisponibilidade de banco.

Como o roaming afeta a replicação Galera ou InnoDB Cluster?

Se o cliente (nó do banco) troca de AP durante um heartbeat, a interrupção pode exceder o `evs.suspect_timeout` ou `group_replication_member_expel_timeout`, causando expulsão do nó. Roaming rápido (802.11r/k/v) e overlap de células de 20% mitigam esse risco.

Vale a pena usar Wi-Fi 6/6E para clusters MySQL?

Sim. OFDMA e BSS Coloring reduzem contenção de meio e latência de cauda, essenciais para tráfego de replicação sensível. Porém, o projeto de RF e a cabeamento de uplink dos APs continuam sendo os fatores decisivos.

Posso rodar nó de MySQL apenas no Wi-Fi sem cabo?

Não recomendado para produção crítica. Use Wi-Fi apenas como link de redundância (failover) com métricas de SLA garantidas. O meio cabeado continua sendo o primário para tráfego de replicação e cliente.