↓Pular para o conteúdo principal
  1. blog/
ARTIGO TÉCNICO

Migrando Zabbix 3.4 → 7.0: os bugs de charset, double precision e proxy que ninguém avisa

Migração incremental de um Zabbix 3.4.15 legado até 7.0 LTS — charset/collation, double precision, MySQL 8 e proxy atrás de NAT.

·2 minutos

Contexto #

Zabbix 3.4.15 rodando há anos, com banco MySQL 5.7 e configuração acumulada. O caminho para chegar em 7.0 LTS foi incremental:

1
2
Zabbix 3.4 → 4.0 → 5.0 → 6.0 → 7.0
MySQL 5.7 → MySQL 8.0

Charset/collation fora do padrão #

Bancos antigos podem acumular tabelas com charset divergente. Antes de avançar, o schema precisa ser normalizado e validado.

1
ALTER DATABASE zabbix CHARACTER SET utf8 COLLATE utf8_bin;

double precision em history/trends #

A validação de schema em versões novas exige atenção ao tipo das colunas numéricas de history e trends. O frontend também precisa estar alinhado ao tipo IEEE754 esperado.

log_bin_trust_function_creators no MySQL 8 #

Durante upgrade, criação de funções/triggers pode falhar com binary logging mais estrito. O ajuste precisa ser aplicado e persistido de forma consciente no MySQL.

Proxy atrás de NAT #

Um proxy ativo pode ser rejeitado mesmo com configuração aparentemente correta quando o endereço cadastrado espera um IP diferente daquele visto pelo servidor após NAT. Nesse cenário, a validação do endereço pode virar bloqueio em vez de proteção.

SNMP #

No polling SNMP, quem consulta o equipamento é o proxy. Ao mover um host para outro proxy, rota e ACL UDP/161 também precisam permitir o novo originador da consulta.

Tecnologias #

Zabbix 7 LTS · MySQL 8 · Docker Compose · Traefik · SNMP

TEM UM CENÁRIO PARECIDO?

Me chama.

Manda o contexto, os sintomas e o que já foi testado. Bora organizar as evidências antes de sair mexendo.

Falar com Castro →
Sem enrolação. Com evidência.