В MS SQL можно сделать запрос для определения последнего изменения типа такого:




Не смог найти чего-то подобного в Firebird. Думал время последнего изменения файла базы поможет, но оно как-то странно меняется, gstat показывает только время создания базы. Есть ли варианты кроме как обновлять вручную переменную или поле при каждом запросе изменения?

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

Мимопроходящийчто подразумевается под "синхронизацией" ?

В моем контексте это простой вариант - несколько машин, каждая со своей базой, но реально работа производится только на одной (главной), остальные на подхвате. Если главная умирает, одна из оставшихся становится главной и продолжает работу умершей и так далее, до последней оставшейся. Если кто-то из тех кто поглавнее неожиданно воскресает, то работу должна продолжить она. Отдельной системы хранения данных нет, предполагаются абсолютная надежность сети и невозможность смерти всех машин одновременно. Таково видение клиента бесперебойной работы системы.

Basil A. Sidorov,
Во первых я не смогу ему это объяснить, что это неправильно поскольку эта конструкция сейчас реально работает и потребовала относительно небольших усилий от меня в реализации. Базы иногда теряют часть последней, не успевшей сархивироваться, информации, но это для клиента несущественно. Во вторых и это главное, клиент мне четко дал понять, что любые укручения системы будут за мой счет. Я все таки не враг себе :)

Dimitry Sibiryakov,
982183,
Я уже сказал связь предполагается абсолютно надежной. Кстати почему бы этому не быть правдой? Рутеры с проводами всяко проще компьютеров. Можно также продублировать связь вайфаем. Есть еще одна тонкость - без сети полезная функция моего ПО равна нулю, если такое случается то, чтобы там не писалось в базу практического значения не имеет. После подъема сети даже если базы будут сильно различаться я их синхронизирую по какой нибудь одной не особо парясь что, что-то там на какой то базе потерялось.

kdv,
На главной реально работающей машине при наличии изменений в базе регулярно (например раз в минуту) делаются бэкапы (последовательно, в количестве например не больше 10, старые затираются) и рассылаются всем остальным. Если главная машина упала, производится поиск машины с наибольшим приоритетом которая делает рестор и становится главной рабочей и так далее. Если внезапно появляется машина с большим приоритетом, бывшая главная делает бэкап отправляет новой главной, главная делает рестор и берет работу в свои руки. Запасные машины не работают вообще, только получают бэкапы. Информация теряется между последним бэкапом и последним изменением базы. Но с этим клиент мирится.

Симонов Денис,
А сколько записей в сумме должно быть для нормальной? Миллиона хватит? Я потестю

Dimitry Sibiryakov,
Это что за база такая?! На firebird?! Хелперы решили просто локальную задачу определения последнего изменения базы без изменения кода - один выполняется при выполнении запроса (проверяет изменилось ли число записей), другой при коммите транзакции фиксирует время если число изменившихся записей ненулевое.

kdvMolochnik,

что будет, если бэкап будет длиться больше минуты?
Это может случиться не только из-за увеличившегося размера БД, но и тормозов оборудования.
И, пользователь вынужден работать с базой в условиях постоянного бэкапа? Это ведь полный скан БД,
будет малозаметно разве что если база и бэкап на SSD.

Вообще, конечно, это псевдо-репликация для бедных, выглядит ужасно.
Во первых только SSD и для базы и для бэкапов. Во вторых автоматическое удаление старых записей во избежание бесконечного разрастания базы. Оборудование свежекупленное хорошее. Да, постоянный бэкап, но ничего страшного, он не требует иксклюзивного доступа, делается в отдельном потоке. Да, выглядит уродливо, признаю, но должно быть сделать кондово - просто но надежно (терминология клиента). А как вообще сделать иначе? Если не делать бэкапы то надо будет вести полный лог совершенных действий, который иногда надо будет выполнять если потребуется. Причем запросы должны быть точно синхронизированы по времени выполнения, возможно есть еще какие нибудь подводные камни типа разнын последние цифры флоата. По моему эта задача на пару порядков тяжелее в решении. Если конечно если бы это была база транзакций визы, наверное стоило бы этим заняться, а для утилитарных нужд может это и не нужно.

Dimitry Sibiryakov,
А что такое "четверка"?

kdv,
Да такие базы будут бэкапиться долго. У меня поменьше думаю максимум 500 мегов, в минут уложится.

Dimitry Sibiryakov,
Имеет ввиду четвертый FB? Он же еще в бета версии, его можно ставить клиенту? Я только месяц назад перешел на FB3.

