Error 1146 mysql: Mysql-Error-1146 – вопросы и ответы по программированию

Содержание

Рабочий черновик: Ошибка Mysql — ERROR 1146 (42S02): Table ‘mysql.servers’ doesn’t exist

На Cenos 5 работает mysql-5.1.58. При попытке дать команду «flush privileges» вылезала следующая ошибка:

mysql> flush privileges;
ERROR 1146 (42S02): Table ‘mysql.servers’ doesn’t exist

В базе «mysql» не было таблицы «servers».

mysql> use mysql;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

На других серверах с более поздней версией таблица «servers» была.

Для решения проблемы надо создать требуемую таблицу.

mysql> CREATE TABLE `servers` ( `Server_name` char(64) NOT NULL,

`Host` char(64) NOT NULL,

`Db` char(64) NOT NULL,

`Username` char(64) NOT NULL,

`Password` char(64) NOT NULL,

`Port` int(4) DEFAULT NULL,

`Socket` char(64) DEFAULT NULL,

`Wrapper` char(64) NOT NULL,

`Owner` char(64) NOT NULL,

PRIMARY KEY (`Server_name`) )

ENGINE=MyISAM

DEFAULT CHARSET=utf8

COMMENT=’MySQL Foreign Servers table’;

Query OK, 0 rows affected (0.02 sec)

##В последней строчке должны стоять одинарные кавычки, а не апостроф как выше.

После добавления таблицы все стало хорошо.

mysql> flush privileges;

Query OK, 0 rows affected (0.00 sec)

—

При написании заметки использовались материалы:

http://linux-lab. ru/oshibka-error-1146-42s02-table-mysql-servers-doesnt-exist/

ERROR 1146 (42S02): Table ‘mysql.servers’ doesn’t exist Flush privileges error in Mysql…

Ошибка MySQL Error 1146 в базе данных DLE — Общие вопросы по DLE

Версия 2.0.8 от 05.10.2017

1. Внесены некоторые поправки в алгоритмы, отвечающие за SMS и E-Mail верификацию в связи с изменениями в логике работы Instagram.

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

3. Исправлена проблема в функции «Удалить, используя игнор-лист», возникающая при использовании игнор-листов с неверными данными.

4. Исправлены некоторые проблемы, связанные с несоответствием цвета фона в колонке «Задача» после выхода оной из проблемного состояния.

5. В программу добавлена возможность отключать предупреждающие сообщения в функциях, что связаны с изменением технических данных устройства. Соответствующий переключатель находится на закладке «Эксперт» в главном окне программы.

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

7. В задачу «Отписка (+Блокировка)» добавлена возможность обжаловать профили по списку с той или иной формулировкой.

8. В задачи «Подписка по списку пользователей», «Подписка по списку хэштегов», «Подписка по подписчикам конкурентов» добавлена возможность активировать режим сёрфинга с привязкой к числу выполненных действий. По умолчанию этот режим включен, что позволит внести больше разнообразия в выполняемые программой действия в перечисленных задачах.

9. Для задач «Подписка по списку пользователей», «Подписка по списку хэштегов», «Подписка по подписчикам конкурентов» изменена группировка переключателей с подзакладки «Тех. настройки». Добавлены три дополнительные подзакладки «Алгоритмы», «Производительность», «Отладка», между которыми распределены новые и ранее существовавшие переключатели.

10. Исправлена ошибка соединения, которая в редких случаях могла возникать на финальной стадии взаимодействия с тем или иным SMS-сервисом через некоторые прокси в ходе SMS-верификации Instagram-аккаунтов.

11. В функцию массового редактирования профилей и связей добавлена возможность указывать диапазон для определения случайного тайм-аута, который может быть использован при последующей обработке Instagram-аккаунтов. По умолчанию тайм-аут не используется.

12. В редакторе профилей исправлена ошибка, возникающая при одиночном изменении пола того или иного Instagram-профиля на «без пола».

13. При массовой SMS-верификации Instagram-аккаунтов добавлена возможность использовать случайный тайм-аут из установленного диапазона с привязкой к количеству верифицируемых Instagram-аккаунтов. Новый блок настроек находится на подзакладке «Сервисы» в главных настройках программы. По умолчанию тайм-аут не используется.

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

15. Во все задачи, которые поддерживают работу с блоком «Матрица перерывов» добавлена возможность указывать время отложенного старта и/или формировать матрицу пользовательских перерывов для группы Instagram-аккаунтов.

16. В блок «Матрица перерывов» добавлена возможность устанавливать время отложенного старта случайным образом из указанного диапазона для одного или группы Instagram-аккаунтов.

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

18. В задачу «Шпион + Автолайкинг / Автокомментинг» добавлена возможность автоматической смены технических данных устройства во время выполнения задачи для каждого из используемых ботов при обнаружении спам-блокировки.

Решение ошибки Error 1146 Table doesn’t exist

Однажды у меня выпала такая ошибка Error 1146 Table doesn’t exist — Joomla 3 при следующих обстоятельствах.

Стояло расширение — JHackerGuard — которое практически не использовалось и решено было его удалить, точнее — де инсталлировать.

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

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

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

Итак, нахожу пакет, ставлю на де инсталляцию и … О, ЧУДО (!!!) — выползает ошибка 1146 Table doesn’t exist, которая сообщает, что какая-то там таблица в базе данных Joomla отсутствутет, причем таблица, имеющая отношение именно к этому расширению.

Попытки вернуться в панель управления оказались тщетными.

Бэкапа нет. Чувствую, как мурашки начинают расползаться по всему телу … что делать — что делать?

Про-гуглил интернет — результат ноль, предлагают в основном все ставить заново.

Немного поразмыслив и успокоившись пришел к следующему плану действий, который, забегая вперед скажу сразу — привел к положительному результату, может и еще кому поможет.

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

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

Супер! Бэкапы были созданы аж за последние тридцать дней!

Казалось бы — можно жить — но не тут-то было.

Бэкап базы данных не поддавался восстановлению по неизвестным причинам.

Пишет: Ошибка валидации.

Создается впечатление, что все сегодня просто сговорились.

Идем дальше.

Принимаю решение полного восстановления сайта. Для этого пытаюсь восстановить бэкап файловой системы у того-же хостера.

О чудо — удалось успешно!

Итак — все файлы восстановлены, дело осталось только за базой данных.

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

Но руки-то чешутся, ждать нет никакой возможности.

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

Здесь самый смак событий.

Чтобы восстановить недостающие таблицы в базе данных Joomla, необходимо выполнить SQL-запрос по вставке этих таблиц.

