Aumentar o tamanho max_allowed_packet no MySQL

Resumo — Para aumentar o tamanho max_allowed_packet de forma permanente, adiciona max_allowed_packet=1G em [mysqld] no my.cnf e reinicia o MySQL. Para uma correção imediata sem reinício, executa SET GLOBAL max_allowed_packet=1073741824; num cliente MySQL. Confirma a alteração com SHOW VARIABLES LIKE 'max_allowed_packet';.

Visual representation: Increase max_allowed_packet Size in MySQL. Image created by Dali.

Quando o MySQL recebe uma query com um pacote de dados maior do que o valor de max_allowed_packet, lança um erro "Packet too large" e fecha a ligação. Este é um erro comum do MySQL em ambientes WordPress — aparece em erros de tamanho de pacote MySQL durante o push, pacote demasiado grande durante a clonagem, importações grandes de bases de dados e migrações de sites. O valor predefinido está baixo em relação ao que sites WordPress grandes precisam, mas aumentá-lo é simples assim que identificas o método certo para o teu ambiente de Hosting.

Por exemplo, se o restauro do Backup do WP STAGING falhar devido a um tamanho de pacote demasiado pequeno, a mensagem de erro mostra o tamanho da query problemática para que possas ajustar o max_allowed_packet em conformidade. Na versão atual do WP STAGING, o Plugin regula e executa queries de base de dados dinamicamente com base no tamanho máximo de pacote permitido no servidor, mas o limite subjacente do MySQL continua a aplicar-se a importações diretas e ferramentas de terceiros.

Tens duas opções para alterar o tamanho max_allowed_packet do MySQL: uma alteração permanente no ficheiro de configuração do MySQL e uma alteração temporária via SQL — ambas cobertas abaixo.

O que o max_allowed_packet controla

A variável de sistema max_allowed_packet define o tamanho máximo de um único pacote de comunicação entre o cliente e o servidor MySQL. Quando uma query, linha de resultado ou definição de stored routine excede este limite, o MySQL termina a ligação e regista um erro.

Padrões comuns de sintomas:

  • "Packet too large" — o MySQL rejeita imediatamente a query.
  • "MySQL server has gone away" — a ligação cai durante uma importação demorada.
  • Falhas de push ou restauro no WP STAGING quando o site contém grandes revisões de publicações, valores de opções serializados ou metadados de imagens guardados como post meta.
  • Erros durante o restauro com mysqldump ou importação por phpMyAdmin.

Na nossa fila de suporte, o motivo mais comum é um push do WP STAGING que inclui bibliotecas grandes de imagens ou revisões de publicações guardadas como post meta. Também vimos isto bloquear aumentar o max_allowed_packet antes de migrar para um novo Hosting — apanhar o limite antes de uma migração evita falhas de importação a meio da transferência.

Que método devo usar?

O teu ambiente Melhor método
VPS ou servidor dedicado com acesso SSH Editar my.cnf — permanente
Hosting partilhado (sem SSH) Contacta o fornecedor de Hosting; o phpMyAdmin permite inspecionar o valor atual mas não o alterar permanentemente
AWS RDS for MySQL Modificar um DB parameter group na consola AWS
DigitalOcean Managed MySQL Definir através do separador "Configuration" no painel
Necessitas de correção imediata sem reinício Comando SQL SET GLOBAL — temporário, reinicia ao reiniciar

Se não tens a certeza de que ficheiro de configuração o MySQL está a ler, executa mysql --verbose --help | grep my.cnf num terminal para veres a ordem completa de procura.

Como definir max_allowed_packet de forma permanente

Uma alteração permanente sobrevive a reinícios do servidor MySQL. O método depende do teu ambiente de Hosting.

VPS ou servidor dedicado: editar my.cnf

  1. Abre my.ini (Windows) ou my.cnf (Linux/macOS) na diretoria de instalação do servidor MySQL. Na maioria dos sistemas Linux o ficheiro está em /etc/mysql/my.cnf ou /etc/my.cnf. Para configurar o servidor MySQL via linha de comandos, verifica primeiro o caminho exato com mysql --verbose --help | grep my.cnf.
  2. Localiza a secção [mysqld]. A diretiva tem de ir em [mysqld], não em [mysql] ou [client] — colocá-la na secção errada é a razão mais comum para a correção parecer funcionar mas não ter efeito.
  3. Encontra ou adiciona a linha max_allowed_packet. Para definir o valor para 1 GB:
