Перенос дельта-файла

Методы, механизмы и инструментарий для репликации

Модератор: kdv

Ответить
Frattello
Сообщения: 10
Зарегистрирован: 31 авг 2012, 06:12

Перенос дельта-файла

Сообщение Frattello » 05 сен 2012, 12:44

Добрый день

Насколько я понимаю, при проведении нбэкапа основной файл БД блокируется и все изменения пишутся в дельта-файл, который после разблокирования применяется на БД.
Так вот, есть ли какая то возможно сделать так:
1) Основая база блокируется
2) Проделывается бэкап основной базы
3) Проделывается восстановление из полученного бэкапа свежей БД
4) Во время пунктов 2,3 в дельта-файл основной базы продолжают поступать данные
5) Дельта-файл основной базы применяется к восстановленной копии БД
6) Алиасы перебрасываются на восстановленную копию, основная база разблокируется

Дело в том, что моя система работает 24/7, база достаточно большая (уже >30 гигов вроде) в связи с чем отключил SWEEP. Для поддержания базы в нормальном состоянии периодически (раз в 1-2 месяца) далается бэкап-откат, но это занимает достаточно много времени и пропадают ценные данные. Написал скрипт для перекачки данных за период бэкапа-отката, но все это достаточно криво, т.к. таблиц под сотню. Вышеописанный метод был бы спасением, но не знаю как к этому делу подойти.

Dimitry Sibiryakov
Заслуженный разработчик
Сообщения: 1436
Зарегистрирован: 15 сен 2005, 09:05

Re: Перенос дельта-файла

Сообщение Dimitry Sibiryakov » 05 сен 2012, 15:09

"Для поддержания базы в нормальном состоянии" backup-restore не требуется.
Раз уж ты отключил автоматический sweep - делай его вручную по ночам. Или включи обратно, поскольку не понимаешь что творишь.

Frattello
Сообщения: 10
Зарегистрирован: 31 авг 2012, 06:12

Re: Перенос дельта-файла

Сообщение Frattello » 05 сен 2012, 15:56

Dimitry Sibiryakov писал(а):"Для поддержания базы в нормальном состоянии" backup-restore не требуется.
Раз уж ты отключил автоматический sweep - делай его вручную по ночам. Или включи обратно, поскольку не понимаешь что творишь.
Во-первых, цитата 24/7 тебе о чем-нибудь говорит? Во-вторых свип сильно тормозит базу, в третьих Backup-Restore отлично поддерживает базу в нормальном состоянии, в четвертых ты по теме можешь что-нибудь сказать?

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Re: Перенос дельта-файла

Сообщение kdv » 05 сен 2012, 18:45

при проведении бэкапа основной файл БД блокируется
нбэкапа. исправил в вашем сообщении, а то кто еще чего подумает.
Так вот, есть ли какая то возможно сделать так:
нет, нельзя. 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 дня ! в год.

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Re: Перенос дельта-файла

Сообщение kdv » 05 сен 2012, 18:47

и - грубить не надо, и желательно накал нервов поубавить. Систему вы писали, мы тут ни при чем.

Frattello
Сообщения: 10
Зарегистрирован: 31 авг 2012, 06:12

Re: Перенос дельта-файла

Сообщение Frattello » 06 сен 2012, 07:11

kdv писал(а):нет, нельзя. nbackup копирует страницы. а при обычном restore (gbak -c) создается НОВАЯ БАЗА, в которой страницы не имеют ничего общего со старой.
Спасибо, действительно механизм gbak и nbackup отличается, к тому и задавался вопрос, чтобы узнать возможность/невозможность проведения подобной операции.
kdv писал(а):и перестаньте фантазировать :)
Ваша ирония ни к месту ниразу, был задан конкретный вопрос по рабочей теме.
kdv писал(а):значит, "система" сделана не 24/7. Если бы она была так сделана, то при отключении СУБД (а это только одна часть системы), никакие данные не пропадали бы.
Причем тут система? Она состоит из десятков различных программ, которые не обязаны заботиться о целостности данных, а наоборот абстрагироваться от таких проблем. И зачем вы мои слова перевираете? Никто не заявлял, что система сделана 24/7, было сказано что она работает 24/7. Программы оттестированы так, чтобы работать 365 дней в году, с учетом работоспособности нижележащих систем, то есть они отвечают только за собственные память/алгоритмы и в меру возможности за оборудование с которым работают, причем тут БД? Может быть делать их устойчивыми к сбоям файловой системы? Операционной системы?
kdv писал(а):Кстати, сколько времени у вас идет b/r 30-ти гиг?
Хороший вопрос по теме. В сумме все занимает порядка 4-6 часов.
kdv писал(а):переписать систему, чтобы временная недоступность БД по любым причинам не приводила к пропаданию поступающих данных.
Исключено. У системы свои цели, которые она должна выполнять и без заморочек с обеспечением целостности данных.
kdv писал(а):и - грубить не надо, и желательно накал нервов поубавить. Систему вы писали, мы тут ни при чем.
Во-первых, где грубость. Во-вторых, я писал лишь часть системы, над ней работали многие люди. В-третьих, есть конкретный технический вопрос касательно БАЗЫ ДАННЫХ, зачем вы и ваш друг приплетаете сюда "систему" и уходите от сути вопроса? Дальше что, скажите что у меня ось хреновая и кроссовки неправильные одеваю?

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Re: Перенос дельта-файла

