СТРАТЕГИИ РЕЗЕРВНОГО КОПИРОВАНИЯ И

ВОССТАНОВЛЕНИЯ В СУБД MySQL

Проценко В., студент 3 курса специальности «Информационные системы»

КГУ им. А.Байтурсынова

Бевз И.А., ст.преподаватель кафедры ИС КГУ им. А.Байтурсынова

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

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

Разработка эффективной стратегии резервирования и восстановления требует тщательного планирования, реализации и тестирования.

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

- Периодическое полное резервное копирование базы данных;

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

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

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

Чтобы включить ведение двоичных журналов, запустим сервер MySQL с параметром –log-bin. Это можно сделать одним из следующих способов:

- Если запускается сервер вручную из командной строки, указывается параметр –log-bin в команде запуска сервера: mysqld-nt –log-bin

- Если сервер MySQL сконфигурирован как сервис Windows и запускается автоматически, или с помощью панели управления, или с помощью MySQL Administrator открывается конфигурационный файл my.ini, находящийся в папке, где установлена программа MySQL, и добавляется параметр log-bin в раздел [mysqld]. Сохраняется файл my.ini. Ведение журналов начинается после перезапуска сервера.

Вместо того чтобы редактировать файл my.ini вручную, можно запустить MySQL Administrator, в левой области главного окна щелкнуть пункт Startup Variables (Параметры запуска), открыть вкладку Log files (Журналы) и установить флажок Binary Logfile (Двоичный журнал), а затем нажать кнопку Apply Changes (Сохранить изменения). Чтобы сервер MySQL начал вести журналы, его необходимо перезапустить.

«Сброс» журналов необходим при выполнении полного резервного копирования, чтобы изменения с момента резервирования отражались в новом файле (старые файлы журналов при этом становятся не нужны). Кроме того, принудительный «сброс» осуществляется перед промежуточным резервным копированием: сервер начнет протоколировать изменения в новом файле, а предыдущие файлы вы скопируете на резервный носитель. Для «сброса» журналов выполняется SQL-команду FLUSH LOGS; либо запускается утилита mysqladmin с параметром flush-logs, выполнив в окне командной строки Windows команду

mysqladmin -u <Имя пользователя> -p flush-logs

Пользователь, от имени которого выполняется «сброс» журналов, должен обладать привилегией RELOAD. Пароль пользователя должен следовать сразу после ключа -p без пробела. Учитывая риск разглашения пароля, рекомендуем выполнять «сброс» журналов не от имени пользователя root, а от имени специально зарегистрированного пользователя, не имеющего никаких привилегий, кроме RELOAD.

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

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

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

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

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

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

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

- вначале восстанавливается база данных из резервной копии;

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

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