Сегодня я проснулся с отключенным нашим производственным сервером. Не счастлив.
Мы выявили проблему в ежедневном задании cron, которое выполняет полный mysqldump из производственной базы данных на удаленный сервер.
Команда SQL была просто
mysqldump -u myuser -pmypassword mydatabase >outfile.sql
Однако, войдя в консоль администратора mysql и выполнив Показать список процессов; команда отобразила следующее:
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 навсегда решить эту проблему?
Спасибо за уделенное время.
--lock-tables = false, вероятно, остановит это, но потенциально может привести к формированию несогласованной резервной копии. Тем не менее, поскольку MyISAM не контролируется транзакциями, это не должно иметь большого значения.
Другой альтернативой может быть использование другого механизма хранения (такого как InnoDB), который использует другую модель блокировки.