kdv я надеюсь, вы в курсе, что удаление (delete) порождает новые версии записей, и в результате база увеличивается.
То есть чтобы этого избежать время от времени нужно делать рестор на главной машине?

Симонов ДенисОднако существуют платные версии HQ Bird, Red Database, Avalarion в которых репликация сделано нормально.
Да и есть самописные реализации, где она сделана по уму хоть и не на уровне ядра. Твоя реализация совершенно не масштабируема и не надёжна.
Платные версии не хочу потому что клиент за них платить не будет, а такая задача вряд кому то понадобится еще. Да, немасштабируемое решение согласен.

982183Molochnik Во вторых автоматическое удаление старых записей во избежание бесконечного разрастания базы.
Старых записей или старых бэкапов?
Хотя и то и другой сомнительно...
Удаление всего, что может увеличить размер занимаемого пространства, в частности старые записи базы, старые лог файлы, а бэкапов ограниченное количество. Это пожелание клиента.

Dimitry SibiryakovОн всяко не будет хуже твоего поделия. Просто обеспечь регулярное обновление.

Так и сделаю попозже в след версии и предложу клиенту онлайн синхронизацию, может клюнет

maytonУ тебя - странный подход к восстановлению. В продуктовых базах потеря даже одной записи - это
потерянные деньги. Это репутационные потери. Что у тебя за база? Что за данные? Каким образом это ты (особо парясь!) принимаешь решение - где данные будут для тебя ценнее?

Да, все так. По счастью у меня не продуктовая база, а в основном статистические данные и оперируют ими обычно в статистических целях. Одна потерянная запись ни у кого денег не отнимет. Если бы это было важно я бы конечно так делать не стал (я вообще этим изначально не хотел заниматься и планировал использовать MS SQL с своими группами доступности, но клиенту не понравились дополнительные траты)
maytonМежду прочим "цифровой ник" тебе задал интересную задачу. Я не вижу ее правильного решения ни в каком виде.

А какую задачу он задал? Не понял в каком сообщении
maytonИли для тебя данные в принципе не особо ценные. Тогда зачем так страдать по последним изменениям?
Да, не особо ценные и поэтому раньше вопрос и не возникал и никого вообще это не парило. А этому клиенту понадобилось, там реально занимается этим только один человек со своим видением решения, вот его желания и исполняю.

Кстати сейчас пока тестировал архивацию, пара вопросов возникло. В 3-ем FB пароли можно менять SQL запросом а не gsec-ом, а запроса на бэкап-рестор так и нет. Это вообще планируется в 4й версии? И еще один вопрос - как можно определить что рестор прошел успешно? Если FB на локальной машине я просто удаляю файл базы перед рестором и смотрю не появился ли он после него. А если FB и файл базы на удаленной машине и доступ к нему через UNC путь закрыт, как тогда?

m7mПо логу рестора
Визуально то понятно, а программно? Формат лога разве специфицирован?
m7mнадеюсь удаляешь не файл основной базы ибо
появление файла после рестора совсем не означает что рестор прошел успешно
Не знал этого, а я надеялся...
hvladСделать коннект к новой БД.При наличии паранойи - сделать ей валидацию.
А если база восстановилась но не полностью? Валидацию же пройдет.

А код завершения gbak? Я немного потестировал, если бэкап или рестор завершились успешно, возвращает 0, иначе 1. На это можно положиться?

Симонов Денис,
Ничего ж себе, вот это сервисы в 4ке! Просто кардинальные изменения - и распределенная база тебе и инкрементный бэкап. В третьем ничего существенного для себя не нашел, разве что перешел на суперсервер.

Симонов Денис,
Я так понял, что инкрементный бэкап в терминологии FB, это когда:
Сначала делается основной файл бэкапа, далее - только файлы изменений
1) До 2.5 его использовать было нельзя
2) В последних версиях 2.5 было можно, но не было смысла поскольку время занималось как и при полном, разве что файлы изменений занимали меньше места
3) В 3-ем его стало иметь смысл его использовать поскольку стал очень быстрым
4) в 4-ке рестор можно делать с любого изменения бэкапа

Симонов Денисну это ты погорячился, никакой распределённой БД там нет. Есть логическая синхронная и асинхронная репликация мастер-слейв.
А чем это отличается от распределенной базы?

MolochnikА чем это отличается от распределенной базы?
Тем что данные не размазаны, а собраны в одном месте?

Да еще один момент, при ресторе имя файла базы всегда восстанавливается в верхнем регистре независимо от моего желания. Это просто неуважение со стороны FB или это имеет какой смысл?