Чтение онлайн

ЖАНРЫ

MySQL 5.0. Библиотека программиста

Гольцман Виктор

Шрифт:

Расписание для запуска утилиты xcopy целесообразно сделать смещенным на несколько минут относительно расписания «сброса» журналов.

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

Полное резервирование

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

mysqldump –u <Имя пользователя> -p

[Опциональные параметры]

<Копируемые базы данных и таблицы>

> <Путь и имя результирующего файла>

После появления приглашения Enter password (Введите пароль) введите

пароль пользователя.

Выбор опциональных параметров утилиты зависит от типа резервируемых таблиц.

• Для резервного копирования таблиц с типом InnoDB необходимо указать параметр –single-transaction. В процессе резервного копирования пользователи смогут продолжать работу с данными, в том числе вносить изменения, однако эти изменения будут незаметны для программы mysqldump. Таким образом, вы получите согласованную копию баз данных, в которой не будет нарушений целостности данных.

• При резервном копировании таблиц с типом MyISAM необходимо запретить пользователям изменение данных во избежание их рассогласованности. Для этого необходимо указать параметр –lock-all-tables или –lock-tables. Параметр –lock-all-tables устанавливает блокировку для всех таблиц всех баз данных в течение всего времени резервного копирования. Параметр –lock-tables блокирует таблицы той базы данных, которая в данный момент копируется. В последнем случае уменьшается время недоступности каждой таблицы для пользователей, однако отсутствует гарантия непротиворечивости данных, находящихся в разных базах.

Параметры –single-transaction, –lock-all-tables и-lock-tables являются взаимоисключающими: в команде резервного копирования вы можете указать только один из них. Кроме того, поскольку наша стратегия резервного копирования использует двоичные журналы, необходимо указать параметр –flush-logs для «сброса» журналов.

Копируемые объекты вы можете задать одним из следующих способов:

• –all-databases

Необходимо копирование всех баз данных с сервера MySQL (кроме виртуальной базы данных INFORMATION_SCHEMA).

• –databases <Имя базы данных 1> <Имя базы данных 2>… Необходимо скопировать перечисленные базы данных.

• <Имя базы данных> <Имя таблицы 1> <Имя таблицы 2>… Необходимо скопировать перечисленные таблицы указанной базы данных.

Например, команда

mysqldump –u root –p –single-transaction –flush-logs –databases SalesDept FinanceDept > “C:\data\full_backup.sql”

выполняет резервное копирование баз данных SalesDept (Отдел продаж) и FinanceDept (Финансовый отдел) в файл full_backup.sql, находящийся в папке C: \data, а команда

mysqldump –u root –p –lock-tables –flush-logs mysql user db tables_priv columns_priv > «C:\data\users.sql»

выполняет резервное копирование таблиц user, db, tables_priv и columns_priv системной базы данных mysql в файл users.sql, находящийся в папке C: \data. Таблицы в базе данных mysql имеют тип MyISAM, поэтому при резервировании мы указали параметр –lock-tables.

...

Примечание

Открыв созданный файл с помощью программы Блокнот, вы увидите, что данные в нем представлены в виде SQL-команд CREATE DATABASE, CREATE TABLE и INSERT.

Вы можете также организовать полное резервное копирование по расписанию. Для этого необходимо создать задание Windows, выполняющее команду

mysqldump –u <Имя пользователя> -p<Пароль пользователя> [Опциональные параметры]

<Копируемые базы данных и таблицы>

> <Путь и имя результирующего файла>

О том, как создать подобное задание, говорилось в подразделе «Двоичные журналы». Обратите внимание, что в команде mysqldump пароль пользователя должен следовать сразу после ключа -p без пробела. Учитывая риск разглашения пароля, рекомендуется выполнять резервное копирование не от имени пользователя root, а от имени специально зарегистрированного пользователя. Этот пользователь должен обладать следующими привилегиями:

• глобальной привилегией RELOAD;

• привилегией SELECT для всех копируемых объектов;

• в случае резервирования с параметром –lock-all-tables или –lock-tables – дополнительно привилегией LOCK_TABLES для всех баз данных, участвующих в копировании.

После создания файла с резервной копией базы данных необходимо позаботиться

о переносе этого файла на резервный носитель информации. Этот носитель должен быть надежно защищен от несанкционированного доступа.

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

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

Согласно нашей стратегии резервного копирования в случае сбоя восстановление утраченных данных проводится в два этапа:

• вначале нужно восстановить базу данных из резервной копии;

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

Перед началом восстановления данных необходимо запустить сервер MySQL. Если при сбое были повреждены таблицы, управляющие доступом пользователей, при запуске сервера необходимо указать параметр –skip-grant-tables.

Чтобы восстановить базу данных из файла, содержащего полную резервную копию, откроем окно командной строки Windows и выполним команду

mysql –u root –p [<Имя базы данных>] < <Путь и имя файла>

После появления приглашения Enter password (Введите пароль) введем пароль пользователя root.

...

Внимание!

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

Имя базы данных необходимо указывать в том случае, если файл содержит копии отдельных таблиц. Эта база данных должна уже существовать на сервере в момент восстановления данных. Если же база данных отсутствует, ее необходимо предварительно создать с помощью SQL-команды CREATE DATABASE (об этой команде вы узнали в разделе «Создание базы данных» главы 2).

Например, если резервная копия была создана с помощью команды

mysqldump –u root –p –single-transaction –flush-logs –databases SalesDept FinanceDept > «C:\data\full_backup.sql»

то восстановить базы данных SalesDept (Отдел продаж) и FinanceDept (Финансовый отдел) можно с помощью команды

mysql –u root –p < «C:\data\full_backup.sql»

Если резервная копия была создана с помощью команды

mysqldump –u root –p –lock-tables –flush-logs mysql user db tables_priv columns_priv > «C:\data\users.sql»

то при восстановлении необходимо указать имя базы данных, в которую будут помещены воссозданные таблицы user, db, tables_priv и columns_priv:

mysql –u root –p mysql < «C:\data\users.sql»

...

Совет

Поскольку файл с резервной копией содержит данные в виде SQL-команд, вы можете восстанавливать с его помощью отдельные таблицы по своему выбору, просто копируя SQL-команды CREATE TABLE и INSERT в какое-либо клиентское приложение и отправляя их на сервер.

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

mysqlbinlog <Список журналов> | mysql –u root -p

В качестве первого журнала необходимо указать тот журнал, ведение которого началось в момент запуска полного резервного копирования. Определить этот журнал можно по дате создания. Далее перечислим имена всех журналов вплоть до последнего, созданного перед сбоем. Например,:

mysqlbinlog “C:\data\eugene_pc-bin.000117”

“C:\data\eugene_pc-bin.000118”

“C:\data\eugene_pc-bin.000119” | mysql –u root -p

После появления приглашения Enter password (Введите пароль) введите пароль пользователя. Итак, теперь вы знаете, как организовать резервное копирование базы данных и как в случае потери данных восстановить их из резервных копий и двоичных журналов. Далее вы узнаете об устранении другого возможного последствия сбоев – повреждения таблиц.

5.4. Профилактическая проверка и восстановление таблиц

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

Поделиться с друзьями: