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.
- 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.