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

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

Команда mysqldump по умолчанию перед записью таблицы в архив считывает ее всю в память. В этом, однако, нет необходимости. Более того, подобная обработка больших таблиц вообще может привести к сбою. Поэтому администратор может воспользоваться опцией --quick, определяющей построчное считывание и запись информации. Чтобы еще больше оптимизировать процесс резервирования, вместо опции --quick можно применить опцию -opt. Она, в свою очередь, активизирует все остальные опции, ускоряющие считывание и резервирование данных.

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

Эффекта, прямо противоположного результатам опции -opt, можно достичь с помощью опции -delayed. Эта опция заставляет команду mysqldump записывать в файл архива операторы INSERT DELAYED вместо операторов INSERT. Опция -delayed оказывается весьма полезной, если при загрузке файла архива в другую базу данных администратор желает уменьшить влияние этой операции на выполнение текущих запросов.

Для уменьшения передаваемого объема информации при копировании базы данных с одного компьютера на другой весьма эффективной является опция -compress. Однако эта опция предназна-

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

% mysqldump --opt samp db mysql --compress -h boa.snake.net samp db

Команда mysqldump имеет и множество других опций. Более детально о них рассказывается в приложении Д, Программы MySQL .

Использование методов прямого копирования

Второй метод резервирования баз данных и таблиц заключается в непосредственном копировании файлов таблиц. Как правило, эта процедура выполняется с помощью таких утилит, как ср, tar или cpio. В примерах этого раздела используется программа ср.

Ранее уже отмечалось, что при использовании методов прямого копирования обязательно нужно убедиться, что таблицы в процессе резервирования не используются другими пользователями. Если сервер изменяет какую-либо таблицу во время копирования, ее копия окажется искаженной.

Лучщий способ обеспечить целостность копий - временно приостановить работу сервера, скопировать файлы и затем снова запустить сервер. Если ситуация не позволяет полностью остановить сервер, обратитесь к материалу главы 13, Поддержка и восстановление баз данных . Попробуйте воспользоваться описанными в ней способами блокировки сервера при проверке таблиц. На копирование файлов накладываются те же ограничения, что и на проверку таблиц, что позволяет использовать для блокировки сервера тот же блокирующий протокол.

Итак, предположим, что работа сервера временно приостановлена либо подлежащие копированию таблицы защищены от изменения. В таком случае резервирование всей базы данных samp db в каталог резервирования {DATADIR в этом примере - каталог данных сервера) выполняется посредством следующих команд:

% cd datadir

% ср -г samp db /usr/archive/mysql

Для резервирования отдельных таблиц введите следующие команды:

% cd DATADIR/samp db

% ср member.* /usr/archive/mysql/samp db % ср score.* /usr/archive/mysql/san5> db

По заверщению процедуры резервирования можно перезапустить сервер (если его работа была приостановлена) или снять блокировку с таблиц (если сервер все же работал).

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

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

Репликация баз данных

Термин репликация может означать как простое копирование базы данных на другой компьютер, так и интерактивное обновление подобной второй базы данных при внесении изменений в основную базу данных. Если необходимо просто скопировать базу данных на другой компьютер, можно воспользоваться одним из описанных выше методов. Первые признаки возможностей интерактивного обновления появились только в версии MySQL 3.23. Пока они находятся на стадии разработки, поэтому заинтересованным администраторам следует внимательно следить за будущими версиями, чтобы не пропустить новые разработки.

Восстановление данных из архивов

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

Если таблицы не утеряны, а лишь повреждены, попытайтесь отладить их с помошью команд myisamchk и issamchk. Вполне вероятно, что проблему можно решить с их помощью, и необходимость в восстановлении файлов архивов отпадет. Процедура отладки таблиц описывается в главе 13, Поддержка и восстановление баз данных . Если же таблицы потеряны или не подлежат отладке, самое время приступить к их восстановлению.

Для восстановления используются два источника информации; файлы архива и журналы обновлений. Первые позволяют восстановить таблицы до состояния, в котором они были в момент вьшолнения резервирования. Однако зачастую таблицы значительно изменяются пользователями между моментами резервирования и сбоя. В такой ситуации эффективными оказываются журналы обновлений, содержащие все последние запросы на внесение изменений. Чтобы восстановить все эти изменения, достаточно запустить запросы журнала обновлений в mysql. (Именно по этой причине администратор должен обязательно включить регистрацию