Сообщение kdv » 06 сен 2012, 19:51

Ваша ирония ни к месту ниразу, был задан конкретный вопрос по рабочей теме.
в таком случае вашим первым вопросом должен был быть "чем отличаются gbak и nbackup". И я бы вас послал читать уже указанные выше статьи.
А ваш "конкретный вопрос" получился типа "можно ли к Жигулям приделать гусеницы от трактора".
Причем тут система? Она состоит из десятков различных программ, которые не обязаны заботиться о целостности данных, а наоборот абстрагироваться от таких проблем.
неужели? То есть, программа должна считать, что СУБД всегда работает? Ну, это ее право, не спорю. Но получается ли тогда 24/7 комбинация такой программы и СУБД? Нет.
то есть они отвечают только за собственные память/алгоритмы и в меру возможности за оборудование с которым работают, причем тут БД? Может быть делать их устойчивыми к сбоям файловой системы? Операционной системы?
ну эти программы же работают с БД? Чтобы было понятно, приведу пример:
программа работает с БД. Допустим, оператор штампует накладные. Бэкап делается раз в сутки. Вечером raid, на котором база, разваливается так, что базу не починить. Восстанавливаем из бэкапа. И - пропал ввод за день. Кто виноват? Если никто - пусть оператор перевводит накладные за сутки. Если все же программа - значит она должна была вести какой-то локальный лог, чтобы его можно было "накатить" на восстановленную из бэкапа БД.
Еще пример - в моей статье
http://www.ibase.ru/devinfo/sys_failure.htm особенно рекомендую разделы
"Мифические 24 часа в сутки"
"Ввод (импорт) данных из внешних источников" и
"Двухфазный коммит".

Разработчик и администатор должны быть слегка параноиками, и ни в коем случае не оптимистами.
зачем вы и ваш друг приплетаете сюда "систему" и уходите от сути вопроса?
я вам объясняю суть вашего вопроса. Вы упираетесь. Ну тогда в добрый путь. Про gbak и nbackup вы уже знаете, дальнейшие решения проблемы "24/7"- за вами.

Frattello
Сообщения: 10
Зарегистрирован: 31 авг 2012, 06:12

Re: Перенос дельта-файла

Сообщение Frattello » 07 сен 2012, 09:57

