|
|
Каталог Голосование Сколько контроллеров в Вашей системе "АВАНГАРДЪ"?
|
Дополнительные параметры restore
Что здесь отсутствует? Правильно, знакомый многим параметр -r. Параметр -r на самом деле не -r[estore], а -r[eplace], т.е. не "восстановить", а "заменить" имеющуюся базу данных. Т.е. если в предыдущем примере команды заменить -c на -r, то существующая база данных e.fdb будет молча удалена. Этого допускать нельзя, потому что по разным причинам восстановление из резервной копии может не состояться, и тогда вы останетесь без оригинальной базы данных и с невосстановимой резервной копией. gbak -c -r e.fbk e.fdb Причина написания такой командной строки кроется в неверном чтении документации по InterBase. Там указано gbak {-c|-r} [options] source dbfile
Что означает - "или -c, или -r", но никак не оба вместе. Тем не менее, лучше такие неоднозначности не устраивать. Кроме того, в Firebird 2.0 параметр -r сам по себе был фактически запрещен, т.к. "убиение" оригинальных баз данных при помощи -r имеет массовый характер. Теперь в Firebird 2.0 параметр -r просто не работает, и вместо него нужно использовать явно -rep (или -replace_database полным текстом), или -r o (-recreate_database overwrite). Таким образом, если требуется сделать резервную копию базы данных и тут же восстановить базу из нее на том же сервере, нужно
если восстановление прошло успешно, то tmp.fdb можно удалить. До этого момента tmp.fdb категорически удалять нельзя. (есть вариации - можно восстановить не в e.fdb, а например в e1.fdb, после успешного восстановления удалить e.fdb, а e1.fdb переименовать в e.fbk) Поборники параметра -r могут сказать, что они или выполняют пункт 2, или вместо пункта 2 копируют базу данных в другой файл (остановив сервер InterBase или Firebird, разумеется). На это могу сказать следующее - все равно использовать -r не надо. Во-первых, он несовместим с Firebird 2.0, и во-вторых, что будет, если переименование или копирование вдруг произойдет с ошибкой? Теперь можно перейти к более подробному описанию параметров restore. -bu n Изменить размер кэша базы данных. По умолчанию кэш базы данных задан в файле конфигурации сервера (firebird.conf, ibconfig), и равен 2048 страниц. Это значение действует для всех баз данных, у которых размер кэша задан неявно. Если вы используете на сервере несколько баз данных, то может потребоваться указать для них разный размер кэша, в зависимости от назначения этих баз. Параметр -bu n позволяет при восстановлении базы данных задать или изменить этот размер. К сожалению, у gbak можно указать значение -bu только больше 0. Если вы обнаружили, что в бэкапе уже "зашито" значение кэша, то "сбросить" его при restore не получится. Для убирания размера кэша в БД придется использовать gfix. -p n Позволяет задать новый размер страницы базы данных. Это единственный способ, которым можно изменить размер страницы БД. На текущий момент можно сказать следующее - если вы посмотрели параметры БД через gstat -h, и увидели, что у базы данных размер страницы 1024 или 2048 байт - рекомендуется сделать backup и restore с указанием размера страницы 4096, 8192 или 16384 байт (если ваша версия сервера поддерживает страницы в 16к). Потому что даже небольшие базы данных с таким небольшим размером страницы имеют явно худшую производительность, чем базы со страницей 4 килобайта и выше. -i Не выполнять создание (активацию) индексов (последняя фаза restore). После восстановления базы данных все индексы в ней останутся отключены (неактивны). Фактически с такой базой данных работать нельзя, т.к. при отключенных индексах Primary key, Foreign key и Unique возможны нарушения целостности данных в таблицах (дублирование первичных ключей и т.д.). если вы восстановили бэкап с опцией -i, индексы можно активировать командой alter index nnn active (для каждого индекса). -k Не создавать shadow, если таковые были созданы в оригинальной базе данных. На самом деле этот параметр не только "не создает" shadow, но и еще удаляет существующие, например в варианте с backup/restore с промежуточным переименованием базы данных. Впрочем, поскольку использовать shadow (программный raid 1) сейчас нет смысла, то и параметр -k можно считать атавизмом. -m Восстановить только метаданные, без данных. Можно использовать как "проверочный" метод целостности резервной копии, или отсутствия проблем в метаданных. -mode <режим> По умолчанию база данных восстанавливается в режиме read_write. Однако, если вам нужно получить базу только для чтения, особенно для размещения ее на CD или DVD, то можно воспользоваться -mode read_only. -use_ По умолчанию базы данных InterBase и Firebird резервируют примерно 30% пространства на страницах данных, для размещения версий при будущих вставках, удалениях или обновлениях записей. Если предполагается запись базы данных на CD или DVD, то лучше базу данных несколько "сжать", указав параметр -use_ при restore (одновременно указав -mode read_only). -o Помогает при некоторых случаях "невосстановимого backup". Тут больше добавить нечего. -n Отключает проверку constraints, если при обычном восстановлении БД оказалось, что логическая целостность оригинальной БД была повреждена (например, из-за битого индекса PK возникли дубликаты первичного ключа). -va В InterBase 7.x, 2007 и 2009 при восстановлении БД из резервной копии параметр -n (см. выше) включен по умолчанию. Это опасно тем, что можно не заметить появление в базе данных нарушений целостности Primary key, Foreign key и Unique в случае повреждения оригинальной базы данных. Поэтому в данных версиях InterBase параметр -va рекомендуется использовать всегда, кроме случаев восстановления "невосстановимого backup". примечание: если требуется восстановить сразу несколько баз из бэкапов, то нужно выполнить команду gbak -c для каждой базы данных отдельно, но ни в коем случае не указывать нечто вроде gbak -c *.gbk *.gdb. Шаблоны и маски в данном случае не работают. -fix Опции -fix_fss_metadata и -fix_fss_data у Firebird 2.5 предназначены для приведения чарсета метаданных (и данных), которые были записаны в некорректной кодировке. Например, при редактировании процедур или триггеров в код могли попасть комментарии или константы в кодировке none, в то время когда они на самом деле являются символами 1251. Если при restore gbak выводит сообщение об ошибке Malformed string то нужно принудительно указать нужную кодировку при помощи указанных опций. После этого в столбцах unicode данные будут записаны корректно. gbak от Firebird 2.5 также может выдавать сообщение gbak:Invalid metadata detected. Use -FIX_FSS_METADATA option. что сигнализирует об аналогичной ситуации, и требует явного указания данной опции с нужной кодировкой. ! Указывать опции -fix... можно ТОЛЬКО ОДИН РАЗ! Если вы сделаете еще раз backup/restore этой же базы данных с этими опциями, то исходные тексты процедур и триггеров БУДУТ ИСПОРЧЕНЫ! Другие параметры gbak - InterBase 2007 и выше-preallocate n весьма странная опция, учитывая то, что она "добивает" базу данных до указанного в n размера страниц, а не аллокирует сразу эти страницы в момент начала restore. Физически это выглядит следующим образом: gbak -c -pr 1300000 db.gbk db.gdb... 1. сначала пройдет restore Причем, с этого момента значение preallocate будет кочевать из базы в бэкап и обратно, до тех пор пока при очередном restore не будет сброшено опцией -pr 0. Если вы делаете restore бэкапа рабочей базы себе на компьютер, то сначала посмотрите gstat -h db.gdb, нет-ли там опции preallocate. Если есть - при restore придется указать -pr 0, иначе сервер развернет базу у вас на компьютере в полный размер preallocate. Services API - restoreЗдесь все то же самое, что и при создании резервной копии: gbak -c -se server:service_mgr d:\e.fbk c:\db\e.fdb Восстановление (например, проверочное) на тот же самый диск, где находится резервная копия, не так опасно, как в случае backup (когда свободное место может кончиться, и резервная копия будет неполной, да еще и база данных может быть повреждена). Но разумеется имеет те же самые проблемы с производительностью, когда восстановление проводится на тот же самый физический диск (поочередные чтение и запись с разных участков диска). Поэтому при восстановлении базы данных из резевной копии рекомендуется использовать разные физические диски. Ошибки при restoreПричины "невосстановимости" резервных копий подробно описаны в статье. Здесь я опишу в общих чертах причины и моменты, когда такие ошибки могут произойти. Если вернуться к описанию последовательности процесса restore, то можно сказать следующее:
Соответственно, при возникновении ошибки вы получаете "неполноценную" базу данных, в которой может быть часть данных, данные без триггеров, данные с процедурами и триггерами, но без части индексов. Если в БД не оказалось процедур или триггеров, то их надо извлечь в виде скрипта из оригинальной базы, и создать в новой БД. Если в БД нет части индексов, то их надо пробовать активировать по очереди (вручную), одновременно корректируя данные, которые препятствуют созданию соответствующего индекса (дубликаты первичного ключа, отсутствующие данные для вторичного ключа, и т.д.) Хуже, если резервная копия оказывается битой сама по себе. В данном случае сможет помочь только инструмент IBBackupSurgeon, который позволяет "вытащить" все что было в резервной копии, полностью или по частям, даже если резервная копия имеет повреждения "посередине". Заключение по restoreНикогда не используйте параметр -r. Всегда используйте -v - это поможет вам определить в случае ошибки, что восстановилось из БД, а что нет. Если во время restore произошла ошибка, то база данных будет в состоянии shutdown, т.е. к ней сможет присоединиться только SYSDBA или владелец БД. Поэтому невозможность для обычных пользователей подсоединиться после restore может служить дополнительным сигналом, что восстановление не прошло нормально, если вы не проверяете логи restore. Как правило, restore по времени занимает в 2-4 раза дольше, чем backup. Это не относится к восстановлению из резервных копий nbackup или online dump. Замечание по Services APIВы уже в курсе, что можно заставить сервер делать backup или restore, через Services API - компонентами или утилитой gbak с опцией -se. Как показывают тесты, как минимум backup через Services API происходит быстрее, чем с использованием локального протокола или tcp. Однако, если потребуется прекратить процесс backup или restore, то
Автоматизация резервного копированияАвтоматизацию резервного копирования можно выполнить как самостоятельно, так и при помощи готовых инструментов. Например, как готовое решение можно использовать наш FBDataGuard Community Edition, который не только защищает базу данных от повреждений, но и может делать резервные копии по расписанию, тестовое восстановление, а также отправку уведомлений по email, и много других полезных вещей. Кроме него, разумеется, есть ряд других инструментов для автоматизации резервного копирования (только), но здесь мы их рассматривать не будем. Что нужно помнить при самостоятельной автоматизации резервного копирования, производимой скриптами, написанными вручную
Итак, у нас есть утилита командной строки gbak, и средства операционной системы для периодического выполнения команд - в Windows это AT или "планировщик заданий", в Unix - cron. Вот пример использования at в Windows: Создаем файл backup.cmd. В файле должна быть одна команда создания резервной копии БД, возможно с параметром, указывающим некое число или день. @echo off set DOW=%1 del d:\backup\data%DOW%.log c:\interbase\bin\gbak -b -g -user sysdba -pass masterkey localhost:c:\db\data.gdb Здесь всего три строки - последние "две" на самом деле одна строка, здесь разбита на две части для облегчения читаемости. Полные пути прописаны для того, чтобы backup.cmd можно было вызвать из любого каталога. Если мы вызовем командный файл как backup.cmd 1 то в результате в каталоге d:\backup будет создана резервная копия data1.gbk и лог data1.log Теперь автоматизируем вызов at. Можно открыть окно командной строки (Пуск, выполнить, cmd), а можно открыть в Панели управления окно планировщика задач и задать нужные параметры интерактивно. Я приведу текст командного файла conf_at.cmd, который автоматически задает для AT создание резервных копий каждый день недели: at %1 /every:M c:\backup.cmd Mon at %1 /every:T c:\backup.cmd Tue at %1 /every:W c:\backup.cmd Wed at %1 /every:Th c:\backup.cmd Thu at %1 /every:F c:\backup.cmd Fri at %1 /every:S c:\backup.cmd Sat at %1 /every:Su c:\backup.cmd Sun Теперь можно вызвать этот командный файл как conf_at 03:00 в результате каждый день недели ровно в 3 часа ночи at будет запускать backup.cmd с соответствующим параметром. И мы в каталоге d:\backup получим т.н. "револьверный" бэкап, то есть по одной резервной копии на каждый день недели, которые будут перезаписываться каждый день. Имена резервных копий будут dataMon.gbk, dataTue.gbk и т.п., что не совсем удобно при просмотре каталога. Вместо Mon, Tue и так далее можно задать номера дней 1, 2, 3..., только главное не забыть, какой день недели у вас соответствует цифре 1. Это самый примитивный вариант, который не обрабатывает ошибки при выполнении резервного копирования. Если вы не будете проверять логи бэкапа, то может оказаться что все резервные копии "дефективные". Поэтому нужно не только регулярно проверять логи, но и периодически делать тестовое восстановление например из самой последней резервной копии. Если backup делается на другой компьютер, то нужно задавать команды AT от имени пользователя, который имеет право доступа к разделяемой папке на этом компьютере. Также можно добавить обработку ошибок в backup.cmd, даже с отправкой email в случае ошибки, но это выходит за рамки статьи. Вот здесь еще один пример автоматизации, более сложный, с тестовым восстановлением, уведомлением по email, обработкой ошибок. Разумеется, в качестве готового решения он не годится, но вполне подходит как пример. Автоматизированное восстановлениена самом деле зло. Что, если автоматический бэкап завершился с ошибкой? Что будет, если при автоматизированном восстановлении возникнет ошибка? Крайний случай - бэкап все время в один и тот же файл, восстановление с ключом -r, да еще и все это на одном логическом диске. Как результат (случившийся в одной компании) - неполный бэкап и убитая база. Соответственно, примеров автоматизированного восстановления не даю. Схематически верный вариант изложен в разделе об опциях restore. Есть вопросы по статье? присылайте на support@ibase.ru. |
Поиск Блог / Новости |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||