Где взять запрос? Да в самой системе Joomla.

Нахожу инсталяционный файл sql-запроса моего недавно удаленного расширения, в моем случае это

ваш_сайт/administrator/components/com_jhackguard/sql/install.mysql.utf8.sql

Теперь очень аккуратно!

Редактируем весь файл таким образом, чтобы префикс в имени создаваемой таблицы точно соответствовал у вас уже существующему префиксу.

После редактирования файла, на что ушло не более 1 секунды, копирую полученный готовый запрос через PHPAdmin своей бызы данных и … вуаля!

Недостающие таблицы успешно созданы.

Сайт полностью восстановил свою работу.

Вывод: без бэкапов не работаем.

Вот второй, не менее важный, а может быть и еще более важный вывод, который я сделал лично для себя,что ни всем расширениям можно доверять без оглядки.

Прежде чем ставить на рабочий сайт, его необходимо протестировать на локальном сервере, полностью удалить например, посмотреть — насколько корректно все работает и только тогда осторожненько ставить на рабочий сайт.

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

Всем удачи.

Получили что-то полезное для себя?

Борьба с ошибкой 1146 «Table `table_name` doesn’t exist when using LOCK TABLES» в СУБД MySQL

Попытался сделать дамп (бэкап) БД через родную для MySQL утилиту mysqldump и получил ошибку:

Got error: 1146: Table `table_name` doesn't exist when using LOCK TABLES

Вместо table_name имя несуществующей таблицы. Т.е. сразу после введения в консоль/терминал команды:

mysqldump --user=root -p db_name > db_name.sql

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

Попытки ухода от проблемы

Не стал обращать внимание на mysqldump и взял другие инструменты пытаясь убежать от проблемы, так сказать, решил применить альтернативные пути решения. Пробовал сделать дамп базы через менеджер баз данных phpMyAdmin и всё получилось, но при импорте (поднятии) дампа возникли ошибки. Так же пробовал сделать тамп через родной для MySQL графический менеджер БД MySQL Workbench, но он тоже стал ругаться и выдавать эту обишку ибо он так же пользуется утилитой командной строки mysqldump при экспорте БД. Пробовал экспортировать дамп БД так же при помощи Sypex Dumper, он сперва вроде работал, но потом тоже выдал аналогичную ошибку. Короче говоря зря я только тратил время с этими альтернативными инструментами работы с БД. Если не работает родной mysqldump, то и другие программы врядли помогут ибо с базой что-то не так и надо разбираться.

Попытки решения проблемы

Что же это за «doesn’t exist when using LOCK TABLES» такой. Придётся разобраться. Если перевести текст сообщения об ошибке, то в нём говорится примерно следующее: «Таблица `table_name` не существует при использовании команды LOCK TABLES». Т.е. не была найдена указанная таблица, что понятно, ведь её никто там не создавал и быть её не должно.

Если посмотреть базу через разные графические менеджеры БД вроде браузерного phpMyAdmin или десктопного MySQL Workbench, то такой таблицы в базе действительно нет и не должно быть, но СУБД MySQL почему-то считает, что она там есть или должна быть, однако если посмотреть базу через родной консольный менеджер БД mysql (MySQL monitor), то такая таблица там будет в общем списке таблиц. Надо разбираться.

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

Repairing tables
table_name
Error : Table 'table_name' doesn't exist
status : Operation failed

Решение проблемы

Воспользовался стандартным родным консольным менеджером БД, который так и называется mysql, он же полностью MySQL monitor. Зашёл под нужным пользователем БД, выбрал базу, вывел список таблиц базы и оказалось в этом списке действительно есть та самая несуществующая таблица, которая была указана в тексте сообщения об ошибке. Так же при попытке создать таблицу с таким именем получаешь сообщение об ошибке, что такая таблица уже существует. Решил посмотреть что же есть в этой таблице. Получил сообщение об ошибке, что такой таблицы не существует, что не удивительно, ведь её и не должно существовать, но СУБД MySQL считает, что она есть и выводит её в общем списке таблиц. Решил удалить эту таблицу и тоже получил сообщение, что такой таблицы нет и удалять нечего. После этого вновь запросил список всех таблиц базы данных и о чудо, это несуществующей таблицы в списке больше нет.

Таким образом, что бы решить проблему «Got error: 1146: Table `table_name` doesn’t exist when using LOCK TABLES» при работе с БД надо пользоваться родным консольным менеджером БД MySQL monitor (mysql). Попытайтесь сперва создать таблицу с таким именем и получите сообщеине об ошибке, что такая таблица уже есть в БД. Попытайтесь удалить эту таблицу и получите сообщение, что её и так нет. Во время одного из этих действий СУБД MySQL ещё раз проверит базу и убедится, что такой таблицы нет и вычеркнет её из мета информации БД, т.е. забудет про эту несуществующую таблицу, не будет выводить её в списке всех таблиц и не будет выводить эту ошикбу. Скорее всего проверка целостности базы происходит при попытке удаления этой несуществующей таблицы, поэтому пробовать создавать её и не нужно. Так же, возможно, пользоваться консольным MySQL monitor тоже не обязательно и можно послать SQL-запрос СУБД на удаление этой таблицы откуда удобно, просто в MySQL monitor эта таблица сперва отображается в общем списке а в остальных менеджерах баз данных не показывается. В общем точно не знаю что в моём алгоритме действий лишнее, а что необходимое, я лишь говорю как я решил эту проблему. Задача нетривиальная и попытаться воссоздать эту ошибку с целостностью базы ещё раз для учебных целей оказалось не просто. У меня был лишь один проход решения проблемы, поэтому, что точно её решило я не знаю.

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

На всякий случай прикладываю список консольных команд и SQL-запросов, которые я использовал в ходе решения этой проблемы. Хотел их писать сразу по ходу изложения, но решил, что это не нужно для тех кто и так знает, а для остальных (забывчивых) напишу список ниже, названия файлов, пользователей, таблиц и баз, естественно взяты для примера, подставляйте свои.

Для начала консольная команды.
Попытка сделать дамп базы через утилиту mysqldump:

mysqldump --user=root -p db_name > db_name.sql

Пакетная проверка и восстановление всех таблиц базы данных через родную утилиту mysqlcheck:

mysqlcheck --user=USER --password=PASSWORD --auto-repair --check --all-databases

Вход в консольный менеджер баз данных MySQL monitor с указанием данных:

mysql --user=USER --password=PASSWORD

Далее работает непосрдественно с БД, поэтому теперь пойдут SQL-запросы.
Просмотр всех доступных для пользователя (для просмотра) баз данных:

