Справочное руководство по MySQL версии 4.1.1-alpha
       

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


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

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

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

Существует еще один способ создать резервную копию базы данных - использовать программу mysqldump или сценарий mysqlhotcopy (см. разделы section 4.8.5 mysqldump, Получение дампов данных и структуры таблицы и see section 4.8.6 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] (see section 4.9.3 Журнал обновлений (update)). В файлах журнала обновлений находится информация, необходимая для того, чтобы повторить в базе данных последовательность изменений, внесенных с момента выполнения mysqldump.


    Если дело дошло до восстановления, сначала надо попробовать восстановить таблицы с помощью REPAIR TABLE или myisamchk -r - это должно сработать в 99,9% случаев. Если myisamchk не даст результата, попробуйте применить следующую процедуру (эти действия применимы только в случае, если MySQL запускался с --log-update (see section 4.9.3 Журнал обновлений (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

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

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

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





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



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



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



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



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


        Содержание раздела