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

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

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

Типы резервных копий баз данных в облачных сервисах

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

± экспорт/дамп базы данных;

± резервное копирование файловой системы;

± резервное копирование журнала транзакций.

ПРИМЕЧАНИЕ

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

Наиболее надежная резервная копия получается, когда вы выполняете экспорт (сбрасываете дамп) всей базы данных. Когда вы осуществляете экспорт базы данных, вы сбрасываете дамп всей схемы базы данных и всех хранящихся в ней данных в один или несколько экспортированных файлов. Затем вы можете создать резервные копии экспортированных файлов. В процессе восстановления вы можете применить экспортированные файлы для восстановления изначальной инсталляции (pristine install) вашего движка базы данных.

Чтобы экспортировать базу данных, например, в SQL Server, выполните следующую команду:

BACKUP DATABASE website to disk = ‘D:\db\website.dump’

В результате вы получите экспортированный файл, который сможете переносить из одной среды SQL Server в другую.

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

Большинство баз данных предлагают опцию экспорта частей баз данных на индивидуальной основе. Например, в MySQL можно сбрасывать дамп таблицы access_log по ночам:

$ mysqldump website access_log > /backups/db/website.dump

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

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

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

Следующее предложение SQL "заморозит" MySQL и даст вам возможность снять моментальный снимок файловой системы, на которой хранится база данных:

FLUSH TABLES WITH READ LOCK

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

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

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

Источник: Риз Дж., Облачные вычисления: Пер. с англ. — СПб.: БХВ-Петербург, 2011. — 288 с.: ил.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете промотать до конца и оставить ответ. Pinging в настоящее время не допускается.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100