SHOW DATABASES;

Выбор необходимой рабочей базы данных для работы с ней:

USE <db_title>;

Просмотр всех доступных для пользователя таблиц выбранной базы данных:

SHOW TABLES;

Просмотр содержимого указанной таблицы (с лимитом записей/строк):

SELECT * FROM table_title LIMIT 100;

Удаление таблицы из базы данных:

DROP TABLE table_title;

Следует понимать, что несуществующая таблица, это ошибка структуры базы данных, т.е. надо копать в эту сторону, восстанавливать структуру БД, а не таблиц.

Если моё решение не помогло, то можно попробовать воспользоваться утилитой «innodb tools» (Percona Data Recovery Tool for InnoDB) (https://code.google(точка)com/archive/p/innodb-tools/). Ещё есть решение описанное здесь (http://adw0rd(точка)com/2009/07/02/recovery-innodb/), но там народ в комментариях говорит, что это не всегда помогает.

На этом все, всем спасибо за внимание.

Laravel Panel Giving error 1146 | PHP | MySQL | Linux | Laravel | Apache

Hello,

i was changed my hosting and buy cloud hosting before my both panels are working.

i think so its some mysql table problem or migration problem

I have two Laravel-5 panels ( Client and Admin panel ) with all codes on cpanel saved

Client Panel showing error : (2/2) QueryException

SQLSTATE[42S02]: Base table or view not found: 1146 Table ‘[login to view URL]’ doesn’t exist (SQL: select * from `sessions` where `id` = HlfPCfZZv4vyp8UKwnhBJYqnqlwG0AZRf6N7aZCs limit 1)

Admin dashboard need to be install on my dedicated linux server or link to my cpanel where Laravel all data are saved

Навыки: PHP, MySQL, Linux, Laravel, Apache

Показать больше:
database error 1146 query table, phplist database error 1146 query table doesnt exist, phplist database error 1146 query table, base table or view not found 1146 table doesn’t exist cakephp 3, in connection. php line 664: sqlstate[42s02]: base table or view not found: 1146 table, pdoexception: sqlstate[42s02]: base table or view not found, sqlstate 42s02 base table or view not found 1146 table laravel, laravel telescope docker, telescope_entries doesn t exist, cache_rules doesn t exist, telescope_entries, database error 1146 query table user doesnt exist, database error 1146 query table doesnt exist, mysql error 1146 creloaded, database error 1146 doesnt exist phplist, cre install mysql error 1146, database error 1146 query, phplist error 1146, phplist database error 1146, database error 1146 query user doesnt exist

(
3 отзыв(-а, -ов)

)

Haripur, Pakistan

ID проекта: #20567802

Как бороться с ненайденными таблицами при mysqldump? · BaRoN! blog

Сегодня надо было перенести огромный сайт. Там не тысячи, а десятки тысяч таблиц. При mysqldump вылезает ошибка вида: «mysqldump: Got error: 1146: «Table doesn’t exist» when using LOCK TABLES» или «mysqldump: Got error: 29: «File ‘table.MYD’ not found (Errcode: 23 «Too many open files in system»)» when using LOCK TABLES». Перемещаю я его уже второй раз, так что ошибка мне знакома. Приступим!

На самом деле интернет прямо-таки пестрит сообщениями, что эта ошибка означает нарушение связности InnoDB. Возможно, это так. Но я ещё не видел нарушения связности, выглядящего таким образом :). Да и сообщение про Too many open files in system однозначно говорит о том, что база данных разрослась (жаль только, это сообщение выскакивает гораздо реже). Есть на самом деле 2 метода решения проблемы.

Первый — простой — увеличить количество открытых файлов. Откройте файл /etc/security/limits.conf, поставьте что-то вроде «* hard nofile 8192» и этого должно хватить для большинства пользователей. Хватило и мне в первый переезд сервера. Целостность данных в порядке, а вот работа сайта может на некоторое время прерываться, если вы попытаетесь начать записывать в таблицу, которая сейчас архивируется. Идеальным будет перевести сайт в режим «только для чтения».

Второй — ещё более простой. Всё делается очень просто: архивируются файлы, создаются неработоспособные бэкапы, портится структура БД, всё это делается очень просто. Работоспособность сайта при этом не страдает, опять же! «Что это за способ?», — спросите вы. Спрашивали — отвечаю: это mysqldump —skip-lock-tables.

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

Как устранить ошибку MySQL «Таблица 1146 не существует» на вашем сервере

В нашей роли инженеров службы поддержки для веб-хостов мы управляем серверами с различными службами, такими как Интернет, база данных, почта, панели управления, FTP, и т. д.

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

Часто замечаемая ошибка сервера MySQL — «таблица 1146 не существует».Сегодня мы увидим, что вызывает ошибку «Таблица 1146 не существует» в MySQL и как ее исправить.

Ошибка: таблица mysql.innodb_index_stats не существует.
status: Operation failed

Что вызывает ошибку MySQL 1146 table not exists

Ошибки таблицы MySQL возникают по многим причинам, основные из которых Среди них:

Сбой InnoDB — Когда сервер InnoDB выходит из строя из-за какой-либо загрузки процесса или злоупотреблений со стороны пользователя, или если сервер не был перезагружен должным образом, он может быть поврежден и вызвать появление ошибок таблицы .
Отсутствует файл ibdata в каталоге данных MySQL — InnoDB имеет словарь данных — файл ibdata и файлы журнала, которые имеют решающее значение для работы InnoDB. Если во время миграции или восстановления эти файлы пропадают, это может помешать правильному функционированию таблиц InnoDB.
Неправильно размещенные файлы .frm — В InnoDB таблицы имеют файлы «.frm», которые определяют формат таблицы. Если эти файлы были удалены или были пропущены для копирования в соответствующий каталог базы данных, в таблицах могут отображаться ошибки.
Неправильные разрешения и права собственности на каталог данных MySQL — MySQL имеет каталог данных, обычно «/ var / lib / mysql», в котором хранятся базы данных. Если разрешения и права собственности на этот каталог недостаточны для доступа MySQL к нему, могут возникнуть ошибки.
Поврежденные таблицы или неправильные имена таблиц — Если таблицы базы данных были повреждены из-за неправильного выключения сервера или неполных запросов, или если формат имени таблицы неправильный, может появиться ошибка «1146 таблица не существует» .

[Вы не должны терять сон из-за ошибок сервера. Наши опытные специалисты по поддержке серверов контролируют и обслуживают ваши серверы 24/7/365 и поддерживают их надежность. ]

