MySQLdump deadlock em uma tabela myisam?

1

Hoje acordei com o nosso servidor de produção desativado. Não feliz.

Nós identificamos o problema em um cronjob diário, que faz um mysqldump completo do banco de dados de produção, para um servidor remoto.

O comando SQL era simplesmente

mysqldump -u myuser -pmypassword mydatabase >outfile.sql

No entanto, logando no console administrativo do mysql, e emitindo uma Show processlist; comando exibido o seguinte:

statistics select clickthrough_rate, i1.token, length(title) as len, p.id as pid, i1.category_id, title, c.name
155250  root  localhost   mydatauser  Query 32164 Locked   insert into srch_logs (log_id, api_session_id, query, category_filter, clickthrough_item_id)  values
155251  root  localhost   mydatauser  Query 32163 Locked   insert into srch_logs (log_id, api_session_id, query, category_filter, clickthrough_item_id)  values
155254  root  localhost   mydatauser  Query 32145 Locked   insert into srch_logs (log_id, api_session_id, query, category_filter, clickthrough_item_id)  values
...[a lot of these, then]...
155941  root  localhost   mydatauser  Query 26147 Locked   LOCK TABLES 'api_asin_cache' READ /*!32311 LOCAL */,'api_auto_pricesets' READ /*!32311 LOCAL */,'api

srch_logs é uma tabela MyIsam normal, com meros ~ 300K registros.

Minha melhor hipótese atual, é que uma solicitação da Web emitida simultaneamente para fazer o mysqldump bloqueia a solicitação. Isso pode acontecer?

A execução do mysqldump com --lock-tables = false corrige esse problema permanentemente?

Obrigado pelo seu tempo.

    
por Silver Dragon 15.03.2011 / 12:59

1 resposta

2

- lock-tables = false provavelmente parará com isso, mas possivelmente levará a um backup inconsistente sendo formado. Dito isto, como o MyISAM não é controlado transacionalmente, não deve fazer muita diferença.

Outra alternativa pode ser usar um mecanismo de armazenamento diferente (como o InnoDB), que usa um modelo de bloqueio diferente.

    
por 15.03.2011 / 13:24