Здравствуйте.

Есть такая ситуация, точнее она не есть, но вполне вероятна:

Программа одновременно проводит одинаковые транзакции над тремя (и более) одинаковыми базами данных, каждая из которых расположена и управляется отдельным сервером.

В это время падает один из серверов и база уходит в Лэнг… Программа просто перестает выполнять транзакции с этим сервером и работает с остальными. Затем админ поднимает сервер, и каким-то образом должен базу (полностью чистую) синхронизировать с остальными(полностью одинаковыми), Не останавливая!!! работу программы. Тоесть backup/restore не подойдет, так как за это время выполнится неизвестное количество транзакций.

Есть ли стандартный механизм синхронизации двух баз без остановки приложения в Firebird, в других серверах РБД?

Задал вопрос здесь, так как с Fb обычно работает народ образованный и мыслящий.

FreemanZAVto soft
Я думаю, что лучше писать в одну базу, а потом остальные синхронизировать. IBReplicator - ом например.

Да я так и думал. Вопрос в цене или открытости не стоит, так работа научная и цена реализации "полной" модели в ней в исследование не входит :) В принципе, даже чем дороже тем лучше, главное чтобы была нормальная реализация указанного выше механизма...

В Oracle и DB2 вроде механизмы репликации, в том числе Online вроде присутствуют в Enterprise версиях.

Свой механизм репликации делать, думаю, было бы сложно.

Dried Gagarin
посмотреть можно куда угодно, если требуется надежность... а использовать лучше не наколенные решения, а купить готовое. Решения по кластеризации всего и вся на рынке есть - рекламой заниматься не буду.

Db2?

Di_LIne Эт, простите с точки зрения пользователя, или это синхронное, 3-х поточное приложение на 3-х камневом монстре???


Скажем, 64-x процессорный монстр (SMP/MPP???) с Java-шным приложением к которому подключены 1000 пользователей (каждый коннект в своем потоке и на каждый поток свой db conect или даже несколько)

Di_LIne
softЕсть ли стандартный механизм синхронизации двух баз без остановки приложения в Firebird , в других серверах РБД?
Уп-с!... А транзакции, и соответствующие им изменения в БАЗЕ(-ах), проводимые клиентской программой, как бум учитывать?
Аль думать не надо, сервак железный - сделает все сам?

Пишет только главное приложение и пользователи к нему подключенные, остальные в read-only режиме (по архитектуре такие же), тоесть могут только читать данные с локальных для себя серверов и удаленных от главного. Серваки СУБД могут быть разнесены территориально. В принципе несинхронность данных в течении часа не особо страшна, но их очень уж много - теоретически, петабайты.

Di_LIne
Ну так прямо и нуна грить: - Территориально-разнесенная система...


Ну в общем-то да - классический континентальный Grid.


Di_LIne
А то тень на плетень наводить...
Петабайты - эт по-русски скока??? (Гораздо больше чем до XYZ?! )
А если енту, неизвестную в Природе, сифирку поделить на 3600 секунд, то
глазки выпучаться от такой скорости канала...
Значитца задача обче_теоритическая.
Пойду-ка БСЛ поработаю что-ль...

Петабайты это всего 10^15, Oracle тот же поддерживает базы размером в 8 эксабайт 10^18. А математика знает йоттабайты 10^24, вот это уже действительно больше чем "до XYZ" :)

Как я понял, синхронная репликация данных мне поможет, при наличии соответствующей физики (канала, железа...).

Я сделал правильные выводы?

Di_LIne soft Di_LIne
Ну так прямо и нуна грить: - Территориально-разнесенная система...


Ну в общем-то да - классический континентальный Grid.
- А при чем тут IB/FB/YA ??????????????
Пол-дня мы тут распинаемся, а чел шутить изволит.
to Kull: - Слей енто в "Про разработку БД".
Товарищ Yo и другие обязательно помогут афтару....


В общем-то, этот грид будет только на бумаге... теоретически, чтобы сказать комиссии, что данная программная модель после определенной доработки напильником это позволяет. А реально будет обычная PC-шная системка, для которой Firebird-а выше крыши http://eds.sourceforge.net/ . Возможно даже Java-овская встроенная БД Derby будет.

