VLDB или NLDB?

KDV, www.ibase.ru, 26.04.2007, последнее изменение – 21.05.2010.

Не понравилось мне как я на "Корпоративных СУБД 2007" выступил. Возможно, слушатели даже скажут, что я нес ахинею. Попробую объяснить, что же именно я хотел в этом выступлении сказать :-)
 

Терминология и RAID

Итак, в InterBase 2007 и Firebird 2.0 есть поддержка VLDB. VLDB – Very Large Database. Словари трактуют этот термин совершенно по разному. Один пишет, что VLDB это база больше 100 гигабайт, другой – больше 1 терабайт. Я бы предложил более простую трактовку: VLDB – это база данных, достигшая такого размера, что затраты по времени на ее резервное копирование и восстановление в случае сбоя превышают регламент, необходимый для нормального функционирования предприятия.

Большинство СУБД допускают резервное копирование online. А вот время восстановления может трактоваться по разному. Я предлагаю ограничиться случаем, когда оригинальная БД повреждена, и должна быть восстановлена из резервной копии целиком.

Если под повреждением иметь в виду повреждение физического диска с БД, то большинство ориентируется на восстановительные возможности RAID. Однако, бывают случаи, когда RAID 10 не может быть восстановлен, а если возможен rebuild массива, то сам процесс rebuild может занять весьма длительное время. Например, Sun StorEdge 3510 FC Array при размере массива 2 терабайта в монопольном режиме делает rebuild в течение 4.5 часов (при цене железки около $40000). Можно выбрать для массива диски поменьше, но даже если это будет 5 дисков по 74 гигабайта, то размер массива raid5 получится ~300 гигабайт, а следовательно время rebuild – около 1.5 часов (с такими дисками стоимость уже на уровне $10000).

Процесс rebuild не обязательно выполнять в монопольном режиме, но массив в этом случае будет работать медленнее, и rebuild будет выполняться дольше. Здесь стоит подумать, какое из двух зол лучше – полный простой на 1.5 часа, или медленная работа в течение 3-4 часов.
  Исходя из надежности SATA и SCSI, хоть они и отличаются по error rate в 100 раз, по статистике сбоев – почти одинаковы. Поэтому, на мой взгляд, для средних предприятий проще организовать raid из мелких дешевых SATA-дисков, чем из мелких дорогих SCSI. Не убедил? Прочитайте абзац выше еще раз. RAID предохранит данные от потери, но не обеспечит как 100% гарантию восстановления, так и максимальную скорость восстановления. Значит, для максимальной скорости резервной копии придется держать или отдельный компьютер, соединенный с сервером 1gb сетью, или диск на hot swap с этой резервной копией.

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

В буквальном смысле, наиболее быстрый вариант восстановления после такого сбоя – запуск резервного сервера или быстрый перенос на сервер резервной копии файла БД.

Если БД Совсем Большая, то о ее копировании не может быть и речи. Например, на среднего пошиба SATA-дисках копирование 13-ти гигабайт (почему 13, а не 15, 20 или 10? такой размер в IB/FB имеет база теста tpc-c с множителем 10) с диска на диск (физических, а не логических), длится 6 минут. Если взять диски дороже и быстрее, то допустим, будет не 6 минут а 3-4 минуты. Если увеличить базу до 100 гигабайт, то уже получится минут 30.

Если говорить о терабайтной БД, то "копирование" будет длиться максимум часов 5, что неприемлемо (при использовании одиночных sata дисков). Поэтому, вопрос о восстановлении резервной копии путем "копирования" для Совсем больших баз данных (SLDB) даже не стоит.
  К этому моменту, надеюсь, вы поняли, что я имею в виду под Non-large database, Very large database и Super large database. Выше терабайта полет уже совсем иной, так что, возможно, называющие базы такого объема VLDB и правы. Но – такие объемы не массовые. А вот объемы на уровне 20-100 гигабайт – это уже явно "средний класс" по количеству. Причем, "копировать" файлы такого размера можно за вполне обозримое время.
   

Как было?

До InterBase 2007 и Firebird 2.0 резервные копии можно было делать двумя способами:

• физическое копирование файла БД
• штатный backup/restore

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

Штатный бэкап (утилитой gbak или через Services API) представляет собой сохранение метаданных и данных БД в файле, примерно как если экспортировать содержимое в виде скриптов "в двоичном виде". Бэкап происходит быстро, например, если использовать ключ -g, то на хорошем raid 20 гигабайт базы сохраняются в 14 гигабайт бэкапа за ~20 минут.

Восстановление базы из бэкапа не может быть осуществлено с такой же скоростью. По сути restore это

1. создание пустой базы данных
2. воссоздание метаданных из бэкапа (без перекомпиляции процедур, view, триггеров и прочего blr)
3. заливка данных в базу из бэкапа
4. создание заново всех индексов БД

Если пункты 1-3 выполняются достаточно быстро (вы можете оценить сами сделав тестовый restore с ключом -i, т. е. не активируя индексы), то пункт 4 иногда занимает столько же, сколько пункты 1-3, и даже больше, если в базе много Foregin Key с часто повторяющимися значениями (ссылка от таблицы с миллионами записей на справочник из 3-10 значений).
  Например, restore упоминаемого выше бэкапа размером 14 гигабайт происходит за ~8 часов. Для сравнения, restore тестовой БД TPC-C размером 13 гигабайт выполняется за 1 час 50 минут (при времени бэкапа ~25 минут), а restore без индексов – 1 час 30 минут. То есть, на создание индексов этой БД уходит всего 20 минут, но

