Lost connection to MySQL server during query


Bueno… começo o post de hoje com este título nada agradável. Quem usa Mysql já passou por ela algumas vezes na vida.

Alguns clientes nossos também passaram por isso na semana passada, que, quando afetado por um bug do Mysql, que foi corrigido na última versão (5.1.33), fazia o sistema inteiro do mysql simplesmente cair. Simples assim… caiu. Por sorte, a KingHost possui hoje 10 servidores de mysql em operação (e com isso nem todos eram afetados simultaneamente), para dividir o tráfego e o processamento, alto índice de uso de memória ram para cache das queryes mais comuns, o que confere mais velocidade, mas… bugs são bugs, e são feitos para serem corrigidos.

O bandido da vez foi que, quando criada uma tabela em INNODB (existem vários tipos de armazenamento de dados em Mysql, como MyISAM, INNODB e MEMORY, as mais utilizadas, além de outros menos comuns), com um campo que fosse DOUBLE ou FLOAT, e que tivesse a característica de AUTO-INCREMENT, quando fosse adicionado um valor à esta tabela, ocorria um erro interno e o negócio caía todo… não somente a conexão do cliente que estava inserindo o valor, mas todas as conexões abertas, tornando o servidor inteiro indisponível por 1 a 5 minutos, que é o tempo que leva para reconstruir os índices das tabelas INNODB e iniciar o recebimento de conexões, passando posteriormente pela checagem de cada tabela que no momento do crash estava aberta, reparando se necessário (myisam_recover) ou encaminhando para um script de verificação que faz a reparação (em casos onde a reparação automática falha é necessário rodar o comando repair table manualmente. Claro que cada evento desses demorava cerca de 30 minutos para normalizar em função do alto processamento consumido na checagem de cada nova tabela aberta para uso. Como somos especialistas no negócio, um script faz este trabalho manual automaticamente quando detecta este tipo de necessidade)

O propósito deste post é explicar um pouco do problema para os clientes afetados e alertar a comunidade para este grave problema existente no mysql 5.1 em versões iguais ou anteriores à 5.1.32

Lembro que vale apenas para tabelas INNODB. Tabelas em MYISAM e MEMORY não são afetadas. Porém, se em seu servidor de MYSQL existir UMA ÚNICA TABELA INNODB com esta característica, deve ser feito upgrade imediato.

Para quem se interessa, a página oficial do BUG é esta: bugs.mysql.com/bug.php?id=42400

Atenção!!! Outras empresas de hospedagem de sites podem estar vulneráveis e não saber…

Mensagem de erro que ocorria quando do crash:

InnoDB: Assertion failure in thread 1101715792 in file handler/ha_innodb.cc line 3454
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html
InnoDB: about forcing recovery.
– mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.

key_buffer_size=536870912
read_buffer_size=2097152
max_used_connections=39
max_threads=1000
threads_connected=28
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 4630444 K bytes of memory
Hope that’s ok; if not, decrease some variables in the equation.

thd: 0x7f8f10bb8640
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong…
stack_bottom = 0x41aad0e0 thread_stack 0x40000
/usr/sbin/mysqld(my_print_stacktrace+0x24) [0x8b6224] /usr/sbin/mysqld(handle_segfault+0x320) [0x5f7600] /lib/libpthread.so.0 [0x7f8f945d4ed0] /lib/libc.so.6(gsignal+0x35) [0x7f8f932c23c5] /lib/libc.so.6(abort+0x10e) [0x7f8f932c373e] /usr/sbin/mysqld(ha_innobase::write_row(unsigned char*)+0x147) [0x78e297] /usr/sbin/mysqld(handler::ha_write_row(unsigned char*)+0x6f) [0x6ea18f] /usr/sbin/mysqld(write_record(THD*, st_table*, st_copy_info*)+0x5b) [0x67cc9b] /usr/sbin/mysqld(mysql_insert(THD*, TABLE_LIST*, List<Item>&, List<List<Item> >&, List<Item>&, List<Item>&, enum_duplicates, bool)+0x836) [0x681616] /usr/sbin/mysqld(mysql_execute_command(THD*)+0x1ed1) [0x6075b1] /usr/sbin/mysqld(mysql_parse(THD*, char const*, unsigned int, char const**)+0x227) [0x60d277] /usr/sbin/mysqld(dispatch_command(enum_server_command, THD*, char*, unsigned int)+0x3e2) 0x60d662] /usr/sbin/mysqld(do_command(THD*)+0xe4) [0x60e6b4] /usr/sbin/mysqld(handle_one_connection+0x663) [0x5ff403] /lib/libpthread.so.0 [0x7f8f945cd047] /lib/libc.so.6(clone+0x6d) [0x7f8f9335228d] Trying to get some variables.
Some pointers may be invalid and cause the dump to abort…
thd->query at 0x7f8f10b593d0 is an invalid pointer
thd->thread_id=2335
thd->killed=NOT_KILLED

Comentários

comentário(s)

5 Comments

Add yours
  1. Carlos Henrique

    Tenho um plano de revenda com a king, até o momento nenhum cliente nos reportou algum tipo de problema.

    Alem da revenda temos servidores dedidados tambem, e esse sim tivemos que fazer um upgrade no banco de dados.

    Mas o alerta é certo, muitas mas muitas empresas por ai nem sabe que esse bug existe.

    abraços

  2. Anonimo

    Apesar de não ter tido problemas como este, admiro a atitude do pessoal da KingHost.
    A sinceridade constrói relacionamentos sólidos.
    Eu sempre procuro trabalhar com pessoas e empresas que sejam transparentes e a KingHost está se mostrando excelente neste quesito. Tanto no atendimento quanto na qualidade do serviço.
    A característica do atendimento da KingHost é marcado pela informalidade, o que torna saudável e confiável ser atendido pelos profissionais da empresa.
    Como cliente, me sinto próximo da empresa.
    Parabéns à toda equipe.

    Abraços

  3. Carlos

    Muito bonito o post, mas eu estou vivendo esse erro nos últimos meses, dentro da kinghost..

    Neste momento por exemplo ^^

    Lost connection to MySQL server at ‘reading initial communication packet’, system error: 111

    Aqui eu curti o tratamento, mas via ticket??
    Olha, me sinto como se estivesse ligando para a OI (e não, isso não é um elogio).

+ Leave a Comment