Сервер УКМ4. ошибка подключения к mysql : УКМ-4

Всем добрый день.
Натолкнулся на проблему, периодически не могу подключиться к БД сервера, выдает ошибку 1045. По описанию говорится что это либо неправильный пользователь, хост или пароль. Но подключаюсь утилитой SQLyog в которой логин пароль сохранены и не меняются. Подключаюсь непосредственно с самого сервера на котором установлен mysql. Тех поддержка не помогла в этом вопросе. Есть идеи из-за чего это может быть?

В первую очередь лезем в журнал винды и убеждаемся, что "красненького" и "желтенького" там ничего нет. Можно еще и в журнале MySQL посмотреть.
Потом убеждаемся, что никакой антивирус у нас в принципе не установлен (это же сервер БД).
Могу предположить, что грант на вход дан по адресу машины, а DNS лагает, например. Или что-то прерывает сам процесс аутентификации. Например, системные таблички побились или диск сбоит во время их чтений. Ошибка из разряда глюков, чем так славится Windows и поиск решения может привести к ее переустановке.

Посмотрел. И вот что обнаружил. Вчера в логах появились следующие записи.
InnoDB: Cannot open table mysql/slave_worker_info from the internal data dictionary of InnoDB though the .frm file for the table exists.
InnoDB: Cannot open table mysql/slave_relay_log_info from the internal data dictionary of InnoDB though the .frm file for the table exists.
InnoDB: Cannot open table mysql/slave_master_info from the internal data dictionary of InnoDB though the .frm file for the table exists.
InnoDB: Cannot open table mysql/slave_worker_info from the internal data dictionary of InnoDB though the .frm file for the table exists.
InnoDB: Cannot open table mysql/slave_relay_log_info from the internal data dictionary of InnoDB though the .frm file for the table exists.
InnoDB: Cannot open table mysql/slave_master_info from the internal data dictionary of InnoDB though the .frm file for the table exists.
До этого дня таких записей не встречается. В базе mysql эти таблички не открываются.

Бывает, табличка ломается.
А если это системная табличка - как раз и будут проблемы только с определенными действиями, затрагивающими сбойный кусок словаря.
Если не поможет set-variable=innodb_force_recovery=6 - бэкап, если он есть, или пересоздавать БД, переливать данные (если есть СГО - проще).

Например, у меня в БД конвертера поломалась таблица смен.
Но я не чиню, мне лень :). Отчеты по ней крайне редко требуют.

Миниатюры

 

Сейчас пытаюсь восстановить эти таблички. ТП дала пару ссылок. Суть ремонта следующая: устанавливаем БД на другой ПК, делаем дамп таблиц innodb_index_stats, innodb_table_stats, slave_master_info, slave_relay_log_info, slave_worker_info. На проблемном сервере удаляем эти таблицы ibdata1. и восстанавливаем из дампа.
Но столкнулся с проблемой. Для дампа структуры таблиц есть скрипт:
TABLELIST="innodb_index_stats"
TABLELIST="${TABLELIST} innodb_table_stats"
TABLELIST="${TABLELIST} slave_master_info"
TABLELIST="${TABLELIST} slave_relay_log_info"
TABLELIST="${TABLELIST} slave_worker_info"
mysqldump -uroot -p mysql ${TABLELIST} > mysql_innodb_tables.sql
Он выдает ошибку ERROR 1064 (42000): You have an error in your SQL syntax
версия mysql: 5.6.17

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

Бесперебойник стоит. Уж что что, но с этой стороны прикрыто.