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

13

Я использую базу данных MySQL и использую машину с Ubuntu Linux.

Моя база данных с именем db_test, я заметил , что в пути /var/lib/mysql/db_test, есть файлы , суффикс с .frm, .MYD, .MYIкак следующее:

/var/lib/mysql/db_test# ls

cars.frm 
cars.MYD 
cars.MYI

customers.frm
customers.MYD
customers.MYI

departments.frm
departments.MYD
departments.MYI

...

Кажется , каждый .frm, .MYD, .MYIфайлы группы сопоставляются с одной таблицей в базе данных.

У меня есть следующие два вопроса:

Что именно делают три файла?
Если я создам новый каталог, /var/lib/mysql/скажем db_test_2, путь , и скопирую каждый файл из db_test_1каталога в db_test_2, создаст ли он также новую базу данных, db_test_2которая имеет точно такое же содержимое (таблицы), как db_test_1и?

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

дамп базы данных db_test_1отказа
создать новую базу данных db_test_2
затем сбросить db_test_1базу данных обратно в новую базу данных db_test_2?

Если это так, кажется, что перемещение файлов происходит гораздо быстрее, чем использование mysqldumpдля копирования баз данных (или для импорта данных из одной БД в другую БД в MySQL). Есть мнения по этому поводу?

mysql database

— Mellon
источник

5

AFAIR, .frm - файл описания (где описана структура таблицы базы данных), .MYD - файл с данными, .MYI - файл с индексами.
Да, копирование будет намного быстрее. Но есть одна проблема: это не атомарно. При высокой нагрузке скопированные файлы будут несовместимы и, возможно, даже повреждены. Особенно, если вы используете более «умный» движок, такой как InnoDB.

Редактировать: PS Вы можете безопасно скопировать эти файлы, но перед тем, как вы должны остановить MySQL сервер.

— RVS
источник

4

У вас есть инструмент cmd-line, который делает именно это: mysqlhotcopy

Он отлично работает с таблицами myisam, но не с таблицами InnoDb.

Если вы настроили свой сервер с помощью lvm и поместили свой / var / lib / mysql на выделенный том, я рекомендую очень быстро и неблокирующим образом резервировать все ваши базы данных:

mysql -U root -p
  > flush tables with read lock;

Это сбрасывает все ваши таблицы на диск и блокирует любую операцию

  > system "lvcreate -s -L 1G -n lvMysql_snap /dev/vg_myserver/lv_mysql" ;

Необходимо адаптировать к вашей конфигурации, это создает снимок файловой системы вашей базы данных. Это не займет много времени

  > unlock tables;

Это сделано, работа R / W возобновлена.

Теперь вы можете смонтировать / dev / vg_myserver / lvMysql_snap и сделать архив tar своей базы данных!

— Оливье С
источник

Это похоже на быстрый способ сделать резервную копию БД. Но как насчет переключения этого снимка обратно, чтобы он снова стал моей действующей базой данных? Это та часть, о которой я действительно беспокоюсь. Я могу mysqldumpмой БД менее чем за 2 секунды. Восстановление это медленная часть, занимающая 5-10 минут.

— Баттл Буткус

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

— Оливье С.

Что касается Mysqlhotcopy: "Эта утилита является устаревшим в MySQL 5.6.20 и удалены в MySQL 5.7" От: [ dev.mysql.com/doc/refman/5.6/en/mysqlhotcopy.html]

— zeusstl

0

Это будет работать для MyISAM, но не для InnoDB. См. Https://serverfault.com/a/367321/57569.

Из этого ответа о InnoDB:

Если вы думаете только о том, чтобы скопировать файлы .frm и .ibd, значит, вы в опасности. Копирование файлов .frm и .ibd таблицы InnoDB полезно только в том случае, если вы можете гарантировать, что идентификатор табличного пространства файла .ibd точно совпадает с записью идентификатора табличного пространства в метаданных файла ibdata1.

— Петр В. Мёрч
источник