Меню

Восстановление mysql после отключения питания



Восстановление Mysql после сбоя

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

1. В файле my.cnf установите значение:

2. Перезапустите Mysql:

3. Сделайте дамп всех данных:

4. Создайте новую базу данных:

5. И залейте туда данные:

Теперь все ваши данные продублированы в новой базе данных. Их стоит проверить и, если все хорошо, удалить старую базу данных.

Если сервер не запускается

Если Mysql не запускается попробуйте разные значения опции innodb_force_recovery:

# Попробуйте каждое из значений, пока не запустится Mysql

Если mysqldump не работает

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

# Если не будет работать дамп, стоит попробовать экспорт

Для загрузки данных из файла в новую таблицу используйте:

# Загрузим данные из файла в новую таблицу

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

Что такое индексы в Mysql и как их использовать для оптимизации запросов

Сравнение Vertica и Mysql на практике

Включение и использование логов ошибок, запросов и медленных запросов, бинарного лога для проверки работы MySQL

Check-unused-keys для определения неиспользуемых индексов в базе данных

Повышение скорости работы запросов с MySQL Handlersocket

Ускорение репликации в Mysql 5.6+

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

Правильная настройка Mysql под нагрузки и не только. Обновлено.

Анализ медленных запросов с помощью EXPLAIN

Правильный поиск по тексту в Mysql (full-text search)

Синтаксис и оптимизация Mysql LIMIT

Быстрая альтернатива Mysqldump для больших таблиц без блокировок и выключений.

Оптимизация постраничного вывода данных

Анализ медленных запросов (профилирование) в MySQL с помощью Percona Toolkit

3 примера установки индексов в JOIN запросах

Использование партиций для ускорения сложных удалений

Инструмент для горячих бэкапов MySQL

Сравнение двух движков и когда стоит использовать каждый из них

Примеры использования колоночной базы данных Vertica

И как правильно работать с длительными соединениями в MySQL

Эффективная замена ORDER BY RAND()

Настройка Master-Slave репликации на MySQL за 6 простых шагов

Рекомендации по настройке Redis для оптимизации ресурсов и повышения стабильности на производственном сервере

Настройки для улучшения производительности Postgres

Источник

innodb force recovery и восстановление Mysql из дампа

[mysqld]
innodb_force_recovery = 1

Параметру innodb_force_recovery ставится в соответствие числовое значение от 1 до 6. С увеличением значения MySQL становится менее чувствителен к целостности таблиц и запускается. Именно за счет директивы сервер баз данных становится возможным запустить.

Если в логах сервера баз данных встречаются такие сообщения:

InnoDB: Waiting for the background threads to start

В конфигурационный файл необходимо также добавить

innodb_purge_threads=0

Также лучше сменить порт, на котором работает MySQL

port = 3307

Все три параметра добавляются в /etc/mysql/my.cnf

Сейчас MySQL запущен, но в режиме восстановления в котором изменять таблицы нельзя. Выясним какие таблицы повреждены и сделаем дамп.

Проверяем таблицы и ищем Corrupted

Делаем дамп всех поврежденных таблиц (составляем их список если таблиц много):

mysqldump database_name table_name > database.table.sql

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

Читайте также:  Стандарты питания для детского сада

Снова заходим в /etc/mysql/my.cnf и удаляем директивы innodb_purge_threads=0 и innodb_force_recovery = 1.

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

mysql database Запись опубликована 16.08.2017 автором admin в рубрике MySQL.

Источник

linux-notes.org

Исправляем поврежденные INNODB таблицы

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

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

К сожалению, если не удается InnoDB восстановить себя, -entire- база данных не запустяться. MySQL завершится с сообщением об ошибке и вся ваша база данных будет находиться в автономном режиме. Вы можете попробовать перезапустить базу данных снова и снова, но если процесс ремонта не удается — база данных будет падать и будет переставать запускаться.

Это одна из причин, почему вы всегда должны запустить настройки master/master при использовании InnoDB т.к есть всегда избыточный мастер, если не удается запустить 1-й.

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

Шаг 1.

Добавьте следующую строку в ваш конфигурационный файл /etc/my.cnf:

и вставляем следующую строчку:

Примечание: Если MySQL не запускается, продолжать увеличивать количество innodb_force_recovery, пока вы не получите innodb_force_recovery = 8. Хотя, в основном, доходит до 6:

  1. Mode 1 — не «отваливается» MySQL, когда он видит коррумпированные страницы.
  2. Mode 2 — не запускает фоновые операции.
  3. Mode 3 — Не пытается откатить транзакции.
  4. Mode 4 — не рассчитывает статистику или не применяет сохраненные/буферизированные изменения.
  5. Mode 5 — Не смотрите на log-и отката при запуске.
  6. Mode 6 — Не прокрутки вперед от повтора логов (ib_logfiles) во время пуска.

Так например, если ваш сервер MySQL запускается в режиме 3, но не режим 2, это может быть предположение что «авария» возникла с процессом отката транзакций. Кроме того, следует знать, что режимы 4-6 mysql будет работать в режиме только для чтения.

Я использую 4. Помогает в 99%.

Вы также можете запустить следующую команду чтобы добавить данную опцию в файл /etc/my.cnf автоматически (изменить цифру в поле «mode=»):

Затем, после восстановления поврежденных баз, нужно убрать опцию (вернуть обратно в режим по умолчанию), то вы можете удалить innodb_force_recovery строку с помощью следующей команды:

О sed, я надеюсь расскажу еще, но попозже.

Шаг 2.

