OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Суббота, 17 Август, 2019 13:34

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 11 ] 
Автор Сообщение
СообщениеДобавлено: Вторник, 01 Декабрь, 2009 14:02 

Зарегистрирован: Среда, 31 Октябрь, 2007 18:58
Сообщения: 212
Откуда: Austria, Bruck
Задача: сделать распределенную систему накопления данных, которая могла бы продолжать функционировать в случае потери части из составляющих ее ПК.

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 01 Декабрь, 2009 14:16 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
Этот режим работы, на сколько я знаю, называется "зеркалирование" и он поддерживается (или должен поддерживаться) почти всеми СУБД. То есть то что Вам надо сделать это прочитать документацию по конфигурированию используемой Вами СУБД.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 01 Декабрь, 2009 14:29 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9128
Откуда: Россия, Орёл
"Не-реляционная БД" - значит, custom-БД? Речь о том, как это запрограммировать?

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 01 Декабрь, 2009 15:03 

Зарегистрирован: Среда, 31 Октябрь, 2007 18:58
Сообщения: 212
Откуда: Austria, Bruck
Илья Ермаков писал(а):
"Не-реляционная БД" - значит, custom-БД? Речь о том, как это запрограммировать?

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

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

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 01 Декабрь, 2009 15:07 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9128
Откуда: Россия, Орёл
Ну, центральный узел не выполняет функций несущего. Он просто глобальная точка обмена. Журнал тоже можно хранить на нескольких таких узлах.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 01 Декабрь, 2009 15:25 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 1538
Откуда: Беларусь, Минск
hothing писал(а):
Илья Ермаков писал(а):
...
Примерная схема действий такова.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 01 Декабрь, 2009 16:02 

Зарегистрирован: Среда, 31 Октябрь, 2007 18:58
Сообщения: 212
Откуда: Austria, Bruck
Илья Ермаков писал(а):
Вообще, тема очень интересная, можно в личку :)

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 01 Декабрь, 2009 16:25 

Зарегистрирован: Среда, 31 Октябрь, 2007 18:58
Сообщения: 212
Откуда: Austria, Bruck
Valery Solovey писал(а):
А если изменения выполнятся одновременно на двух разных серверах? Не то, чтобы это нельзя было учесть при реализации, но эффективность БД может серьёзно упасть.

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

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

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 02 Декабрь, 2009 13:06 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
hothing писал(а):
Но все равно, толком не работает.
Нельзя объять необъятное. Если в принципе нельзя параллельно проводить модификацию "интерферирующих" данных, значит нельзя и точка. Нужен некий диспетчер выдающий право на модификацию.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 02 Декабрь, 2009 16:51 

Зарегистрирован: Среда, 31 Октябрь, 2007 18:58
Сообщения: 212
Откуда: Austria, Bruck
:) Наступив N раз на "грабли" сформулировал нечто схожее. Спасибо.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 03 Декабрь, 2009 00:18 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4294
Откуда: Россия, Орёл
Сергей Губанов писал(а):
Этот режим работы, на сколько я знаю, называется "зеркалирование" и он поддерживается (или должен поддерживаться) почти всеми СУБД. То есть то что Вам надо сделать это прочитать документацию по конфигурированию используемой Вами СУБД.

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

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


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 11 ] 

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


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

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2019, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB