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), который использует другую модель блокировки.