Хостинг

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

Данный сценарий можно использовать так, как показано ниже.

mysqlhotcopy -и имя_пользователя -р имяБД размещение_копии

Этот сценарий является сценарием Perl. Если вы используете Unix или подоб­ную ей операционную систему, у вас почти наверняка где-то уже есть исполняе­мый файл perl. В Windows, чтобы использовать Perl, вам нужно установить его. Если установщика Perl для Windows у вас еще нет, загрузите его с узла ActiveState:

www.activestate.com/Products/ActivePerl

Файлы, создаваемые mysqlhotcopy, — это точные копии файлов данных ба­зы данных. Чтобы использовать эти копии, необходимо остановить работу сервера MySQL и заменить файлы данных в каталоге данных MySQL соответствующими файлами-копиями.

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

Это значит, что сначала придется открыть сеанс MySQL. Затем можно ввести команду LOCK TABLES, чтобы блокировать все таблицы, которые планируется резервировать:

lock tables employee read, department read, client read, assignment read, employeeSkills read;

Оператор LOCK TABLES в качестве параметров получает список имен таб­лиц и тип блокировки, который необходимо применить: READ или WRITE. Для резервирования блокировки для чтения обычно бывает достаточно. Это означает, что другие потоки (связывающиеся объекты) могут продолжать читать данные таблиц, но не смогут записывать в них данные, пока резервирование не будет завершено.

Блокировка в таких ситуациях очень важна, поскольку копирование может занять достаточно много времени. В нашем случае будет катастрофой, если, на­пример, после копирования таблицы employee, но еще перед копированием таб­лицы department, кто-то удалит информацию о всех служащих какого-то отдела и информацию о самом отделе. Полученная в результате квпия будет несогласо­ванной, поскольку будет содержать информацию о служащих несуществующего отдела.

Затем следует применить команду FLUSH TABLES: flush tables;

Если необходимо резервировать все базы данных, можно совместить эти два шага, используя команду

flush tables with read lock;

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

По завершении копирования файлов следует, конечно, разблокировать таблицы:

unlock tables;

Эта процедура аналогична сценарию mysqlhotcopy, и точно так же вы можете восстановить базу данных.

Альтернативу только что рассмотренным вариантам составляют два оператора SQL, которые можно использовать для получения тех же результатов. Это — опера­торы BACKUP TABLE и RESTORE TABLE. Соответствующие команды работают только с таблицами MylSAM.

Вы можете создать резервную копию таблицы MylSAM с помощью команды

backup table tl to ‘путь/к/копии‘;

Обратите внимание на то, что в Windows необходимо также указать букву дисковода, например,

backup table tl to ‘с:/путь/к/копии’;

В результате файлы, представляющие указанную таблицу MylSAM, будут ско­пированы в указанное место. Таблица будет заблокирована для чтения, пока будет выполняться копирование.

Можно также указать список таблиц, разделенный запятыми, однако каждая из таких таблиц будет блокироваться и копироваться отдельно, по очереди. Если необходимо получить согласованный набор таблиц, следует сначала применить оператор LOCK TABLES (о том, как это сделать, говорилось в предыдущем раз­деле, “Резервирование и восстановление вручную”).

Чтобы восстановить данные с помощью копии, введите

restore table tl’from ¹c:/tmp’;

Это сработает только в том случае, если восстанавливаемых таблиц в теку­щей базе данных не существует. Если уже имеется таблица с соответствующим именем, перед использованием оператора RESTORE следует применить команду DROP TABLE.

И подчеркнем еще раз, RESTORE работает только с таблицами MylSAM.

Как правило, при восстановлении данных с помощью резервной копии со вре­мени создания копии уже бывают выполнены какие-то новые модификации дан­ных таблиц. Базу данных можно сначала восстановить с помощью одной из про­цедур восстановления, описанных в предыдущих разделах, а затем выполнить по­вторно все операции обновления данных, сделанные со времени резервирования.

Все изменения запоминаются в журнале двоичной регистрации или журнале обновлений. Вот почему журнал двоичной регистрации так важен. Вы можете извлечь список выполненных операций из журнала двоичной регистрации с по­мощью команды

mysqlbinlog logfile > updates.sql

Весьма желательно взглянуть на этот файл перед тем, как повторно запускать соответствующие запросы, — вполне возможно, что какие-то из них вы повторять не пожелаете. Возможно, что какой-то плохо продуманный запрос SQL и привел к тому, что вам пришлось обратиться к резервной копии.

Например, однажды среди множества строк мы обнаружили, что кто-то из программистов ввел

update user set password³‘password” ;

Естественно, что при восстановлении таблицы мы не пожелали снова вво­дить этот запрос и устанавливать для всех пользователей нашей системы пароль password!

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

Проверка таблиц на их целостность является частью системы профилактики таблиц, а также частью процедуры восстановления данных в случае непредвиден­ных обстоятельств, например, в случае отказа системы электропитания.

MySQL предлагает три способа проверки таблиц: с помощью CHECK TABLE, myisamchk (или isamchk) либо mysqlcheck. Затем можно устранить обна­руженные в таблицах проблемы с помощью REPAIR TABLE или с помощью myisamchk (либо isamchk), или mysqlcheck.

Существует ряд факторов, которые следует учитывать при выборе каждого из указанных вариантов. Команды CHECK и REPAIR можно использовать в рамках MySQL, тогда как остальные должны применяться из командной строки. Коман­ды CHECK и REPAIR работают как с таблицами MylSAM, так и с таблицами InnoDB. Сценарий isamchk применим к таблицам ISAM, тогда как myisamchk и mysqlcheck могут использоваться с таблицами MylSAM.

Нельзя применять myisamchk или isamchk к таблицам, которые в тот мо­мент используются. Лучше всего перед использованием этих сценариев завер­шить работу сервера, однако можно ограничиться и блокировкой таблиц. Если использовать указанные сценарии с таблицами, используемыми другими потока­ми MySQL, данные могут быть повреждены. Команды CHECK, REPAIR и mysqlcheck можно использовать и тогда, когда сервер находится в работе, а таблицы — в использовании.

Мы обсудим возможности использования каждого из указанных инструментов.