MySQL 5.0 - atualização 5.1, atualizações de tabelas demorando muito tempo

Question

Nós temos um servidor de banco de dados que estava executando o MySQL 5.0 no Debian etch (!), e decidimos que era hora de atualizar. Agora ele está rodando o 5.1 no Debian squeeze.

Este servidor de banco de dados tem cerca de 1,2 TB de dados MyISAM em uma matriz RAID SATA e 2 GB de RAM. Normalmente, a velocidade não é um fator para as consultas que este servidor executa, é principalmente o material de fundo.

Na atualização, o pacote Debian executou um script de manutenção para atualizar as tabelas, mas está demorando muito tempo para atualizar cada tabela. Por muito tempo, quero dizer que está levando cerca de 18 horas por mesa, e fazer o lote levará algo como 6 semanas na velocidade atual. Este é um grande problema.

Eu tentei aumentar o key_buffer global para 512MB, o que parece estar de acordo com as recomendações, sem efeito.

O problema parece ser que ele está usando o método "Reparar com keycache", que é muito mais lento que o método de classificação:

mysql> show processlist;
+-----+------------------+----------------------------------+------------------+---------+-------+----------------------+--------------------------------------------------------------------------+
| Id  | User             | Host                             | db               | Command | Time  | State                | Info                                                                     |
+-----+------------------+----------------------------------+------------------+---------+-------+----------------------+--------------------------------------------------------------------------+
|   5 | debian-sys-maint | localhost                        | xxxxxxxxxxxxxxxx | Query   | 45146 | Repair with keycache | REPAIR TABLE 'xxxxxxxxxxxxxxxx'.'xxxxxxxxxxxxxxxxxxxx'     

Outras tabelas estão inacessíveis devido à necessidade de atualização:

mysql> check table xxxxxxxxxxxxxxxxxxxx fast quick;
+---------------------------------------+-------+----------+---------------------------------------------------------------------------------------------------+
| Table                                 | Op    | Msg_type | Msg_text                                                                                          |
+---------------------------------------+-------+----------+---------------------------------------------------------------------------------------------------+
| xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | check | error    | Table upgrade required. Please do "REPAIR TABLE 'xxxxxxxxxxxxxxxxxxxx'" or dump/reload to fix it! |
+---------------------------------------+-------+----------+---------------------------------------------------------------------------------------------------+
1 row in set (1.09 sec)

A questão principal é: como posso atualizar essas tabelas e obter os dados on-line mais rapidamente?

Questões secundárias seriam:

• O uso do myisamchk com algo como " myisamchk --sort-recover --analyze --sort_buffer_size=256M --key_buffer=256M --read_buffer=2M --write_buffer=2M tablename " atualiza a tabela (ou seja, não usa o método keycache)?
• Posso matar com segurança o script debian e atualizar as tabelas com um método mais eficiente?
• O servidor foi inicialmente iniciado com um key_buffer_size de apenas 16M. Eu já corrigi isso definindo a variável global, mas é possível que a sessão do script debian ainda esteja usando algum valor menor? Se sim, posso alterá-lo?

Answer 1

Acontece o script debian apenas o script de inicialização padrão que verifica as tabelas que precisam de atualização, portanto, eliminá-lo não foi um problema, pois ele simplesmente é executado novamente no init.

O valor do buffer de chave não era o problema, pois eu suspeitava que fosse o método de cache de teclas que ele estava usando para reparar a tabela - é simplesmente muito lento para tantos dados.

Uma vez que nós 'set global myisam_max_sort_file_size=21474836480;' e reiniciado o mysql, ele começou a usar o método de classificação que é muito mais rápido. Mas então, em outra tabela, voltou para o keycache, então eu a levantei para 80G e reiniciei novamente.

Todas as tabelas agora são atualizadas.

    

Answer 2

The main question is, how can I upgrade these tables and get the data online more quickly?

A resposta simples é mysql_upgrade .

Does using myisamchk with something like "myisamchk --sort-recover --analyze --sort_buffer_size=256M --key_buffer=256M --read_buffer=2M --write_buffer=2M tablename" upgrade the table (i.e. not using the keycache method)?

Não.

Can I safely kill the debian script and upgrade the tables with a more efficient method?

Eu preciso saber mais detalhes sobre esse script.

The server was initially started with a key_buffer_size of just 16M. I've since corrected this by setting the global variable, but is it possible that the debian script's session is still using some smaller value? If so can I alter it?

Você pode fazer isso por uma sessão:

mysql> SET SESSION key_buffer_size = ... ;