MySQLdump тупик на таблице myisam?

Сегодня я проснулся с нашим рабочим сервером. Не счастлив.

Мы определили проблему для ежедневного cronjob, который выполняет полный mysqldump из производственной базы данных на удаленный сервер.

Команда SQL была просто

mysqldump -u myuser -pmypassword mydatabase >outfile.sql

Тем не менее, войдите в консоль администратора mysql и введите список процессов Show; Команда отображала следующее:

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 - это обычная таблица MyIsam, всего ~300K записей.

Моя лучшая на данный момент гипотеза заключается в том, что веб-запрос, выданный одновременно с выполнением mysqldump, заблокировал оба запроса. Может ли это случиться?

Будет ли запуск mysqldump с параметром --lock-tables=false навсегда решить эту проблему?

Спасибо за ваше время.

1 ответ

Решение

--lock-tables=false, вероятно, остановит это, но потенциально может привести к формированию противоречивой резервной копии. Тем не менее, поскольку MyISAM не контролируется транзакциями, это не должно иметь большого значения.

Другой альтернативой может быть использование другого механизма хранения (такого как InnoDB), который использует другую модель блокировки.

Другие вопросы по тегам