Функции копирования файлов предоставляются операционной системой, поэтому данный способ создания резервных копий является самым быстрым. Таблица dictionary, скопированная в листинге 4.2, содержит более 100000 записей, а файл данных занимает почти 3 Мбайт. Как видите, процедура архивирования такой таблицы заняла менее секунды.
Инструкция BACKUP TABLE самостоятельно заботится о блокировании таблиц и очистке табличных буферов. Это означает, что, в отличие от других методов резервного копирования, дополнительные инструкции не нужны.
Инструкция RESTORE TABLE копирует архивные файлы в каталог базы данных и перестраивает индексы. Таблица не должна существовать на момент восстановления. В случае необходимости можно удалить ее с помощью инструкции DROP TABLE или же вручную удалить табличные файлы.
В листинге 4.3 показаны результаты восстановления таблицы dictionary, резервная копия которой была создана в листинге 4.2. Обратите внимание на то, что процесс восстановления длился гораздо дольше, чем архивирование. Причина в том, что на перестройку индексов уходит много времени.
mysql> RESTORE TABLE dictionary FROM '/tmp/backup';
+-----------------+---------+-----------+--------------------------+
| Table | Op | Msg_type | Msg_text |
+-----------------+---------+-----------+--------------------------+
| test.dictionary | restore | status | ok |
+-----------------+---------+-----------+--------------------------+
1 rows in set (1 min 22.24 sec)
Листинг 4.3. (html, txt)
Если резервные копии создаются вручную, то в архив можно также включить индексный файл. В этом случае в процессе восстановления таблицы индексный файл будет просто скопирован в каталог базы данных. Тем не менее его всегда можно воссоздать с помощью инструкции REPAIR TABLE. Предположим, таблица dictionary была полностью утеряна. Процесс ее восстановления начнем с копирования frm-файла обратно в каталог базы данных. Создать пустые файлы данных и индексов можно с помощью инструкции TRUNCATE TABLE. Затем необходимо скопировать старый файл данных поверх нового. После этого вводится инструкция REPAIR TABLE. В листинге 4.4показано, как программа MySQL обнаруживает расхождение в количестве записей и перестраивает индексы.
mysql> REPAIR TABLE dictionary;
+-----------------+---------+-----------+-----------------------------------------+
| Table | Op | Msg_type | Msg_text |
+-----------------+---------+-----------+-----------------------------------------+
| state | repair | warning | number of rows changed from 0 to 104237 |
| test.state | repair | status | ok |
+-----------------+---------+-----------+-----------------------------------------+
2 rows in set (1 min 25.12 sec)
Листинг 4.4. (html, txt)
Для безопасного создания резервных копий лучше пользоваться специальной программой, чем делать все вручную. С этой целью в дистрибутив MySQL входит Perl-сценарий mysqlhotcopy. В листинге 4.5 показано, как с его помощью создаются копии таблиц привилегий. Команда ls позволяет убедиться, что все файлы, в том числе индексные, на месте.
# mysqlhotcopy mysql /trap/hc
Locked 6 tables in 0 seconds.
Flushed tables(mysql.columns_priv, mysql.db, mysql.func, mysql.host,
mysql.tables_priv, mysql.user) in 0 seconds.
Copying 18 files…
Copying indices for 0 files…
Unlocked tables.
Mysqlhotcopy copied 6 tables |(18 files) in 1 second (1 seconds overall).
# ls /tmp/hc/mysql
columns_priv.MYD db.MYD func.MYD host.MYD tables_priv.MYD user.MYD
columns_priv.MYI db.MYI func.MYI host.MYI tables_priv.MYI user.MYI
columns_priv.frm db.frm func.frm host.frm tables_priv.frm user.frm
Листинг 4.5. (html, txt)
Сценарий mysqlhotcopy блокирует одновременно все таблицы базы данных, после чего очищает табличные буферы и копирует файлы. Сценарий можно запускать во время работы сервера, даже если в этот момент пользователи делают запросы к базе данных. Естественно, пока происходит копирование таблиц, пользователям будет запрещено вносить в них изменения.
Формат табличных файлов понятен только программе MySQL. Если же создать SQL-образы таблиц, то их можно будет перенести в другие СУБД. Кроме того, в некоторых ситуациях полезно просматривать такие SQL-инструкции. Предположим, к примеру, что потеря данных оставалась незамеченной на протяжении нескольких месяцев. Возможно, пользователи удалили какие-то записи и лишь позднее обнаружили, что это было сделано неправильно. Нужно восстановить только удаленные записи, но не известно, когда точно они были удалены. Если резервные копии хранятся в формате SQL, можно просмотреть архивы и поискать, когда последний раз встречались требуемые записи. Недостатком такого способа резервного копирования является то, что процедура восстановления занимает много времени, поскольку программа MySQL вынуждена выполнять каждую инструкцию из архива.
Для создания sql-образа таблицы предназначена утилита mysqldump. Она записывает текст инструкций в поток stdout, поэтому нужно перенаправить результаты ее работы в файл. В листинге 4.6 показан созданный этой утилитой образ таблицы db из базы данных mysql. Утилита была запущена с опцией --opt которая включает режим оптимальных установок.
# MySQL dump
#
# Host: localhost Database: mysql
#
# Server version 4.12.25-log
#
# Table structure for table 'db'
#
DROP TABLE IF EXISTS db;
CREATE TABLE db (
Host char(60) binary NOT NULL default '',
Db char(64) binary NOT NULL default '',
User char(16) binary NOT NULL default '',
Select_priv enum('N', 'Y') NOT NULL default 'N',
Insert_priv enum('N', 'Y') NOT NULL default 'N',
Update_priv enum('N', 'Y') NOT NULL default 'N',
Delete_priv enum('N', 'Y') NOT NULL default 'N',
Create_priv enum('N', 'Y') NOT NULL default 'N',
Drop_priv enum('N', 'Y') NOT NULL default 'N',
Grant_priv enum('N', 'Y') NOT NULL default 'N',
References_priv enum('N', 'Y') NOT NULL default 'N',