[mysqld]
max_allowed_packet=1G
  1. Guarda o ficheiro, depois reinicia o MySQL:
sudo systemctl restart mysql
  1. Verifica o novo valor:
SHOW VARIABLES LIKE 'max_allowed_packet';

Hosting partilhado: inspecionar via phpMyAdmin

Em Hosting partilhado sem acesso SSH, podes verificar o valor atual de max_allowed_packet navegando em phpMyAdmin → Variables e procurando por max_allowed_packet. Para o aumentar permanentemente, contacta o teu fornecedor de Hosting — esta é uma definição a nível de servidor que requer acesso administrativo fora do painel partilhado.

Bases de dados geridas: AWS RDS e DigitalOcean

Serviços MySQL geridos em cloud expõem a variável através dos respetivos painéis em vez de um ficheiro de configuração:

  • AWS RDS for MySQL — abre a instância de base de dados na consola AWS, navega até ao parameter group associado e define o max_allowed_packet. Aplica o parameter group atualizado e reinicia a instância para a alteração ter efeito.
  • DigitalOcean Managed MySQL — navega até ao separador Configuration do teu cluster de base de dados e atualiza aí o max_allowed_packet.

Em ambas as plataformas, define o valor antes de executar uma importação ou migração grande. Vê aumentar o max_allowed_packet antes de migrar para um checklist pré-migração.

Como definir max_allowed_packet temporariamente

A variável max_allowed_packet pode ser definida globalmente executando um comando SQL. Isto entra em vigor imediatamente — sem necessidade de reinício — mas o valor é reposto quando o servidor MySQL reinicia. Faz sempre o follow-up com a edição permanente do my.cnf se precisares que a alteração persista.

No entanto, se não o alterares no ficheiro my.ini, o valor será sempre reposto quando o servidor reiniciar, mesmo que o tenhas definido globalmente.

Para alterar o max allowed packet para todos para 1 GB até o servidor reiniciar:

SET GLOBAL max_allowed_packet=1073741824;

Verifica imediatamente:

SHOW VARIABLES LIKE 'max_allowed_packet';

Este método é útil para desbloquear erros de max_allowed_packet em restauro em curso, ou para testar o valor correto antes de o comprometer no ficheiro de configuração.

O que fazer se a correção não tiver efeito

Se SHOW VARIABLES LIKE 'max_allowed_packet'; continuar a devolver o valor antigo após a alteração, percorre este checklist:

  1. Secção de configuração errada. A diretiva tem de estar em [mysqld]. Abre o ficheiro e confirma o cabeçalho da secção imediatamente acima da linha max_allowed_packet.
  2. Ficheiro de configuração errado. O MySQL lê vários ficheiros numa ordem específica e o último valor correspondente ganha. Verifica o caminho de procura real:
mysql --verbose --help | grep my.cnf
  1. O MySQL não foi reiniciado. Confirma que o serviço reiniciou com sucesso:
sudo systemctl status mysql
  1. Ficheiro não guardado ou não legível. Verifica se o ficheiro foi guardado e se o MySQL tem permissão de leitura.
  2. Nós replicados. Num ambiente replicado, o SET GLOBAL aplica-se apenas ao nó ao qual te ligaste. Cada réplica requer a sua própria atualização do ficheiro de configuração.
  3. Limite no lado do cliente. Alguns clientes de base de dados definem max_allowed_packet no momento da ligação. Se o valor do cliente for inferior ao do servidor, aplica-se o limite do cliente independentemente da definição do servidor.

Já vimos a correção falhar silenciosamente quando o cabeçalho da secção [mysqld] faltava num my.cnf recém-provisionado que continha apenas entradas [mysql] — o MySQL analisa o ficheiro sem erros mas ignora a diretiva.

Para erros relacionados de limite de memória do servidor que aparecem ao lado de erros de pacote MySQL em ficheiros de log, aplicam-se as mesmas regras de secção de configuração. Para outros limites de servidor MySQL e PHP, uma abordagem semelhante de edição do ficheiro de configuração do servidor resolve o problema.

Artigos relacionados

Updated on May 23, 2026

Rene Hermenau

Autor: Rene Hermenau

About the author: René Hermenau is the founder of WP STAGING. He works on WordPress backups, staging, migrations, database handling, and safe deployment workflows.