Как исправить ошибку MySQL «Таблица 1146 не существует»

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

Перезапустите сервер MySQL. — Если ошибка произошла из-за неправильного выключения сервера или ошибок, связанных со службой MySQL, мы перезапускаем службу и проверяем, устраняет ли она проблему.Если служба не запускается должным образом, мы расследуем и исправим ошибку.
Восстановить таблицы — В MySQL есть такие инструменты, как myisamchk, для восстановления поврежденных баз данных и таблиц.
Восстановление из резервной копии — Восстановление резервных копий базы данных — это последнее средство для восстановления рабочего состояния таблиц. Мы всегда настраиваем и поддерживаем резервные копии на серверах наших клиентов в актуальном состоянии, чтобы гарантировать отсутствие потери данных или простоев из-за неожиданных сбоев или ошибок.
Копировать файл ibdata — Если файл «ibdata» отсутствует, мы копируем его из резервной копии и восстанавливаем в каталог данных для MySQL после удаления табличного пространства, чтобы избежать любых повреждений или ошибок.
Восстановление после сбоя InnoDB — В случае, если резервная копия не завершена или файл ibdata также поврежден, мы все равно можем восстановить таблицы с помощью наших экспертных методов восстановления после сбоя. Прочтите сообщение «Восстановление базы данных при сбое», чтобы узнать больше.

[ Используйте свое время, чтобы построить свой бизнес.Мы позаботимся о ваших серверах. Нанять наших экспертов по серверам для решения и предотвращения проблем с сервером. ]

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

Благодаря нашему систематическому подходу к отладке сервисных или других программных ошибок, мы смогли предоставить клиентам отличную поддержку.

Если вы хотите узнать, как избежать простоев ваших клиентов из-за ошибок или других сбоев в обслуживании, мы будем рады поговорить с вами.

var google_conversion_label = «owonCMyG5nEQ0aD71QM»;

Ошибка MySQL 1146 «Таблица не существует» на сервере MySQL, лучший способ ее исправить.

База данных MySQL — это система реляционных баз данных, которая содержит таблицы, эти таблицы формально описаны и содержат данные внутри них. Доступ к данным и их изменение можно получить различными способами, и нет необходимости изменять порядок таблиц для них. Довольно круто, не правда ли? Но иногда повреждение или неправильное обращение с данными может привести к ошибкам.Ошибка SQL 1146 Таблица не существует также является одной из тех распространенных ошибок, которые могут иметь место при обработке MySQL.

Итак, в этом раздаточном материале я подробно расскажу об ошибке 1146, также известной как Таблица не существует, о причине этой ошибки и о том, как разрешить код MySQL 1146. Итак, не теряя времени, давайте начнем.

Почему возникает ошибка 1146?

Есть несколько причин и катализаторов этой ошибки. Некоторые из причин появления ошибки 1146 указаны ниже:

Сбой InnoDB и отсутствующие файлы данных:
Поскольку все мы знаем, что InnoDB является безопасным для транзакций (ACID-совместимым) механизмом хранения для базы данных MySQL, он предлагает множество возможностей, таких как откат, фиксация и восстановление после сбоя для данных базы данных MySQL.InnoDB также подвержен повреждению, поэтому, если с ним не обращаться правильно, существует вероятность сбоя InnoDB. InnoDB работает благодаря файлу ibdata и файлу журнала. Он действует как словарь данных. Если по какой-либо причине эти файлы пропадут, InnoDB не сможет работать, и MySQL покажет вам ошибку 1146.
Неправильные права доступа к каталогу:
MySQL имеет каталог хранения данных, в котором хранится вся база данных. В большинстве случаев путь — «/ var / lib / mysql».Если права владения и доступа неверны и MySQL не может получить доступ к этому пути к каталогу, то будет выдан код MySQL 1146.
Повреждение таблиц данных:
Таблицы базы данных MySQL могут быть повреждены по нескольким причинам, таким как неправильное выключение сервера, неполные запросы, злоупотребление пользователем, неправильные форматы и т. Д. Поэтому, если таблица была повреждена, база данных может показать ошибку «таблица не существует».
.frm файл отсутствует
.frm содержит формат и структуру базы данных. Если каким-либо образом этот файл не будет скопирован в каталог базы данных или будет удален, появится сообщение об ошибке с кодом ошибки, также известной как «Таблица не существует».
You Might Like:
Неустранимая ошибка 823 в базе данных MS SQL Server
Восстановление базы данных MySQL — ошибка при установлении соединения с базой данных

Как устранить ошибку MySQL 1146 «Таблица не существует»?

Чтобы исправить ошибку 1146 в базе данных MySQL, мы можем использовать несколько средств и самостоятельных действий, например:

Восстановить резервную копию:
Это лучшая альтернатива, которую вы должны использовать. Он обязательно воссоздает все потерянные таблицы из базы данных, и код MySQL 1146 также будет решен, но имейте в виду, что должен быть файл резервной копии для восстановления. Так что всегда сохраняйте привычку время от времени создавать резервные копии, это хорошая практика.
Перезагрузите сервер:
Попробуйте перезапустить сервер, если произошло некорректное завершение работы сервера. Есть шанс вернуть его в рабочее состояние и убрав код ошибки.
Ремонт таблиц базы данных:
Вы можете восстановить таблицы базы данных с помощью MySQL CLI.Все, что вам нужно сделать, это выполнить указанные шаги:
Шаг 1. Используя SSH, войдите на сервер.
Шаг 2. В командной строке выполните следующую команду:
mysql -u [имя пользователя] -p
Примечание. Замените имя пользователя своим именем пользователя и удалите квадратные скобки.
Шаг 3. Теперь введите пароль для имени пользователя.
Шаг 4. Снова введите команду:
используйте [имя базы данных];
Примечание: укажите имя базы данных без скобок.
Шаг 5. Теперь выполните следующую команду:
показать таблицы;
Шаг 6. Теперь восстановите таблицу, используя следующие команды:
(a) Проверить таблицы с ошибкой:
контрольная таблица [имя таблицы];
(б) Ремонтные столы:
ремонтный стол [название таблицы];
Шаг 7. Теперь выйдите с помощью команды quit .

Положитесь на сторонние инструменты:
Если по-прежнему возникает ошибка SQL 1146, вам следует обратиться к профессиональному инструменту, а не полагаться на домашних мастеров. Вы можете использовать инструмент восстановления данных MySQL. Это лучший инструмент для восстановления поврежденных таблиц и исправления кода MySQL 1146 «таблица не существует».

Заключение