• индексы имеют высокую избирательность (нет fk)
• temp сконфигурирован на отдельный диск
• бэкап находится на отдельном диске
• восстановление идет на еще один отдельный физический диск

Как видите, это катастрофически долго по сравнению с упомянутыми выше 6-ю минутами на копирование файла размером 13 гигабайт.
 

Как стало?

Новые версии InterBase 2007 и Firebird 2.0, вышедшие в ноябре 2006 года, предложили решение данной проблемы. В обоих серверах решение похоже – это страничное копирование БД.

InterBase – Online Dump

Новая опция gbak (см. IB2007UpdateGuide.pdfLINK) позволяет "копировать" базу в онлайне. Результатом является полная копия базы данных, готовая к использованию в любой момент. Повторная операция "копирования" может или перезаписать предыдущий "бэкап" полностью, или записать в файл только измененные с момента последнего дампа страницы.

Для восстановления такого дампа в качестве БД нужно только перевести его из состояния readonly в read-write. Эта же операция "разрывает" связь между дампом и базой, после чего дамп обновлять измененными страницами БД уже невозможно.

Собственно, если дамп делается по сети на резервный сервер, то время восстановления такой БД почти равна нулю – достаточно переключить пользователей на новый сервер, что возможно при организации failover-кластераLINK.

Firebird – NBackup

В Firebird инкрементный бэкап реализуется отдельной утилитой – nbackup (см. описание). Это действительно инкрементный бэкап – первоначально копируется вся БД, это уровень ноль. Затем можно сделать бэкап уровня 1, и в отдельный файл будут помещены только те страницы БД, которые изменились с момента бэкапа уровня 0. Для уровня 2 – то же самое.

Восстановление производится последовательным "наложением" бэкапов уровня 1, 2 и т.д на бэкап уровня 0. Бэкап уровня 0 не является "базой данных" в том смысле, что его невозможно превратить в базу как дамп IB 2007. То есть, время восстановления равно времени "копирования" бэкапа уровня 0 (как минимум) на место БД.
 

Недостатки

Online Dump – файл дампа один, на момент последнего "копирования" БД. Нет инкрементов. Если нужно хранить дампы за определенные интервалы, хранимый объем умножается как размер БД на число дампов.

NBackup – бэкап уровня 0 хоть и является базой, но в комбинации с уровнями 1 и выше – нет, поэтому минимальное время восстановления равно времени воссоздания базы из имеющегося набора уровня 0 и инкрементов уровня 1, 2 и так далее (грубо говоря время воссоздания БД равно времени копированию всех файлов такого бэкапа в один).

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

Достоинства

Противоположные недостаткам:

Online dump – готовая база. Если dump делать на соседний компьютер через сеть 1 гигабит, то базой вполне можно пользоваться в режиме read-only для статических отчетов или аналогичных целей. С дампа можно сделать еще дамп, который тоже будет базой данных.

NBackup – возможность сохранения последних изменений в виде инкрементов уровня 1, 2 и т. д. позволяет оптимально организовать резервное копирование, а также восстанавливать базу на любой требуемый момент времени (при наличии инкремента нужного уровня). В буквальном смысле инкременты можно сохранять раз в месяц, неделю, день и даже каждый час.
 

Объемы изменений

В основном этот вопрос касается nbackup, т. к. инкремент каждого уровня – это отдельный файл. Размер такого файла будет зависеть от интенсивности изменения страниц в БД. То есть, база может и не увеличиваться в объеме, и при этом количество изменяемых страниц может быть от нескольких мегабайт до объема почти всей БД. Здесь нужно ориентироваться только на интервалы времени, между которыми вы будете иметь возможность восстановить состояние БД, и на объем всех резервных копий и инекрементов всех уровней. Если ваша БД имеет объем до 10 гигабайт, то 200гб диска хватит надолго.
 

Обратите внимание

Есть два важных момента при использовании nbackup и online dump:

1. NBackup и Online Dump – это страничное копирование БД. То есть, любые повреждения логических структур – записей, текстов процедур, системных таблиц, индексов и т. п. – будут скопированы на 100%. Поэтому необходимо регулярно проводить штатное тестовое резервное копирование (backup/restore) для выявления подобных повреждений. Хорошей практикой также является регулярное сохранение метаданных в скрипт, а также тестовый backup/restore только метаданных (gbak -b/-c -m). Такие операции выполняются достаточно быстро, и их можно проводить в случае изменения метаданных БД.
2. Как backup, так и любые другие резервные копии должны сохраняться на отдельный физический диск. Не сначала на тот же (упаси Боже), или на другой логический, а именно на отдельный физический диск, даже если у вас база данных находится на крутом raid 5 (см. выше о rebuild time). При этом важно, чтобы скорость записи на такой диск не была ниже скорости чтения с диска, на котором находится БД. Иначе, понятно, время на резервное копирование будет определяться худшим из дисков.

 

Итог

Как видите, теперь резервное копирование больших баз данных в InterBase 2007 и Firebird 2.0 можно выполнять легко и непринужденно, и что важно – за вполне приемлемое время. А приличный дисковый массив можно собрать как из дешевых, так и из дорогих дисков. Только не забывайте копировать ваши резервные копии.
 

Дополнительная литература

• Организация failover-кластера на Windows для InterBaseLINK (то же самое можно использовать для Firebird)
• Тестирование базы данных Firebird размером 1 терабайт
• Тест скорости backup
• Повтор теста скорости backup, с новыми результатами
• Тест скорости restore
• Описание утилиты gbak
• Использование Services API в IBX