Одминский блог

Обнуление сбойных таблиц при ошибке mysql timeout

Дал тут ссылку на один свой сайт в профильной группе ФБ и сразу словил нашествие ботов и посетителей. При этом статистика посещений Statpress люто тупила, как оказалось из-за того, что я не поставил дропы базы по времени.

Так что не придумал ничего лучше, как выставить удаление записей через месяц для ботов и три месяца для посетителей.

После чего сайт лег в 500 ошибку. Думал что попустит, минут через 5-10, но не фига.

Полез в логи, там ошибки что то вида
[Wed Aug 28 09:32:22 2019] [error] [client 111.222.333.444] WordPress database error Lock wait timeout exceeded; try restarting transaction for query DELETE FROM wp_statpress WHERE date < ’20190530′ made by require(‘wp-blog-header.php’), wp, WP->main, WP->send_headers, do_action_ref_array, call_user_func_array, nsp_StatAppend, referer: site.ru
2019/08/28 09:32:37 [error] 5836#5836: *33 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 111.222.333.444, server: site.ru, request: “GET / HTTP/1.1″, upstream: “http://site_IP:8080/”, host: “site.ru”

полез в пхпадмин, где обнаружил у таблички statpress отрицательные значения в числе операций. Попробовал её сначала чекнуть, потом очистить и под конец дропнуть, но на все возвращалась ошибки 504, которые gateway timeout.

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

в итоге проверка базы не помогла, т.к статпрессовская база была на InnoDB
# mysqlcheck -r –databases admin_DB -u admin_UZR -p
Enter password:
admin_DB.wp_STATCOUNTER
note     : The storage engine for the table doesn’t support repair
admin_DB.wp_commentmeta                        OK
admin_DB.wp_comments                           OK
admin_DB.wp_gdrts_cache
note     : The storage engine for the table doesn’t support repair

а вот попытка оптимизнуть базу, внезапно, порешала проблему с обнулением базы, т.к в процессе оптимизации, все InnoDB базы были обнулены и пересозданы
# mysqlcheck -o –databases admin_DB -u admin_UZR -p
Enter password:
admin_DB.wp_STATCOUNTER
note     : Table does not support optimize, doing recreate + analyze instead
status   : OK
admin_DB.wp_commentmeta                        OK
admin_DB.wp_comments                           OK
admin_anchdb.DB_gdrts_cache
note     : Table does not support optimize, doing recreate + analyze instead
status   : OK

Так что можно тупо натравливать на проблемную таблицу, ограничивая оптимизацию:
# mysqlcheck -o admin_DB wp_statpress -u admin_UZR -p

По хорошему, все снесенные таблички, отвечали только за статистику, т.ч потеря их не привела ни к каким критическим потерям на сайте и по этой причине, вполне спокойно можно продолжать работать дальше.

Теги: mysql