Итак, это был код MySQL 1146 «таблица не существует».Я также попытался дать вам несколько быстрых и самостоятельных средств устранения этой ошибки. Когда вы сталкиваетесь с такими ошибками, становится действительно сложно и неприятно, потому что такие ошибки могут привести к потере всех ваших ценных данных. Старайтесь изо всех сил, и сохранение резервной копии данных — лучшая из возможных мер предосторожности. Это поможет вам в такой критической ситуации восстановить базу данных MySQL в предыдущем состоянии, а также исправит ошибку SQL 1146. Так что надейтесь на лучшее и сделайте это.

Опубликовано Гауранг Шарад

Я технический компьютер, который любит технологии и любит решать проблемы, связанные с объектами данных.Просмотреть все сообщения Гауранг Шарад

Сообщение навигации

Таблица

mysqldump не существует при использовании LOCK TABLES — справочный центр Plesk

Plesk для Linux

kb: технический

ext: migrator

ABT: Группа A

Симптомы

Сбой дампа базы данных MySQL, размещенной на сервере Plesk:
CONFIG_TEXT: mysqldump: Получена ошибка: 1146: Таблица «» не существует при использовании LOCK TABLES
Резервные копии содержат следующее предупреждение, относящееся к базе данных:
CONFIG_TEXT: WARNING: mysql ‘exampleDB’
Невозможно выполнить SQL: Table ‘exampleDB. ‘не существует в движке. SQL-запрос: ПОКАЗАТЬ ПОЛНЫЕ СТОЛБЦЫ В <ИМЯ ТАБЛИЦЫ>
Перенос завершается с ошибкой:
PLESK_ERROR: Не удалось скопировать содержимое базы данных exampleDB.
Средства миграции попытались выполнить операцию за 3 попытки: Выполнение команды не удалось на исходном сервере «source» (203.0.113.2) с ненулевым кодом выхода. Команда
: MYSQL_PWD = «$ (cat /etc/psa/.psa.shadow)» mysqldump —no-defaults -h localhost -P 3306 -uadmin —quick —quote-names —add-drop-table — -default-character-set = utf8 —set-charset —routines —events exampleDB> / root / plesk_migrator / plesk_migrator-dy0onpkt6k9v4ydtwlfpf507xswuqmyh / db-dumps / exampleDB.sql
код выхода: 2
stdout:
stderr: mysqldump: Получена ошибка: 1932: «Таблица ‘exampleDB.table’ не существует в движке» при использовании LOCK TABLES

Причина

Табличное пространство InnoDB могло быть удалено и воссоздано, но соответствующие файлы . frm таблиц InnoDB из каталога базы данных не были удалены, или файла .frm были перемещены в другую базу данных
Неправильные разрешения и права собственности на файлы таблиц в каталоге данных MySQL
Данные таблицы повреждены

Разрешение

Примечание: Шаги, описанные ниже, охватывают только наиболее распространенные варианты использования Plesk в установках Linux.Эта административная задача может быть выполнена командой профессиональных услуг Plesk от вашего имени. Для получения дополнительной информации свяжитесь с командой профессиональных услуг Plesk.

Подключиться к серверу по SSH
Попробуйте использовать параметр --skip-lock-tables с mysqldump , чтобы пропустить таблицы блокировок, как в примере ниже:
# mysqldump —skip-lock-tables -u -p имя_базы_данных> / root / database_dump.sql
Если описанный выше шаг не помогает, проверьте разрешения и права собственности на файлы таблиц в каталоге данных MySQL для базы данных, для которой не удалось выполнить дамп (например, example_db), это должно быть mysql как для владельца, так и для группы:
- Найти местоположение каталога данных:
  RHEL / CentOS
  # grep datadir /etc/my. cnf
  datadir = / var / lib / mysql
  Debian / Ubuntu
  # grep -iR каталог данных / etc / mysql *
  /etc/mysql/mysql.conf.d / mysqld.cnf: datadir = / var / lib / mysql
- Проверить разрешения:
  # ls -la / var / lib / mysql / example_db /
- Исправить разрешения:
  # chown -R mysql: mysql / var / lib / mysql / example_db /
Если по-прежнему невозможно создать дамп базы данных, попробуйте восстановить таблицу в ошибке, используя собственный инструмент восстановления MySQL:
# plesk db
MYSQL_LIN: mysql> использовать example_db;
mysql> РЕМОНТ ТАБЛИЦЫ ;
Примечание: в приведенной выше команде является заполнителем, и его следует заменить на имя таблицы в сообщении об ошибке
Если проблема не устранена, скорее всего, файл ibdata * не содержит информации о таблице, однако файл осиротевший. Файлы frm по-прежнему сохраняются в файловой системе. Удалите файлы .frm, как показано ниже:
- Убедитесь, что таблица повреждена:
  # plesk db
  MYSQL_LIN: mysql> использовать базу данных example_db;
  mysql> desc <ИМЯ ТАБЛИЦЫ>;
  Если вышеприведенная команда завершилась ошибкой, это означает, что ibdata * не содержит информации о таблице и файл .frm необходимо удалить.
- Перейдите в каталог базы данных / var / lib / mysql / example_db / и переместите .frm файл:
  # cd / var / lib / mysql / example_db /
  # mv .frm /root/.frm
Если ни один из вышеперечисленных шагов не помогает и нет действительных резервных копий для восстановления, единственный доступный вариант для сохранения базы данных — это дамп с опцией innodb_force_recovery: Как исправить случаи повреждения InnoDB для базы данных MySQL? — I. Принудительное восстановление InnoDB

Устранение ошибки MySQL 1146: «Таблица не существует» при резервном копировании

Хотя я не самый большой святой в мире ИТ, когда дело доходит до резервного копирования ([религиозный деятель] — не считая того факта, что OpenVZ имеет простой контейнер -back up function), когда вы выполняете резервное копирование, одна из худших вещей, которые могут произойти (помимо поврежденной резервной копии), — это то, что резервная копия не создается из-за ошибки.Несмотря на то, что в то время, когда я столкнулся с этой проблемой, я не делал резервное копирование, я подумал, что это будет полезно, так как MySQL по-прежнему имеет довольно сильную позицию на рынке баз данных, особенно в системах * nix.

Ошибка
При запуске mysqldump для резервного копирования базы данных вы получаете следующую ошибку:

mysqldump: Получена ошибка: 1146: Таблица ‘db_name.table_name’ не существует при использовании LOCK TABLES