Во всяком случае для теоретической модели Postgre+один из Replicator-ов будет достаточно.

В общем-то, я даже аналог в сети нашел http://starlasoft.com/ Только он платный и закрытый.

Александр ГoлдунОпять дипломники с теоретизированиями для мусорной корзины???


На этот раз все гораздо жестче - аспиранты :)

Александр Гoлдун
soft
Программа одновременно проводит одинаковые транзакции над тремя (и более) одинаковыми базами данных, каждая из которых расположена и управляется отдельным сервером.

А что означает подчеркнутое?


Insert/update одних и тех же записей одними и теми же данными, так как объем данных при операциях выборки в 100-1000 раз превышает при операциях внесения данных. Хотя, как я понял, здесь проще стандартный механизм репликации использовать.

Александр Гoлдун
soft
В это время падает один из серверов и база уходит в Лэнг… Программа просто перестает выполнять транзакции с этим сервером и работает с остальными. Затем админ поднимает сервер, и каким-то образом должен базу (полностью чистую)

А почему чистую? Админ облажался, бэкапы не делал?


Такое бывает

Александр Гoлдун
Т.е. все-таки приложение пишет реально в одну базу, а в остальных нужно получить read-only копию? И это тянет на тему диплома??? Да тут даже с репликациями заморачиваться не надо - можно рабочий макет такой схемы организовать меньше чем за час, причем для любой базы с любой сложностью структуры. Обеспечиваешь на удаленных хостах начальные полные копии центральной базы, а потом просто с нужными интервалами делаешь на них инкрементальный бэкап.

Нет, это кусочек работы, примерно 5% от основной. Для инкрементального Backup-а нужен лог транзакций, а в FB его нет.

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

А сама работа модель СФС с хранилищем в РБД для распределенных систем, ну или хотя-бы кластерных. Основная проблема здесь была многопотоковая работа с метаданными и организация произвольного доступа на изменение для сверхбольших файловых объектов (по нескольку гигабайт). Тоесть одним блобом такое не засунешь, так как его для изменения придется полностью в память вытягивать :) Кроме того внесение такого режима как sharewrite для файлового объекта с возможностью write_on_close_or_rollback.

Dried Gagarin Ivan_Pisarevskyкогда же все таки фб начал поддерживать работу в кластере???

никогда... речь о более другом решении... приводить не буду - мне за его рекламу не платят, тем более тут депломнег (или азперанд)

Честно говоря, уже не нужно. У меня нет привязки к конкретному серверу, а для репликации модели я просто укажу использовать соответствующую СУБД со встроенной возможностью этого ORACLE, DB2, ASA или PostgreSQL.

А FB для локальной системы сгодится.

Di_LIne softА FB для локальной системы сгодится.
- Локальная система с трафиком в ЙопТоБайт?!!!!!!!!!!!!!!!!!!!!!!!
- На морщите нам бабушку, плиз!

Локальная система с трафиком в 500-1000Кб/сек. Реально?

Di_LIne soft Di_LIne softА FB для локальной системы сгодится.
- Локальная система с трафиком в ЙопТоБайт?!!!!!!!!!!!!!!!!!!!!!!!
- На морщите нам бабушку, плиз!

Локальная система с трафиком в 500-1000Кб/сек. Реально?
Ну а ТУТ
кто баламутил в нашем вермутном пруду?

Система проектируется как локальная, но "в теоретизированиях для мусорной корзины" должен указывается способ сделать ее распределенной. Это решается простым механизмом репликации данных, который уже является стандартным почти для всех серьезных СУБД.

Тоесть если операции DML(удалить вставить изменить...) будут реплицироваться, то таким образом будут реплицироваться и данные. А стало быть расхождения в модели данных на локальном и удаленном сервере будут незначительны и их временной интервал прямо пропорционален скорости их репликации.

Тоесть то что требовалось доказать, файловая структура, вложенная в БД, поддается прозрачной репликации без останова системы и может использоваться для хранилищ данных в grid системах.

PS
Тоесть эти 5% работы удалось сделать не делая :)