Резервное копирование баз данных


Поскольку таблицы MySQL хранятся в виде файлов, то резервное копирование выполняется легко. Чтобы резервная копия была согласованной, выполните на выбранных таблицах LOCK TABLES, а затем FLUSH TABLES для этих таблиц (см. разделы Синтаксис команд LOCK TABLES/UNLOCK TABLES и Синтаксис команды FLUSH). При этом требуется блокировка только на чтение; поэтому другие потоки смогут продолжать запросы на таблицах в то время, пока будут создаваться копии файлов из каталога базы данных. Команда FLUSH TABLE обеспечивает гарантию того, что все активные индексные страницы будут записаны на диск прежде, чем начнется резервное копирование.

Начиная с 3.23.56 и 4.0.12 BACKUP TABLE не позволит вам перезаписать существующие файлы, так как это создает потенциальные проблемы в безопасности.

Если есть необходимость провести резервное копирование на уровне SQL, то можно воспользоваться SELECT INTO OUTFILE или BACKUP TABLE (см. разделы Синтаксис оператора SELECT и Синтаксис BACKUP TABLE).

Существует еще один способ создать резервную копию базы данных - использовать программу mysqldump или сценарий mysqlhotcopy (см. разделы mysqldump, Получение дампов данных и структуры таблицы и mysqlhotcopy, Копирование баз данных и таблиц MySQL). Для этого нужно выполнить следующие действия:

  1. Сделать полное резервное копирование баз данных:

    shell> mysqldump --tab=/path/to/some/dir --opt --all
    
    или
    
    shell> mysqlhotcopy database /path/to/some/dir
    

    Можно также просто скопировать табличные файлы (файлы *.frm, *.MYD и *.MYI) в тот момент, когда сервер не проводит никаких обновлений. Этот метод используется в сценарии mysqlhotcopy.

  2. Если mysqld выполняется, остановить его, и затем запустить с опцией --log-update[=file_name] (Журнал обновлений (update)). В файлах журнала обновлений находится информация, необходимая для того, чтобы повторить в базе данных последовательность изменений, внесенных с момента выполнения mysqldump.

Если дело дошло до восстановления, сначала надо попробовать восстановить таблицы с помощью REPAIR TABLE или myisamchk -r - это должно сработать в 99,9% случаев. Если myisamchk не даст результата, попробуйте применить следующую процедуру (эти действия применимы только в случае, если MySQL запускался с --log-update (Журнал обновлений (update))):

  1. Восстановите исходный вариант по копии, сделанной в mysqldump.

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

    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 задает замену старых записей новыми в случае, когда новая запись в значении уникального ключа повторяет старую.

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

Пользователи файловой системы Veritas могут поступить следующим образом:

  1. Из клиента (или Perl) выполнить: FLUSH TABLES WITH READ LOCK.

  2. Из другого shell выполнить: mount vxfs snapshot.

  3. Из первого клиента выполнить: UNLOCK TABLES.

  4. Скопировать файлы из образа.

  5. Демонтировать образ.

Навигация