OberonCore

Задача: сделать распределенную систему накопления данных, которая могла бы продолжать функционировать в случае потери части из составляющих ее ПК.

Как я представляю, это несколько ПК содержащих не реляционные БД и соединенных сетью. При обновлении данных в одной из БД изменения автоматически проводились и других БД. В результате, все БД имели бы одинаковое содержимое, через вполне определенное время (около 5 мин). Также хотелось бы чтобы при включении в сеть ПК с пустой БД приводило к автоматическому заполнению это БД.

Может кто предоставить информацию о таких системах?

Этот режим работы, на сколько я знаю, называется "зеркалирование" и он поддерживается (или должен поддерживаться) почти всеми СУБД. То есть то что Вам надо сделать это прочитать документацию по конфигурированию используемой Вами СУБД.

"Не-реляционная БД" - значит, custom-БД? Речь о том, как это запрограммировать?

Это организовывается через журналирование операций записи. Локальный журнал позволяет "прокатить" старые бэкапы до нового целостного состояния. Для репликации нужно организовать пересылку журнальных записей на центральный журналирующий узел. Сервера "горячей замены" (они же могут выполнять функции реплик "только на чтение") втягивают эти записи с журналирующего узла и всегда имеют актуальную копию, каждый готов стать главным.

Примерная схема действий такова.

Да, верно.

Только хотелось бы обойтись без центрального узла. И запросы чтения/записи можно было бы посылать на любой ПК.

Собственно, такая задача возникла из опыта эксплуатации различных СКАДА систем с РСУБД. И мой личный взгляд - централизованные системы, для надежных систем, не самый лучший вариант. Требуют слишком много времени и усилий на сопровождение и развертывание.

Ну, центральный узел не выполняет функций несущего. Он просто глобальная точка обмена. Журнал тоже можно хранить на нескольких таких узлах.

Вообще, тема очень интересная, можно в личку

А если изменения выполнятся одновременно на двух разных серверах? Не то, чтобы это нельзя было учесть при реализации, но эффективность БД может серьёзно упасть.

Согласен. Илья, обязательно напишу в ближайшее время о своих соображениях

Это одна из проблем. Делал несколько экспериментов, но ничего толкового не получилось

Пока остановился на варианте когда для записей-блоков рассчитываются хеш-сумы. Если меняется блок, то машины А посылает соседним машинам (Б, В) сообщение с двумя хеш-сумами: старой и новой. Если у соседа есть блок со старой хеш-суммой или нет в БД ни одного блока с указанными хешами, то он запрашивает данный блок и заменяет/вставляет его в БД. Если есть с новой - ничего не делает.

Но проблема, в том что вставка\изменение генерирует сообщение об изменении, что приводит к повторному запросу уже к машине А. А если в этот момент этот же блок на машине А уже изменился, то получаем не нужный дубликат и ... новое сообщение об изменении. Система получается не устойчивой.

Как решение этой проблемы - разделение сообщений на модификацию БД из-вне и модификацию при синхронизации. Но все равно, толком не работает.

Нельзя объять необъятное. Если в принципе нельзя параллельно проводить модификацию "интерферирующих" данных, значит нельзя и точка. Нужен некий диспетчер выдающий право на модификацию.

Наступив N раз на "грабли" сформулировал нечто схожее. Спасибо.

Ещё конкретнее он и называется репликацией. Только обычно это всегда мастер-слэйв...

А как там распределённые версионированные хранилища работают?.. a la Mercurial?..