Эта ошибка может быть по любому количеству причин. Я столкнулся с этим, потому что / var был заполнен на 80 +% (очень, очень ужасная ситуация).Хотя очистить / var довольно просто (если вы смелы, запустите эту команду: for i in `find / var / log -type f -iname .log`; do rm -rf $ i; done), этого не произойдет всегда будь таким простым. Настоящая сложность — это когда вы получаете эту ошибку в таблице или базе данных, которые, как вы думали, уже удалили. Добро пожаловать в эту статью.

Проверка ошибок
Чтобы убедиться, что таблица существует и нет проблем, вы можете запустить mysqlcheck:

Код:

  mysqlcheck -u mysql_username -p имя_базы_данных

Это проверит и восстановит любую базу данных и таблицы, переданные в нее.Однако если вы получите что-то вроде:

имя_базы_данных.имя_таблицы
Ошибка: таблица «имя_базы_данных.имя_таблицы» не существует. Статус
: операция не выполнена.

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

mysql -u mysql_user -p
mysql> использовать имя_базы_данных
mysql> показать таблицы; # Если здесь отображается таблица, которая вас огорчила, то вы можете попробовать выполнить для нее запрос SELECT, чтобы увидеть, есть ли там какие-либо данные, но если вы получите сообщение об ошибке, что таблица не существует, тогда…
mysql> удалить таблицу имя_таблицы;
mysql> выйти

Это краткое руководство, но оно определенно может сэкономить вам много времени. Однако всегда рекомендуется создавать ежедневный снимок вашего сервера. В последнее время моя любимая команда — mysqldump -u mysql_user -p имя_базы_данных | bzip2> имя_базы_данных.sql.bz2

BZip2 обычно имеет лучший коэффициент сжатия для ASCII / текстовых данных, который я нашел, и, как правило, лучший период сжатия для моих целей.

Сама по себе эта проблема требует очень много времени, особенно если она не связана с таблицей, которая не была должным образом удалена. Проблемы с разрешениями могут создавать проблемы, так же как и почти полный / var. Часть с / var — вот почему я всегда предлагаю создать отдельный раздел для этого каталога и настроить logwatch, поскольку он будет ежедневно уведомлять вас об информации о разделе (df -h). Если кто-то сталкивается с этой проблемой и / var в порядке, а также нет поврежденных данных, оставьте комментарий, и я сделаю все возможное, чтобы помочь вам.

ИСПРАВЛЕНИЕ для CentOS7 MySQL / MariaDB — ОШИБКА 1146 (42S02) в строке 1: Таблица mysql.global_priv не существует

При использовании старой виртуальной машины с установленным CentOS7 я попытался удалить MySQL v5.5 (ish) и замените ее более поздней версией MariaDB v10.5 для эксперимента с Docker. Пытаясь выровнять типы моей версии БД из-за ограничения в 16 символов для имен пользователей db в более старых версиях MySQL, я столкнулся с: «ОШИБКА 1146 (42S02) в строке 1: Таблица mysql.global_priv не существует. ».

Это было странно, поскольку я даже полностью удалил исходный MySQL с помощью:

