Поскольку таблицы MySQL хранятся в виде файлов, то резервное копирование
выполняется легко. Чтобы резервная копия была согласованной, выполните на
выбранных таблицах LOCK TABLES, а затем FLUSH TABLES для этих таблиц (см.
разделы Раздел 6.7.2, «Синтаксис команд LOCK TABLES/UNLOCK TABLES» и see Раздел 4.5.3, «Синтаксис команды FLUSH »). При этом
требуется блокировка только на чтение; поэтому другие потоки смогут
продолжать запросы на таблицах в то время, пока будут создаваться копии
файлов из каталога базы данных. Команда FLUSH TABLE обеспечивает гарантию
того, что все активные индексные страницы будут записаны на диск прежде,
чем начнется резервное копирование.
Начиная с 3.23.56 и 4.0.12 BACKUP TABLE не позволит вам перезаписать существующие
файлы, так как это создает потенциальные проблемы в безопасности.
Если есть необходимость провести резервное копирование на уровне SQL, то
можно воспользоваться SELECT INTO OUTFILE или BACKUP TABLE (см. разделы
Раздел 6.4.1, «Синтаксис оператора SELECT» и see Раздел 4.4.2, «Синтаксис BACKUP TABLE »).
Существует еще один способ создать резервную копию базы данных -
использовать программу mysqldump или сценарий mysqlhotcopy (см. разделы
Раздел 4.8.5, «mysqldump, Получение дампов данных и структуры таблицы» и see Раздел 4.8.6, «mysqlhotcopy, Копирование баз данных и таблиц MySQL»). Для этого нужно выполнить следующие действия:
-
Сделать полное резервное копирование баз данных:
shell> mysqldump --tab=/path/to/some/dir --opt --all или shell> mysqlhotcopy database /path/to/some/dir
Можно также просто скопировать табличные файлы (файлы
*.frm,*.MYDи*.MYI) в тот момент, когда сервер не проводит никаких обновлений. Этот метод используется в сценарииmysqlhotcopy. -
Если
mysqldвыполняется, остановить его, и затем запустить с опцией--log-update[=file_name](see Раздел 4.9.3, «Журнал обновлений (update)»). В файлах журнала обновлений находится информация, необходимая для того, чтобы повторить в базе данных последовательность изменений, внесенных с момента выполненияmysqldump.
Если дело дошло до восстановления, сначала надо попробовать восстановить
таблицы с помощью REPAIR TABLE или myisamchk -r - это должно сработать в
99,9% случаев. Если myisamchk не даст результата, попробуйте применить
следующую процедуру (эти действия применимы только в случае, если MySQL
запускался с --log-update (see Раздел 4.9.3, «Журнал обновлений (update)»)):
Восстановите исходный вариант по копии, сделанной в
mysqldump.-
Выполните следующую команду, чтобы повторить обновления из бинарного журнала:
shell> mysqlbinlog hostname-bin.[0-9]* | mysql
Если используется журнал обновлений, то можно применить:
shell> ls -1 -t -r hostname.[0-9]* | xargs cat | mysql
ls используется для того, чтобы расположить все файлы журнала обновлений в
правильном порядке.
Можно проводить избирательное резервное копирование посредством SELECT * INTO OUTFILE 'file_name' FROM tbl_name, а восстановление - при помощи LOAD DATA INFILE 'file_name' REPLACE ... Чтобы избежать повторения записей, в
таблице должен быть первичный или уникальный ключ. Ключевое слово REPLACE
задает замену старых записей новыми в случае, когда новая запись в
значении уникального ключа повторяет старую.
Если в системе, где выполняется резервное копирование, возникают проблемы с производительностью, то решить их можно, установив репликацию и выполняя резервное копирование на подчиненном сервере вместо головного (see Раздел 4.10.1, «Введение»).
Пользователи файловой системы Veritas могут поступить следующим образом:
Из клиента (или Perl) выполнить:
FLUSH TABLES WITH READ LOCK.Из другого shell выполнить:
mount vxfs snapshot.Из первого клиента выполнить:
UNLOCK TABLES.Скопировать файлы из образа.
Демонтировать образ.
