информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Атака на InternetСетевые кракеры и правда о деле Левина
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / web building
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
а вот в это и заключается вся задача 16.03.05 17:48  Число просмотров: 2615
Автор: ZaDNiCa <indeed ZaDNiCa> Статус: Elderman
Отредактировано 16.03.05 17:57  Количество правок: 1
<"чистая" ссылка>
приведу один из (возможно далеко не лучший) вариантов
запросы типа UPDATE, DELETE не используются. Если нужно отредактировать скажем какое-то сообщение то делается INSERT, который добавляет в таблицу сообщение с таким же id, но в поле version будет значение больше. Т.е. организовывается что-то похожее на историю сообщений. Если нужно удалить сообщение, то добавляется запись где это сообщение имеет самую последнюю версию и имеющее статус "удаленное".
Делается это все для того чтобы изменение базы было только на основе запросов INSERT. Все они вносятся в базу и записываются в отдельный файл. Каждые n минут этот файл передается на другие сервера где они добавляются в базу
Но этот вариант тоже имеет подводные камни. Опыта разработки подобных проектов нет, но пока ничего лучшего придумать не удалось.
<web building>
подскажите как реализовать 16.03.05 13:28  
Автор: ZaDNiCa <indeed ZaDNiCa> Статус: Elderman
<"чистая" ссылка>
и можно ли вообще такое сделать.
Есть проект, для понимания примем что он похож на bugtaq.ru. Есть три офиса, каждый имеет свой сервер и выход в инет. Необходимо разместить этот проект работал на всех трех серверах и они были взаимосвязаны так, чтобы измения на одном автоматически вносились на два остальных (время между репликацями 5-15 минут). При чем, главного сервера нет (т.е. мастера с которого бы шла реплицация на два зависимых) - все три являются главными.
При реализации идеи столкнулся решеним двух задач - синхронизация файлов (это просто и решается с помощью rsync) и синхронизация SQL. Вот ничего путного придумать не получается.
а может XML WEB Service? 17.03.05 15:25  
Автор: БЖ Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Мне кажется, что будет уместным использование XML WEB Services для обеспечения интерфейса к данным на каждом сервере. И на каждом сервере реализовать WEB приложение, которое бы вызывало методы WebService остальных (для универсализации движка можно обращаться и к локальным службам WebService) и интерпретировало SOAP сообщения (ответы службы WebService) в HTML. В принципе, я как раз работаю над похожим проектом.
---
Если же требуется офф-лайн работа серверов и нужно делать репликацию, опять же можно сделать агента, который бы обращался к WEB Service, тянул к себе инфу и т.п.
---
PS Вообще, WEB Service технология достаточно интересная, хотя мало распространенная. MS со всей силой тужится чтобы популяризовать. Эту технологию поддерживает .Net , к тому же Ms сдалала WSE для VS.Net для работы с WS, так же есть SQLXML 3.0, что позоляет представлять хранимые процедуры как методы Web Service.
Но много скептических замечаний по сабжу. Вроде того, что XML сильно перегружен тэгами, из-за чего большой обе данных, не позволяет использовать бинарные данные и т.п. Это всё справедливо, но спорно :)
Лично мне эта технология нравится. :)
Я бы попытался использовать один sql сервер для всех трех... 16.03.05 14:56  
Автор: NKritsky <Nickolay A. Kritsky> Статус: Elderman
<"чистая" ссылка>
Я бы попытался использовать один sql сервер для всех трех веб-серверов. Как со связью между этими тремя офисами?
это крайний вариант 16.03.05 15:40  
Автор: ZaDNiCa <indeed ZaDNiCa> Статус: Elderman
<"чистая" ссылка>
в основном со связью все в порядке, но иногда бывают все таки перебои
и хотелось бы чтобы сервера в такие моменты могли работать автономно
А если при такой автономной работе на двух серверах произойдут изменения 16.03.05 16:06  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
Как ты эти самые изменения собираешься сливать?
а вот в это и заключается вся задача 16.03.05 17:48  
Автор: ZaDNiCa <indeed ZaDNiCa> Статус: Elderman
Отредактировано 16.03.05 17:57  Количество правок: 1
<"чистая" ссылка>
приведу один из (возможно далеко не лучший) вариантов
запросы типа UPDATE, DELETE не используются. Если нужно отредактировать скажем какое-то сообщение то делается INSERT, который добавляет в таблицу сообщение с таким же id, но в поле version будет значение больше. Т.е. организовывается что-то похожее на историю сообщений. Если нужно удалить сообщение, то добавляется запись где это сообщение имеет самую последнюю версию и имеющее статус "удаленное".
Делается это все для того чтобы изменение базы было только на основе запросов INSERT. Все они вносятся в базу и записываются в отдельный файл. Каждые n минут этот файл передается на другие сервера где они добавляются в базу
Но этот вариант тоже имеет подводные камни. Опыта разработки подобных проектов нет, но пока ничего лучшего придумать не удалось.
Опыт можно позаимствовать у version control system-ов 16.03.05 19:45  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
Есть один репозиторий, куча "песочниц" в которых производятся изменения и периодически сливаются в этот репозиторий. Каждая песочница (как вариант каждый файл в песочнице) имеет номер ревизии. Ну а дальше обычный

Update-Modify-Commit

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

При коммите репозиторий проверяется на существование изменений. Если они есть, то коммит отрывается пока не сделаешь апдейт до актуальной версии. При коммите пересылаются только изменения.

Как по мне, лучше всего пытаться привязаться к такой схеме

Единственная проблема - конфликты. То бишь когда одно и то же место (строку в таблице, строку в файле) изменяется в нескольких песочницах. Первая песочница без проблем закоммитит свои изменения, а вот для следующих лучше предоставить всю доступную информацию и заставить разрешать конфликт вручную (для разрешения конфликтов нужно понимать СМЫСЛ произведенных изменений, чего в автоматическом режиме сделать нельзя).
А можно вопрос чем не подходит репликация реализуемая SQL... 28.05.05 11:19  
Автор: Borisd Статус: Незарегистрированный пользователь
<"чистая" ссылка>
А можно вопрос чем не подходит репликация реализуемая SQL сервером,
один из 3х серверов поочереди соединяется с 2мя другими и обновляет и себя и их.
А эти три сервера оказываются несимметричными, а в условиях задания было 30.05.05 10:31  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> А можно вопрос чем не подходит репликация реализуемая SQL
> сервером,
> один из 3х серверов поочереди соединяется с 2мя другими и
> обновляет и себя и их.

При чем, главного сервера нет (т.е. мастера с которого бы шла реплицация на два зависимых) - все три являются главными.

А если Вы имеете в виду, что этот сервер, который соединяется, сначала забирает изменения, а потом изменят еще и slave-а, то опять же возникает проблема конфликтов, но кроме этого еще и неизвестно, что измнилось с момента последней репликации.
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach