Um dos assassinos silenciosos do MySQL Connections é o MySQL Packet. Até o segmento de E / S da replicação do MySQL pode ser vítima disso.
De acordo com a documentação do MySQL
Você também pode obter esses erros se enviar uma consulta ao servidor incorreta ou muito grande. Se o mysqld recebe um pacote muito grande ou fora de ordem, assume que algo deu errado com o cliente e fecha a conexão. Se você precisar de grandes consultas (por exemplo, se estiver trabalhando com grandes colunas BLOB), poderá aumentar o limite de consultas definindo a variável max_allowed_packet do servidor, que possui um valor padrão de 1 MB. Também pode ser necessário aumentar o tamanho máximo do pacote no lado do cliente. Mais informações sobre a configuração do tamanho do pacote são fornecidas na Seção C.5.2.10, “Pacotes muito grandes”.
Uma instrução INSERT ou REPLACE que insere muitas linhas também pode causar esse tipo de erro. Qualquer uma dessas instruções envia uma única solicitação ao servidor, independentemente do número de linhas a serem inseridas; portanto, muitas vezes você pode evitar o erro reduzindo o número de linhas enviadas por INSERT ou REPLACE.
No mínimo, você deve certificar-se de que os tamanhos dos pacotes para a máquina da qual você mysqldump e a máquina que você está carregando sejam idênticos.
Pode haver duas (2) abordagens que você pode adotar:
ABORDAGEM # 1: Execute o mysqldump usando --skip-extended-insert
Isso garantirá que o pacote MySQL não seja inundado com vários campos BLOBs, TEXT. Dessa forma, os SQL INSERTs são executados um de cada vez. As principais desvantagens são
- o mysqldump é muito maior
- recarregar esse despejo leva muito mais tempo.
ABORDAGEM 2: Aumentar max_allowed_packet
Esta pode ser a abordagem preferida porque implementar isso é apenas uma reinicialização do mysql. Entender o que é o pacote MySQL pode esclarecer isso.
De acordo com a página 99 de "Entendendo o MySQL Internals" (ISBN 0-596-00957-7) , aqui estão os parágrafos 1-3 que explicam:
O código de comunicação de rede do MySQL foi escrito sob a premissa de que as consultas sempre são razoavelmente curtas e, portanto, podem ser enviadas e processadas pelo servidor em um pedaço, chamado de pacote na terminologia do MySQL. O servidor aloca a memória para um buffer temporário para armazenar o pacote e solicita o suficiente para ajustá-lo inteiramente. Essa arquitetura requer uma precaução para evitar que o servidor fique sem memória - um limite para o tamanho do pacote, que essa opção realiza.
O código de interesse em relação a esta opção é encontrado em
sql / net_serv.cc . Dê uma olhada em my_net_read () , siga a chamada para my_real_read () e preste atenção especial a
net_realloc () .
Essa variável também limita o comprimento de um resultado de muitas funções de string. Veja sql / field.cc e
sql / intem_strfunc.cc para obter detalhes.
Dada essa explicação, criar INSERTs em massa carregará / descarregará um pacote MySQL rapidamente. Isso é especialmente verdadeiro quando max_allowed_packet é muito pequeno para a carga de dados fornecida.
CONCLUSÃO
Na maioria das instalações do MySQL, costumo definir isso para 256M ou 512M. Você deve experimentar valores maiores quando o carregamento de dados produzir erros "O MySQL se foi".
max_allowed_packet
para 900M e estava usando--skip-extended-insert
(e você está certo - isso faz com db-dumps huuuge), mas ainda falha. Estou suspeitando de uma linha específica no despejo agora que provavelmente posso contornar. Mas ainda é estranho - o dump pode ser importado corretamente no meu servidor CentOS.