Процесс восстановления mysql занимает больше времени

У меня есть машина Ubuntu 8.04, которая имеет базы данных mysql размером 300 ГБ. Я сбросил все базы данных с помощью команды mysqldump как mysqldump ниже.

 mysqldump -u root -p --all-databases > file.sql 

Теперь, на машине RHEL6, я пытаюсь восстановить базы данных mysql используя:

 mysql -u root -p < file.sql 

Однако вышеприведенная команда, похоже, занимает много времени и, похоже, исполняется навсегда. Через 3 дня, когда я проверю восстановленный размер базы данных, он показывает только 30 ГБ как восстановленный.

Есть ли эффективный способ восстановления базы данных?

Прежде чем отправлять ответ, я хотел бы повторить, что я задал свой вопрос здесь и здесь . Как можно было бы предположить, этот вопрос принадлежит dba SE . Но причина, по которой я размещаю его здесь, состоит в том, что он включает в себя редактирование файла конфигурации в файле /etc/my.cnf .

Первое решение

Отредактируйте /etc/my.cnf чтобы включить приведенные ниже параметры. Расположение файла конфигурации может отличаться в зависимости от дистрибутива Linux. В RHEL6 он присутствует в /etc/my.cnf .

 innodb_doublewrite = 0 innodb_flush_log_at_trx_commit = 0 innodb_support_xa = 0 innodb_locks_unsafe_for_binlog = 1 

Это предложение было дано derobert, и я хотел бы поблагодарить его за предложение этого решения.

Тестирование . Хотя, не так медленно, как команда mysql для восстановления, этот метод все еще занимал значительное время. Команда выполнялась в течение 3 дней и восстановила около 130 ГБ.

Второе решение

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

 SET autocommit=0; SET unique_checks=0; SET foreign_key_checks=0; 

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

 COMMIT; 

Вышеприведенный оператор должен быть последним утверждением файла .sql . На самом деле мы можем найти скрипт для работы с mysqldump .

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

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

Третье решение

У меня есть весь каталог данных mysql поддерживаемый мной. Каталог данных обычно находится в каталоге /var/lib/mysql . В моем случае каталог данных был установлен как отдельный раздел в /mounts/mysql . Я создал резервную копию всей папки, и поэтому я восстановил всю папку на новой машине RHEL6. Перед восстановлением мы должны просто убедиться, что демон mysqld не запущен. Хотя, я восстановил с помощью команды rsync , я хотел убедиться, что права на файл установлены в настоящее время на новой машине RHEL6. Поэтому после восстановления /mounts/mysql в новую систему RHEL6 я выпустил следующую команду.

 chown -R mysql:mysql /mounts/mysql 

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

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

Однако нам нужен файл .sql когда мы пытаемся восстановить базу данных mysql базе данных sql-server или в postgre данных postgre .