(ВАЖНО: НЕ делайте этого, если у вас нет резервных копий существующих данных с помощью mysqldump !! Подробнее здесь: https: // mariadb. com / kb / en / создание резервных копий с mysqldump /)

sudo service mysql stop;
sudo yum удалить mysql;

sudo service mysql stop;

sudo yum удалить mysql;

Затем нам нужно добавить последнюю версию MariaDB, которая работает с CentOS7:

sudo tee /etc/yum.repos.d/mariadb.repo<

[mariadb]

name = MariaDB

baseurl = http://yum.mariadb.org/10.5/centos7-amd64

gpgkey = https: //yum.mariadb.org/RPM-GPG-KEY-MariaDB

gpgcheck = 1

EOF

Затем мы обновляем кеш после добавления MariaDB в yum :

Теперь мы устанавливаем MariaDB из репо, которое мы настроили выше:

sudo yum установить MariaDB-сервер MariaDB-client

Обязательно скажите «да» клавише GPG, например:

. ….
Импорт ключа GPG 0x1BB943DB:
Идентификатор пользователя: «Ключ подписи пакета MariaDB »
…
Это нормально [да / нет]: y

…..

Импорт ключа GPG 0x1BB943DB:

…

Это нормально [да / нет]: да

Теперь нам нужно запустить только что установленную службу mariadb.service, чтобы мы могли протестировать ее и защитить MySQL-совместимую базу данных:

sudo systemctl start mariadb

Если вам нужен mariadb.служба, которая запускается при загрузке, сделайте следующее:

sudo systemctl включить mariadb

Теперь нам нужно убедиться, что мы разрешаем подключение к порту 3306, например:

sudo firewall-cmd —add-service = mysql —permanent
sudo firewall-cmd —reload

sudo firewall-cmd —add-service = mysql —permanent

sudo firewall-cmd —reload

Казалось, все идет нормально, до следующего шага…

sudo mysql_secure_installation

При попытке усилить установку обновления MariaDB с помощью указанной выше команды я получил следующие ошибки:

Включить аутентификацию unix_socket? & # 91; Д / п] Г
ОШИБКА 1146 (42S02) в строке 1: Таблица mysql. global_priv ‘не существует

Включить аутентификацию unix_socket? & # 91; Д / п] Д

ОШИБКА 1146 (42S02) в строке 1: Таблица mysql.global_priv не существует

и / или

Изменить пароль root? & # 91; Д / п] Г
ОШИБКА 1146 (42S02) в строке 1: Таблица mysql.global_priv не существует

Изменить пароль root? & # 91; Y / n] Y

ОШИБКА 1146 (42S02) в строке 1: Таблица mysql.global_priv ‘не существует

Как исправить «ОШИБКА 1146 (42S02) в строке 1: Таблица« mysql.global_priv »не существует»

Я поискал в «обычных местах» очевидное решение. Сначала казалось, что это может быть какая-то проблема с правами локального пользователя Linux CentOS7. Я выполнил несколько побочных квестов и заглянул в кроличью нору разрешений пользователей Linux для пакетов MySQL … но я остановился. Каждый раз, когда вы видите «ошибку в строке 1», это, скорее всего, связано с какой-то проблемой конфигурации, в противном случае более вероятна ошибка «доступ запрещен» или «нет такого пользователя».

Итак, после того как я понял, что у меня голова, я попытался полностью удалить MariaDB, просто чтобы начать с нуля (ВАЖНО: НЕ делайте этого, если вы не использовали mysqldump для своих существующих данных в качестве резервной копии !!)

sudo systemctl stop mariadb
sudo yum удалить mariadb

sudo systemctl stop mariadb

sudo yum удалить mariadb

После удаления MariaDB нам нужно полностью начать заново.На всякий случай мы можем перезагрузиться с:

Пройдя весь процесс установки во второй раз, как и раньше (без добавления репозитория MariaDB, поскольку это уже было сделано один раз), я снова столкнулся с той же проблемой:

Изменить пароль root? & # 91; Д / п] Г
ОШИБКА 1146 (42S02) в строке 1: Таблица mysql. global_priv не существует

Изменить пароль root? & # 91; Y / n] Y

ОШИБКА 1146 (42S02) в строке 1: Таблица mysql.global_priv ‘не существует

ОТКАЗ.

Потратив некоторое время на то, чтобы понять, что пошло не так, я попытался успешно «исправить» ошибку:

И я заметил это примерно на 30% через процесс mysql_upgrade:

………..
mysql.time_zone_name ОК
mysql.time_zone_transition ОК
mysql.time_zone_transition_type ОК
mysql.user ОК
Обновление с версии до MariaDB-10.1
Этап 2/7: Установка использованных механизмов хранения
Проверка таблиц с неизвестным механизмом хранения
Этап 3/7: исправление просмотров
Этап 4/7: запуск mysql_fix_privilege_tables
Этап 5/7: Исправление имен таблиц и баз данных
Этап 6/7: Проверка и обновление таблиц
Обработка баз данных
information_schema
………..

………..

mysql. time_zone_name OK

mysql.time_zone_transition OK

mysql.time_zone_transition_type OK

mysql.user OK

Обновление с версии, предшествующей

, MariaseDB-10000 2/7: Установка используемых механизмов хранения

Проверка таблиц с неизвестным механизмом хранения

Этап 3/7: Исправление представлений

Этап 4/7: Запуск mysql_fix_privilege_tables

Этап 5/7: Исправление имен таблиц и баз данных

Этап 6/7: Проверка и обновление таблиц

Обработка баз данных

information_schema

………..

…. и после этого: Ка-цзин!

sudo mysql_secure_installation
……….
Включить аутентификацию unix_socket? [Да / нет] Да
Включено успешно!
Перезагрузка таблиц привилегий ..
… Успех!

sudo mysql_secure_installation

……….

Включить аутентификацию unix_socket? [Y / n] Y

Активировано успешно!

Перезагрузка таблиц привилегий . .

… Успех!

Мои клиентские инструменты MySQL и доступ через интерфейс командной строки к недавно обновленной и чистой установленной MariaDB работали безупречно.

Мне не приходилось запускать команду mysql_update, чтобы решить проблему с настройкой MySQL / MariaDB для запуска и работы в течение многих лет, но сообщение об ошибке и проблема с отсутствующей таблицей были довольно неясными. Бонусный совет: если вы получаете сообщение «Ошибка доступа запрещена» в течение

sudo mysql_update

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

ОШИБКА 1146 (42S02): Таблица mysql.slow_log не существует

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

  mysql> показать такие переменные, как "% slow%";

+ --------------------- + --------------------------- --------------- +
| Имя_переменной | Значение |
+ --------------------- + --------------------------- --------------- +
| log_slow_queries | ВЫКЛ |
| slow_launch_time | 2 |
| slow_query_log | ВЫКЛ |
| slow_query_log_file | / mysqllog / медленный_лог / медленный_запрос_3306.журнал |
+ --------------------- + --------------------------- --------------- +
4 ряда в наборе (0,00 сек)

Когда вы видите ВЫКЛ, он выключается и сразу открывается.

mysql> установить global slow_query_log = 'on';
ОШИБКА 1146 (42S02): Таблица mysql.slow_log не существует
mysql>
mysql>
mysql> установить global slow_query_log = 1;
ОШИБКА 1146 (42S02): таблица mysql. slow_log не существует
mysql>
mysql> exit

Пока

Неправильно, заходим в проверку библиотеки mysql, такой таблицы нет:

mysql> использовать mysql
База данных изменена
mysql> desc slow_log;
ОШИБКА 1146 (42S02): Таблица mysql.slow_log 'не существует

Таблица mysql.slow_log все еще требуется. Без этой таблицы журнал медленной работы не может быть выведен в ФАЙЛ. Таблица, когда для параметра open log_output установлено значение table, slow.log будет записываться в эту таблицу, но поскольку запись будет влиять на производительность, она обычно записывается в ФАЙЛ, а затем обрабатывается с помощью сценария. . Теперь сообщите об ошибке и попробуйте временно создать эту таблицу, но не забудьте закрыть двоичный файл записи, потому что это двойной мастер:

mysql> установить сеанс sql_log_bin = 0;
Запрос ОК, затронуты 0 строк (0.00 сек)

mysql> использовать mysql
База данных изменена

mysql> СОЗДАТЬ ТАБЛИЦУ `slow_log` (
-> отметка времени` start_time` NOT NULL CURRENT_TIMESTAMP ПО УМОЛЧАНИЮ ПРИ ОБНОВЛЕНИИ CURRENT_TIMESTAMP,
-> `user_host` mediumtext NOT NULL,
->` query_time` time NOT NULL,
-> `lock_time time NOT NULL,
-> `rows_sent` int (11) NOT NULL,
->` rows_examined` int (11) NOT NULL,
-> `db` varchar (512) NOT NULL,
->` last_insert_id` int (11) NOT NULL,
-> `insert_id` int (11) NOT NULL,
->` server_id` int (10) unsigned NOT NULL,
-> `sql_text` mediumtext NOT NULL
->) ENGINE = CSV DEFAULT CHARSET = utf8 COMMENT = 'только медленный журнал';
Запрос ОК, затронуты 0 строк (0. 02 сек)

mysql>
mysql>

Затем откройте журнал медленного журнала

  mysql> установить global slow_query_log = 1;
Запрос выполнен, затронуты 0 строк (0,00 сек)

mysql>
mysql>
mysql> выберите sleep (10), 1 как a;
+ ----------- + --- +
| сон (10) | а |
+ ----------- + --- +
| 0 | 1 |
+ ----------- + --- +
1 ряд в комплекте (10,00 сек)

MySQL>

Затем проверьте, записан ли медленный запрос sql в медленный журнал.

ll slow_queries_3306.log

-rw-rw ---- 1 mysql mysql 0 10 февраля 04:10 slow_queries_3306.log

Оказалось, пусто, почему?

Как устранить ошибки базы данных MySQL в системных таблицах после удаления файлов ibdata в MYSQL 5.7 и выше!

!! ! Не удаляйте больше файлы ibdata на mysql 5.7 !!!

Если вы еще не удалили файл ibdata и вам необходимо уменьшить размер файла ibdata и перейти к innodb для каждой таблицы после обновления до MySQL 5. 7

Проверьте, нет ли проблем с системными таблицами в MySQL, запустив:

mysql_upgrade - форсировать

Не следует сообщать об ошибке, если вы получите какие-либо ошибки, см. Процедуру ниже «Если текущая база данных MySQL уже повреждена » !

Инициализировать каталог данных MySQL и восстановить базы данных

Выполните следующие шаги, чтобы переместить существующие таблицы базы данных для использования в них собственного файла данных ibd.

и инициализируйте текущий файл ibdata, чтобы уменьшить его до исходного размера.

Если возможно, создайте снимок перед продолжением работы в VMware.

Чтобы уменьшить пространство и время, очистите таблицы audit перед запуском процедуры:

https://comm.support.ca.com/kb/how-to-purge-audit-data-in-gateway-9-3-and-newer/kb000074486

Остановить службу шлюза

сервис ssg stop

Остановить репликацию на обоих узлах, если это кластер

mysqladmin стоп-раб

Резервное копирование всех баз данных

mysqldump - все-базы данных> / root / all-db-backup. sql

Не следует сообщать об ошибках, если вы получили какие-либо ошибки, см. Процедуру ниже!

Резервное копирование базы данных ssg отдельно в качестве резервной копии, сделайте то же самое для otk и любых других db, если они установлены:

mysqldump - базы данных ssg | gzip> /root/ssg-db-backup.sql.gz

mysqldump - базы данных otk_db | gzip> /root/otk-db-backup.sql.gz

mysqldump - базы данных mysql> /root/mysql-db-backup.sql

Остановить службу mysql:

служба mysql stop

Удалить каталог данных MySQL:

rm -rf / var / lib / mysql / *

Создайте новый исходный каталог данных MySQL:

mysqld --initialize-insecure --user = mysql

Пример вывода:

2019-08-02T11: 10: 54.362652Z 0 [Предупреждение] TIMESTAMP с неявным значением DEFAULT устарел. Используйте параметр сервера --explicit_defaults_for_timestamp (подробности см. В документации).

2019-08-02T11: 10: 54.365309Z 0 [Предупреждение] Для работы --binlog-format необходимо использовать --log-bin.

2019-08-02T11: 10: 54.677755Z 0 [Предупреждение] InnoDB: созданы новые файлы журнала, LSN = 45790

2019-08-02T11: 10: 54.739585Z 0 [Предупреждение] InnoDB: создание системных таблиц ограничений внешнего ключа.

2019-08-02T11: 10: 54.803364Z 0 [Предупреждение] Существующий UUID не найден, поэтому мы предполагаем, что это первый запуск этого сервера. Создание нового UUID: 32391ce7-b516-11e9-81c9-005056b17f58.

2019-08-02T11: 10: 54.806849Z 0 [Предупреждение] Таблица Gtid не готова к использованию. Таблица mysql.gtid_executed не открыта.

2019-08-02T11: 10: 54.811022Z 0 [Предупреждение] Файл закрытого ключа RSA не найден: /var/lib/mysql//private_key.pem. Некоторые плагины аутентификации работать не будут.

2019-08-02T11: 10: 54.811045Z 0 [Предупреждение] Файл открытого ключа RSA не найден: /var/lib/mysql//public_key. pem. Некоторые плагины аутентификации работать не будут.

2019-08-02T11: 10: 54.811562Z 1 [Предупреждение] [адрес электронной почты защищен] создается с пустым паролем! Пожалуйста, подумайте об отключении опции --initialize-insecure.

Запустить службу MySQL:

служба mysql start

Восстановить резервную копию всех баз данных, созданных ранее:

mysql -u root -p

Введите пароль:

(Примечание: пароль пуст, поскольку мы не устанавливали его во время инициализации)

Если во время восстановления вы получите следующую ошибку:

ОШИБКА 1449 (HY000) в строке 8482: пользователь, указанный как определитель ('xxxxxxxx' @ '%'), не существует

Выполните следующую команду

mysql -root -p -e 'привилегии очистки;'

(Примечание: пароль root для MySQL теперь установлен на исходный из резервной копии)

И снова запускаем восстановление:

mysql -u root -p / root / all-db-backup. sql

(Примечание: если проблема не устранена, остановите и запустите MySQL и попробуйте восстановить снова или запустите mysql и выполните сброс с привилегиями)

Перезапустить службу MySQL:

служба mysql stop

служба mysql start

Запустите mysql_upgrade --force, чтобы проверить состояние базы данных:

mysql_upgrade - форсировать

Проверьте, можете ли вы подключиться к MySQL:

mysql -u корень -p

перезапустить службу шлюза

сервис ssg start

Проверьте ssg и mysqld.журнал на наличие ошибок:

кот /var/log/mysqld.log

cat /opt/SecureSpan/Gateway/node/default/var/logs/ssg_0_0.log

Повторите процедуру на втором узле и перезапустите репликацию.

https://docops.ca.com/ca-api-gateway/9-4/en/install-configure-upgrade/configure-a-gateway-cluster/configuring-cluster-database-replication/restart-replication

Если текущая база данных MySQL уже повреждена:

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

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

В этом случае попробуйте создать защитника, игнорируя ошибки, используя параметр -f.

mysqldump - все-базы данных> /root/all-db-backup.sql -f

Игнорируйте ошибку, например:

mysqldump: Получена ошибка: 1146: Таблица mysql.engine_cost не существует при использовании LOCK TABLES

[[электронная почта защищена] ~] # mysqldump --all-databases> / root / all-db-backup4.sql -f

mysqldump: Получена ошибка: 1146: Таблица mysql.engine_cost не существует при использовании LOCK TABLES

Ошибка: не удалось прочитать информацию о состоянии для таблицы engine_cost ()

Эта ошибка должна возникать только в системных таблицах, а не в таблицах SSG или OTK.

Сделайте резервную копию каждой базы данных отдельно, например SSG, OTK, сделайте то же самое для базы данных mysql на случай возникновения проблем.

Проверить существующие базы данных:

mysql -e "показать базы данных;"

mysqldump --databases ssg> / root / ssg-db-backup.sql

mysqldump - базы данных otk_db> /root/otk-db-backup.sql

mysqldump - базы данных mysql> /root/mysql-db-backup.sql -f

Игнорировать ошибки в резервной копии резервной копии базы данных mysql, например:

mysqldump: Получена ошибка: 1146: Таблица mysql.engine_cost не существует при использовании