Восстановление базы данных MySQL на рабочем сервере приводит к повреждению базы данных

Восстановление базы данных MySQL на рабочем сервере приводит к повреждению базы данных

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

Мы используем MySQL Server версии: 5.7.18-0ubuntu0.16.04.1 (Ubuntu 16.04.2 LTS) и восстанавливаем две таблицы MyISAM с ~350 тыс. записей (в совокупности).

Мы используем следующий скрипт cmd для резервного копирования таблиц из нашей внутренней базы данных и восстановления на удаленном сервере:

"%mysql_path%\mysqldump.exe" --user=root --password="%PWD%" --host=%source% ourdbname --tables table1 table2 | "%mysql_path%\mysql.exe" -uroot --password="%PWD%" --host=%dbtarget% -C ourdbname

Где %%переменные поставляются как часть более крупного пакетного скрипта. По сути, мы передаем вывод дампа в mysql.exe для восстановления на удаленном сервере. Скрипт выполняется на машине с Windows 10, но исходная и целевая базы данных находятся на Linux.

Часть восстановления — это то, где база данных повреждается, что приводит к резкому увеличению использования ЦП сервера БД до 100% на ядро. Единственный способ, который мы нашли для исправления этой проблемы, — это завершить процесс mysql, удалить файлы, .frm, .MYD, .MYIзатем запустить mysql и восстановить таблицы локально (отправить файл mysqldump на сервер с помощью scp и восстановить).

Мы обнаружили, что база данных повреждается только тогда, когда на сайте есть активный трафик. Поэтому мы могли бы отключить сайт (отдельный сервер, работающий на Java, подключающийся через JDBC), запустить скрипт, а затем снова включить сайт, и он будет работать в 100% случаев. Очевидно, что это не идеально, но это единственный способ, которым мы можем это сделать сейчас.

Есть идеи, что может быть причиной этого? Предложения, как обойти это, не останавливая сервер front-end?

решение1

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

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

Итак, использование InnoDB может помочь в этом, но опять же, может и нет. Единственным безопасным вариантом может быть просто остановить front-end сервер. Другой вариант — сделать API для удаленного приложения, который будет безопасно записывать входящие данные в базу данных.

Связанный контент