Резервирование и копирование баз данных

Администратор должен обязательно резервировать базы данных на случай повреждения или потери данных. Только благодаря резервированию все таблицы могут быть восстановлены до прежнего состояния в случае сбоя в работе системы. Кроме того, не исключен вариант, когда резервирование может оказаться единственным путем отступления, если какой-либо неопытный пользователь случайно выполнит операторы DROP database или drop table. Иногда сбой может произойти по вине собственно администратора MySQL. Так, автору этих лекций известны случаи, когда администраторы разрушали файлы таблиц, пытаясь изменить их с помощью таких редакторов, как vi или emacs. Это далеко не самый лучший способ отредактировать таблицы.

Существует два основных способа резервирования баз данных: использование программы mysqldump и непосредственное копирование файлов базы данных (с помощью команд ср, tar или cpio ). Каждый метод имеет свои преимущества и недостатки.

• Программа mysqldump тесно взаимодействует с сервером MySQL. Методы непосредственного копирования являются внешними по отношению к серверу и требуют проверки, чтобы клиенты не пытались изменить таблицы баз данных в процессе копирования. Эта же проблема возникает при использовании для резервирования баз данных средств резервирования файловой системы. Если в процессе резервирования кто-то из пользователей изменяет таблицы, их файлы окажутся несовместимыми и не подлежащими восстановлению. Разница между резервированием файловой системы и непосредственным копированием файлов заключается в том, что в первом случае имеется возможность управлять расписанием резервирования.

• Программа mysqldump медленней резервирует данные, чем методы непосредственного копирования.

• Программа mysqldump создает простые текстовые файлы, которые можно легко переносить на другие компьютеры, даже с другой аппаратной архитектурой. Копируемые вручную файлы не могут переноситься на другие компьютеры, если, конечно, не используется специальный формат хранения MylSAM. ISAM-таблицы могут копироваться только между компьютерами с подобной архитектурой. Так, например, копирование файлов из системы Solaris на компьютере с процессором SPARC в систему Solaris на компьютер с процессором SPARC будет успешным, чего нельзя сказать о копировании файлов из системы Solaris на компьютере с процессором SPARC в систему Solaris на компьютер с процессором Intel. Впервые появившийся в версии MySQL 3.23 формат хранения MylSAM решает эту проблему, поскольку является независимым от архитектуры компьютера. Соответственно, скопированные файлы можно легко переносить на другой компьютер с любой архитектурой в одном из двух случаев: на втором компьютере также запущена СУБД MySQL версии 3.23 и более поздней либо файлы таблиц представлены в формате MylSAM, а не ISAM.

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

• Регулярно выполняйте резервирование. На этапе планирования разработайте расписание и четко его придерживайтесь.

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

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

• Используйте постоянную и легко понятную схему присвоения имен файлам архива. Имена типа backupl, backup2 и т.д. не несут никакой смысловой нагрузки, и когда приходит время восстанавливать информацию, много времени тратится на изучение их содержимого. Гораздо эффективней присваивать архивным файлам имена баз данных и дат резервирования. Например:

  % mysqldump samp_db > /usr/archives/mysql/samp_db.1999-10-02 
  % mysqldump menagerie > /usr/archives/mysql/menagerie.1999-10-02

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

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

• Размещайте файлы архивов на отдельном диске. Это снизит вероятность переполнения этими файлами диска, содержащего каталог данных.

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