Перенос дельта-файла
Модератор: kdv
Перенос дельта-файла
Добрый день
Насколько я понимаю, при проведении нбэкапа основной файл БД блокируется и все изменения пишутся в дельта-файл, который после разблокирования применяется на БД.
Так вот, есть ли какая то возможно сделать так:
1) Основая база блокируется
2) Проделывается бэкап основной базы
3) Проделывается восстановление из полученного бэкапа свежей БД
4) Во время пунктов 2,3 в дельта-файл основной базы продолжают поступать данные
5) Дельта-файл основной базы применяется к восстановленной копии БД
6) Алиасы перебрасываются на восстановленную копию, основная база разблокируется
Дело в том, что моя система работает 24/7, база достаточно большая (уже >30 гигов вроде) в связи с чем отключил SWEEP. Для поддержания базы в нормальном состоянии периодически (раз в 1-2 месяца) далается бэкап-откат, но это занимает достаточно много времени и пропадают ценные данные. Написал скрипт для перекачки данных за период бэкапа-отката, но все это достаточно криво, т.к. таблиц под сотню. Вышеописанный метод был бы спасением, но не знаю как к этому делу подойти.
Насколько я понимаю, при проведении нбэкапа основной файл БД блокируется и все изменения пишутся в дельта-файл, который после разблокирования применяется на БД.
Так вот, есть ли какая то возможно сделать так:
1) Основая база блокируется
2) Проделывается бэкап основной базы
3) Проделывается восстановление из полученного бэкапа свежей БД
4) Во время пунктов 2,3 в дельта-файл основной базы продолжают поступать данные
5) Дельта-файл основной базы применяется к восстановленной копии БД
6) Алиасы перебрасываются на восстановленную копию, основная база разблокируется
Дело в том, что моя система работает 24/7, база достаточно большая (уже >30 гигов вроде) в связи с чем отключил SWEEP. Для поддержания базы в нормальном состоянии периодически (раз в 1-2 месяца) далается бэкап-откат, но это занимает достаточно много времени и пропадают ценные данные. Написал скрипт для перекачки данных за период бэкапа-отката, но все это достаточно криво, т.к. таблиц под сотню. Вышеописанный метод был бы спасением, но не знаю как к этому делу подойти.
-
- Заслуженный разработчик
- Сообщения: 1436
- Зарегистрирован: 15 сен 2005, 09:05
Re: Перенос дельта-файла
"Для поддержания базы в нормальном состоянии" backup-restore не требуется.
Раз уж ты отключил автоматический sweep - делай его вручную по ночам. Или включи обратно, поскольку не понимаешь что творишь.
Раз уж ты отключил автоматический sweep - делай его вручную по ночам. Или включи обратно, поскольку не понимаешь что творишь.
Re: Перенос дельта-файла
Во-первых, цитата 24/7 тебе о чем-нибудь говорит? Во-вторых свип сильно тормозит базу, в третьих Backup-Restore отлично поддерживает базу в нормальном состоянии, в четвертых ты по теме можешь что-нибудь сказать?Dimitry Sibiryakov писал(а):"Для поддержания базы в нормальном состоянии" backup-restore не требуется.
Раз уж ты отключил автоматический sweep - делай его вручную по ночам. Или включи обратно, поскольку не понимаешь что творишь.
Re: Перенос дельта-файла
нбэкапа. исправил в вашем сообщении, а то кто еще чего подумает.при проведении бэкапа основной файл БД блокируется
нет, нельзя. nbackup копирует страницы. а при обычном restore (gbak -c) создается НОВАЯ БАЗА, в которой страницы не имеют ничего общего со старой.Так вот, есть ли какая то возможно сделать так:
Прочитайте подробнее как про backup/restore
http://www.ibase.ru/devinfo/gbak.htm
так и про nbackup
http://www.firebirdsql.org/manual/ru/nbackup-ru.html
и перестаньте фантазировать
значит, "система" сделана не 24/7. Если бы она была так сделана, то при отключении СУБД (а это только одна часть системы), никакие данные не пропадали бы.но это занимает достаточно много времени и пропадают ценные данные.
Кстати, сколько времени у вас идет b/r 30-ти гиг?
переписать систему, чтобы временная недоступность БД по любым причинам не приводила к пропаданию поступающих данных.но не знаю как к этому делу подойти.
Настоящая 24/7 или является "безотказной" (99,999%), что все равно означает 5 минут простоя в год, или является "обычной" (99%), что означает простой 3.5 дня ! в год.
Re: Перенос дельта-файла
и - грубить не надо, и желательно накал нервов поубавить. Систему вы писали, мы тут ни при чем.
Re: Перенос дельта-файла
Спасибо, действительно механизм gbak и nbackup отличается, к тому и задавался вопрос, чтобы узнать возможность/невозможность проведения подобной операции.kdv писал(а):нет, нельзя. nbackup копирует страницы. а при обычном restore (gbak -c) создается НОВАЯ БАЗА, в которой страницы не имеют ничего общего со старой.
Ваша ирония ни к месту ниразу, был задан конкретный вопрос по рабочей теме.kdv писал(а):и перестаньте фантазировать
Причем тут система? Она состоит из десятков различных программ, которые не обязаны заботиться о целостности данных, а наоборот абстрагироваться от таких проблем. И зачем вы мои слова перевираете? Никто не заявлял, что система сделана 24/7, было сказано что она работает 24/7. Программы оттестированы так, чтобы работать 365 дней в году, с учетом работоспособности нижележащих систем, то есть они отвечают только за собственные память/алгоритмы и в меру возможности за оборудование с которым работают, причем тут БД? Может быть делать их устойчивыми к сбоям файловой системы? Операционной системы?kdv писал(а):значит, "система" сделана не 24/7. Если бы она была так сделана, то при отключении СУБД (а это только одна часть системы), никакие данные не пропадали бы.
Хороший вопрос по теме. В сумме все занимает порядка 4-6 часов.kdv писал(а):Кстати, сколько времени у вас идет b/r 30-ти гиг?
Исключено. У системы свои цели, которые она должна выполнять и без заморочек с обеспечением целостности данных.kdv писал(а):переписать систему, чтобы временная недоступность БД по любым причинам не приводила к пропаданию поступающих данных.
Во-первых, где грубость. Во-вторых, я писал лишь часть системы, над ней работали многие люди. В-третьих, есть конкретный технический вопрос касательно БАЗЫ ДАННЫХ, зачем вы и ваш друг приплетаете сюда "систему" и уходите от сути вопроса? Дальше что, скажите что у меня ось хреновая и кроссовки неправильные одеваю?kdv писал(а):и - грубить не надо, и желательно накал нервов поубавить. Систему вы писали, мы тут ни при чем.
Re: Перенос дельта-файла
в таком случае вашим первым вопросом должен был быть "чем отличаются gbak и nbackup". И я бы вас послал читать уже указанные выше статьи.Ваша ирония ни к месту ниразу, был задан конкретный вопрос по рабочей теме.
А ваш "конкретный вопрос" получился типа "можно ли к Жигулям приделать гусеницы от трактора".
неужели? То есть, программа должна считать, что СУБД всегда работает? Ну, это ее право, не спорю. Но получается ли тогда 24/7 комбинация такой программы и СУБД? Нет.Причем тут система? Она состоит из десятков различных программ, которые не обязаны заботиться о целостности данных, а наоборот абстрагироваться от таких проблем.
ну эти программы же работают с БД? Чтобы было понятно, приведу пример:то есть они отвечают только за собственные память/алгоритмы и в меру возможности за оборудование с которым работают, причем тут БД? Может быть делать их устойчивыми к сбоям файловой системы? Операционной системы?
программа работает с БД. Допустим, оператор штампует накладные. Бэкап делается раз в сутки. Вечером raid, на котором база, разваливается так, что базу не починить. Восстанавливаем из бэкапа. И - пропал ввод за день. Кто виноват? Если никто - пусть оператор перевводит накладные за сутки. Если все же программа - значит она должна была вести какой-то локальный лог, чтобы его можно было "накатить" на восстановленную из бэкапа БД.
Еще пример - в моей статье
http://www.ibase.ru/devinfo/sys_failure.htm особенно рекомендую разделы
"Мифические 24 часа в сутки"
"Ввод (импорт) данных из внешних источников" и
"Двухфазный коммит".
Разработчик и администатор должны быть слегка параноиками, и ни в коем случае не оптимистами.
я вам объясняю суть вашего вопроса. Вы упираетесь. Ну тогда в добрый путь. Про gbak и nbackup вы уже знаете, дальнейшие решения проблемы "24/7"- за вами.зачем вы и ваш друг приплетаете сюда "систему" и уходите от сути вопроса?
Re: Перенос дельта-файла
Я имею право не знать каких-то низкоуровневых подробностей СУБД, собственно почему и обратился на этот форум. Вы же не младшеклассник, в состоянии переформулировать вопрос в соответствии с вашими "профессиональными" понятиями. И почему это вопрос о прикреплении шасси одного транспортного средства к другому вызывает у вас такую нервную реакцию?kdv писал(а):в таком случае вашим первым вопросом должен был быть "чем отличаются gbak и nbackup". И я бы вас послал читать уже указанные выше статьи.
А ваш "конкретный вопрос" получился типа "можно ли к Жигулям приделать гусеницы от трактора".
Если декларирована возможность программ работать 24/7 и возможность СУБД работать 24/7 то какие могут быть проблемы? Я еще раз повторяю, программа ни при каких обстоятельствах не обязана отвечать за нижележащие уровни обеспечения, если устойчивость к каким то отказам планируется она указывается-обсуждается-оплачивается отдельно.kdv писал(а):неужели? То есть, программа должна считать, что СУБД всегда работает? Ну, это ее право, не спорю. Но получается ли тогда 24/7 комбинация такой программы и СУБД? Нет.Причем тут система? Она состоит из десятков различных программ, которые не обязаны заботиться о целостности данных, а наоборот абстрагироваться от таких проблем.
Виноват RAID, не понимаю зачем вы подменяете столь очевидные понятия. Ваши душевные переживания это безусловно замечательно, но чем же БД отличается в этом плане от файловой системы? Или от менеджера оперативной памяти? Или от аппаратного обеспечения? Или от наличия питания? Давайте страховаться от каждого чиха, чего уж там. Еще раз повторюсь, у информационной системы свои задачи по обработке данных и работе с оборудованием, которые она обязана решать и в рамках этих задач оставаться максимально устойчивой, что она выполняет на 5+.kdv писал(а):ну эти программы же работают с БД? Чтобы было понятно, приведу пример:
программа работает с БД. Допустим, оператор штампует накладные. Бэкап делается раз в сутки. Вечером raid, на котором база, разваливается так, что базу не починить. Восстанавливаем из бэкапа. И - пропал ввод за день. Кто виноват? блаблабла...
В моем случае никто не декларирует выживаемость данных в форс-мажорных обстоятельствах, потеряем полдня и ладно, для этих целей применено качественное аппаратное обеспечение. Но это действительно должен быть форс-мажор вроде поломки нижележащего уровня типа БД/ОС/HDD/Питания, а не периодический бэкап-откат раз в 2-4 недели.kdv писал(а):Разработчик и администатор должны быть слегка параноиками, и ни в коем случае не оптимистами.
Вам с самого начала следовало написать, что вы не знаете способа обеспечить непрерывность работы БД при бэкап-откате, но вы зачем то упираетесь и учите меня писать ПО.kdv писал(а):я вам объясняю суть вашего вопроса. Вы упираетесь. Ну тогда в добрый путь. Про gbak и nbackup вы уже знаете, дальнейшие решения проблемы "24/7"- за вами.
Что ж, подождем людей, сталкивавшихся с подобными проблемами в реальности, возможно кто-нибудь посоветует что-то полезное по теме.
Re: Перенос дельта-файла
Воспользовавшись случаем хотелось бы поделиться рабочим скриптом по переносу данных из старой базы в новую. Наверное будет полезно во многих случаях, но особенно в таких как мой, когда нужно перекинуть данные за время бэкап-отката в свежевосстановленную базу. Сразу уточню, что ввиду специфики системы почти во всех таблицах используется ключевое поле timestamp, по которому собственно и происходит переброс данных.
execute ibeblock as
declare variable curtime timestamp;
declare variable starttime varchar(20) = '13.06.2012 14:58:30';
/* HROG vars */
declare variable FREQOFFSET double precision;
declare variable PHASEOFFSET double precision;
declare variable INTOSC smallint;
declare variable REF smallint;
declare variable OSCLOCK smallint;
declare variable PLL smallint;
declare variable SYNC smallint;
declare variable TEMP smallint;
begin
DB_NEW = ibec_CreateConnection(__ctFirebird, 'DBName="192.168.1.1:FOODB"; ClientLib=fbclient.dll; User=SYSDBA; Password=masterkey; Names=NONE; SqlDialect=3;');
DB_OLD = ibec_CreateConnection(__ctFirebird, 'DBName="192.168.1.1:OLD_FOODB"; ClientLib=fbclient.dll; User=SYSDBA; Password=masterkey; Names=NONE; SqlDialect=3;');
ibec_UseConnection(DB_OLD );
for execute statement 'select * from "HROG5_1" where curtime>' || '''' || starttime || '''' into :CURTIME, :FREQOFFSET, HASEOFFSET, :INTOSC, :REF, :OSCLOCK, LL, :SYNC, :TEMP do
begin
ibec_UseConnection(DB_NEW);
insert into "HROG5_1" values(:CURTIME, :FREQOFFSET, HASEOFFSET, :INTOSC, :REF, :OSCLOCK, LL, :SYNC, :TEMP);
end
commit;
ibec_CloseConnection(DB_NEW);
ibec_CloseConnection(DB_OLD);
end;
Минус в том, что для каждой таблицы нужно описывать поля и в целом достаточно много писанины получается для всей базы. Буду благодарен если кто подскажет менее трудоемкий и соответственно более красивый путь провести подобную операцию.
execute ibeblock as
declare variable curtime timestamp;
declare variable starttime varchar(20) = '13.06.2012 14:58:30';
/* HROG vars */
declare variable FREQOFFSET double precision;
declare variable PHASEOFFSET double precision;
declare variable INTOSC smallint;
declare variable REF smallint;
declare variable OSCLOCK smallint;
declare variable PLL smallint;
declare variable SYNC smallint;
declare variable TEMP smallint;
begin
DB_NEW = ibec_CreateConnection(__ctFirebird, 'DBName="192.168.1.1:FOODB"; ClientLib=fbclient.dll; User=SYSDBA; Password=masterkey; Names=NONE; SqlDialect=3;');
DB_OLD = ibec_CreateConnection(__ctFirebird, 'DBName="192.168.1.1:OLD_FOODB"; ClientLib=fbclient.dll; User=SYSDBA; Password=masterkey; Names=NONE; SqlDialect=3;');
ibec_UseConnection(DB_OLD );
for execute statement 'select * from "HROG5_1" where curtime>' || '''' || starttime || '''' into :CURTIME, :FREQOFFSET, HASEOFFSET, :INTOSC, :REF, :OSCLOCK, LL, :SYNC, :TEMP do
begin
ibec_UseConnection(DB_NEW);
insert into "HROG5_1" values(:CURTIME, :FREQOFFSET, HASEOFFSET, :INTOSC, :REF, :OSCLOCK, LL, :SYNC, :TEMP);
end
commit;
ibec_CloseConnection(DB_NEW);
ibec_CloseConnection(DB_OLD);
end;
Минус в том, что для каждой таблицы нужно описывать поля и в целом достаточно много писанины получается для всей базы. Буду благодарен если кто подскажет менее трудоемкий и соответственно более красивый путь провести подобную операцию.
Re: Перенос дельта-файла
это не нервное. Хотя вы с вашим тоном и упрямством начинаете меня раздражать. Примените эти ваши свойства к вашей системе, а не в этом бессмысленном диалоге.И почему это вопрос о прикреплении шасси одного транспортного средства к другому вызывает у вас такую нервную реакцию?
я не знаю такого способа для БД, потому что его НЕТ. Как для системы обеспечить "непрерывность", я сказал. Что вам еще нужно, я не знаю.Вам с самого начала следовало написать, что вы не знаете способа обеспечить непрерывность работы БД при бэкап-откате, но вы зачем то упираетесь и учите меня писать ПО.
p.s. еще раз будет что-то про "душевные переживания", "млашеклассник", "нервную реакцию", и т.д. - забаню. Провокаторы мне тут не нужны.
-
- Заслуженный разработчик
- Сообщения: 1436
- Зарегистрирован: 15 сен 2005, 09:05
Re: Перенос дельта-файла
+1kdv писал(а):я не знаю такого способа для БД, потому что его НЕТ.
Простейший двухнодовый кластер решит эту задачу "влёт", но это уже будет "система", а не "БД".