kdv писал(а):в таком случае вашим первым вопросом должен был быть "чем отличаются gbak и nbackup". И я бы вас послал читать уже указанные выше статьи.
А ваш "конкретный вопрос" получился типа "можно ли к Жигулям приделать гусеницы от трактора".
Я имею право не знать каких-то низкоуровневых подробностей СУБД, собственно почему и обратился на этот форум. Вы же не младшеклассник, в состоянии переформулировать вопрос в соответствии с вашими "профессиональными" понятиями. И почему это вопрос о прикреплении шасси одного транспортного средства к другому вызывает у вас такую нервную реакцию?
kdv писал(а):
Причем тут система? Она состоит из десятков различных программ, которые не обязаны заботиться о целостности данных, а наоборот абстрагироваться от таких проблем.
неужели? То есть, программа должна считать, что СУБД всегда работает? Ну, это ее право, не спорю. Но получается ли тогда 24/7 комбинация такой программы и СУБД? Нет.
Если декларирована возможность программ работать 24/7 и возможность СУБД работать 24/7 то какие могут быть проблемы? Я еще раз повторяю, программа ни при каких обстоятельствах не обязана отвечать за нижележащие уровни обеспечения, если устойчивость к каким то отказам планируется она указывается-обсуждается-оплачивается отдельно.
kdv писал(а):ну эти программы же работают с БД? Чтобы было понятно, приведу пример:
программа работает с БД. Допустим, оператор штампует накладные. Бэкап делается раз в сутки. Вечером raid, на котором база, разваливается так, что базу не починить. Восстанавливаем из бэкапа. И - пропал ввод за день. Кто виноват? блаблабла...
Виноват RAID, не понимаю зачем вы подменяете столь очевидные понятия. Ваши душевные переживания это безусловно замечательно, но чем же БД отличается в этом плане от файловой системы? Или от менеджера оперативной памяти? Или от аппаратного обеспечения? Или от наличия питания? Давайте страховаться от каждого чиха, чего уж там. Еще раз повторюсь, у информационной системы свои задачи по обработке данных и работе с оборудованием, которые она обязана решать и в рамках этих задач оставаться максимально устойчивой, что она выполняет на 5+.
kdv писал(а):Разработчик и администатор должны быть слегка параноиками, и ни в коем случае не оптимистами.
В моем случае никто не декларирует выживаемость данных в форс-мажорных обстоятельствах, потеряем полдня и ладно, для этих целей применено качественное аппаратное обеспечение. Но это действительно должен быть форс-мажор вроде поломки нижележащего уровня типа БД/ОС/HDD/Питания, а не периодический бэкап-откат раз в 2-4 недели.
kdv писал(а):я вам объясняю суть вашего вопроса. Вы упираетесь. Ну тогда в добрый путь. Про gbak и nbackup вы уже знаете, дальнейшие решения проблемы "24/7"- за вами.
Вам с самого начала следовало написать, что вы не знаете способа обеспечить непрерывность работы БД при бэкап-откате, но вы зачем то упираетесь и учите меня писать ПО.

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

Frattello
Сообщения: 10
Зарегистрирован: 31 авг 2012, 06:12

Re: Перенос дельта-файла

Сообщение Frattello » 07 сен 2012, 10:05

Воспользовавшись случаем хотелось бы поделиться рабочим скриптом по переносу данных из старой базы в новую. Наверное будет полезно во многих случаях, но особенно в таких как мой, когда нужно перекинуть данные за время бэкап-отката в свежевосстановленную базу. Сразу уточню, что ввиду специфики системы почти во всех таблицах используется ключевое поле 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, :PHASEOFFSET, :INTOSC, :REF, :OSCLOCK, :PLL, :SYNC, :TEMP do
begin
ibec_UseConnection(DB_NEW);
insert into "HROG5_1" values(:CURTIME, :FREQOFFSET, :PHASEOFFSET, :INTOSC, :REF, :OSCLOCK, :PLL, :SYNC, :TEMP);
end
commit;
ibec_CloseConnection(DB_NEW);
ibec_CloseConnection(DB_OLD);
end;

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

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Re: Перенос дельта-файла

Сообщение kdv » 07 сен 2012, 13:06

И почему это вопрос о прикреплении шасси одного транспортного средства к другому вызывает у вас такую нервную реакцию?
это не нервное. Хотя вы с вашим тоном и упрямством начинаете меня раздражать. Примените эти ваши свойства к вашей системе, а не в этом бессмысленном диалоге.
Вам с самого начала следовало написать, что вы не знаете способа обеспечить непрерывность работы БД при бэкап-откате, но вы зачем то упираетесь и учите меня писать ПО.
я не знаю такого способа для БД, потому что его НЕТ. Как для системы обеспечить "непрерывность", я сказал. Что вам еще нужно, я не знаю.

p.s. еще раз будет что-то про "душевные переживания", "млашеклассник", "нервную реакцию", и т.д. - забаню. Провокаторы мне тут не нужны.

Dimitry Sibiryakov
Заслуженный разработчик
Сообщения: 1436
Зарегистрирован: 15 сен 2005, 09:05

Re: Перенос дельта-файла

Сообщение Dimitry Sibiryakov » 07 сен 2012, 15:52

kdv писал(а):я не знаю такого способа для БД, потому что его НЕТ.
+1

Простейший двухнодовый кластер решит эту задачу "влёт", но это уже будет "система", а не "БД".

Ответить