База данных теперь будет запускаться, но с параметром innodb_force_recovery,все INSERT-ы и UPDATE-ы будут игнорироваться.

Шаг 3.

Стоит позаботится о бекапах всех таблиц (создать дамп):

Шаг 4.

Выключите сервер базы данных и удалите каталог данных. Запустите «mysql_install_db» для создания таблиц MySQL по умолчанию.

Читайте также:  Hd 4870 нет питания

Шаг 5.

Снимите опцию «innodb_force_recovery» в /etc/my.cnf файл и перезапустите сервер баз данных:

Шаг 6.

Восстановить все из резервной копии.

Повторное создание каталогов базы данных и так же установим основные таблицы в MySQL:

Импортировать все данные обратно (следующая команда может занять много времени, чтобы завершить все и восстановить все данные):

И, наконец, — обновим привилегии MySQL (потому что мы также обновили таблицы MySQL):

Примечание: Для получения наилучших результатов, добавьте «port=8819» (или любой другой из случайных чисел) в /etc/my.cnf перед перезапуском MySQL, а затем запустить «mysqldump» с параметром «—port = 8819».

Если все что выше, не помогло, то стоит попытаться использовать Mysqlcheck:

Восстановить все базы:

Проанализировать все базы:

Оптимизировать все базы:

Восстанавливаем одну базу:

Восстанавливаем один столбец в базе:

Статья «Исправляем поврежденные INNODB таблицы» подошла к завершению. Если есть еще какие-либо соображения по восстановлению поврежденных INNODB таблиц, поделитесь.

Источник

Восстановление MySQL InnoDB после отключения электропитания

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

Первым делом я создал директорию и сделал в нее копию всех файлов баз данных:

Потом открыл файл конфигурации MySQL сервера в текстовом редакторе:

Попытался запустить MySQL сервер (у меня он запустился, если бы не запустился, то можно увеличить значение до 5 или 6 например и попробовать запустить):

Сделал дамп всех баз данных:

Остановил MySQL сервер и закомментировал «innodb_force_recovery» в конфигурации:

Удалил файлы баз данных:

Запустил MySQL сервер и сделал импорт ранее созданного дампа:

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

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

Иногда я полностью удалял MySQL сервер, а потом устанавливал и делал импорт дампа либо резервной копии:

Во время удаления отображался следующий текст:

The following packages will be REMOVED:
libdbd-mysql-perl* libmysqlclient-dev* libmysqlclient20* mysql-client* mysql-client-5.7* mysql-common* mysql-server* mysql-server-5.7*

Источник

Восстановление базы MySQL: подробное руководство

Аварийное завершение работы базы данных MySQL (в России, увы, частой причиной аварийного завершения работы являются отключения электричества), механические повреждения серверного «железа» или обновление CMS – все это может стать причиной повреждения базы данных MySQL.
Если у пользователя нет возможности сделать резервное копирование данных в нужное ему время, то приходится заниматься восстановлением поврежденных или потерянных таблиц. Сделать эту процедуру можно быстрее и проще, если следовать указанным ниже шагам.

Форматы таблиц

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

Читайте также:  Состав рациона питания женщины

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

Общая схема восстановления

Задача по восстановлению базы данных в формате InnoDB решается с помощью опции innodb_force_recovery, которая будет размещена в файле конфигурации MySQL. До того, как она активирована, стоит попробовать воспользоваться командой SELECT . I NTO OUT FILE. Чаще всего она позволяет сохранить данные без каких-либо дополнительных действий.

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

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

Опция innodb_force_recovery прописывается в файле конфигурации MySQL; расположение зависит от того, какая операционная система используется. Путь может иметь вид:

  • /etc/my.cnf;
  • /etc/mysql/my.cnf – если это операционная система Linux.

Уточним, что речь идет о пути по умолчанию – в любом случае поиск файла конфигурации много времени занять не должен.

Важно! Для опции innodb_force_recovery можно прописать несколько значений. В варианте «по умолчанию» она выглядит так: innodb_force_recovery = 0. Любое число вместо нуля (от 1 до 6) позволяет провести восстановление не только собственно таблиц базы данных, но и процессов, которые не были завершены из-за аварийного завершения работы.

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

В файле my.cnf innodb_force_recovery прописывается в раздел [mysqld]. Включение опции потребует перезапуска сервера базы данных MySQL.

Начинать восстановление с помощью этой опции можно лишь при наличии как минимум копий:

  • файлов данных;
  • файлов журнала InnoDB;
  • файла конфигурации БД (my.cnf);
  • файлов таблиц .frm InnoDB.

Работа с опцией innodb_force_recovery

Основное правило работы по восстановлению с использованием innodb_force_recovery – последовательное изменение значений от 1 до 6:

  • при значении innodb_force_recovery = 1 сервер пытается начать работу независимо от того, есть ли поврежденные данные InnoDB или нет;
  • при значении = 2 удается восстановить работу за счет остановки потока команд, которые были частично выполнены или не выполнены;
  • значение = 3 отменяет откат после восстановления поврежденных файлов.

Выставлять значения от 4 до 6 не рекомендуется, особенно если у вас нет большого опыта в работе с БД MySQL: риск потерять данные многократно возрастает. Однако опция innodb_force_recovery = 4/5/6 дает возможность с использованием простых функций делать выборку из таблиц, выявляя поврежденные.

Снижение вероятности повреждения БД

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

Например, в Timeweb можно воспользоваться удобной услугой «Резервная копия по требованию». Запросить бекап можно в любой момент и хранить неограниченный период времени.

Источник