Репликация и проверка целостности данных

Тема в разделе "Lotus - Программирование", создана пользователем Akupaka, 4 июн 2010.

  1. Akupaka

    Akupaka А че я?.. О.о

    Регистрация:
    4 окт 2007
    Сообщения:
    3.373
    Симпатии:
    2
    Всем привет!

    Есть система, весьма большая, которая распределена на несколько уровней.
    В частности есть три уровня:
    Сервер Центральный (1) <- Сервер региональный (2) <- клиент субрегиональный (3)
    Иногда возникают ситуации, когда клиент 3-го уровня реплицирует данные, но в связи с какими-то проблемами на сервере 2-го уровня все изменения не получены, соотв, и на сервере 1-го уровня их не будет. Либо заминки могут быть между 1-м и 2-м уровнями. Как в одну так и в другую сторону.
    Возникает вопрос: как убедиться, что данные на уровнях синхронизированны? Сейчас абсурдно - звонят переспрашивают.
    Кто-нить решал такую задачу? Или есть идеи?
    Спасибо заранее.
     
  2. ToxaRat

    ToxaRat Чёрный маг
    Lotus team

    Регистрация:
    6 ноя 2007
    Сообщения:
    3.046
    Симпатии:
    18
    может создать агент на 2м чтобы тот на новых документоа слал реквестиы клиенту, что его данные получены?
     
  3. VladSh

    VladSh начинающий
    Lotus team

    Регистрация:
    11 дек 2009
    Сообщения:
    1.251
    Симпатии:
    2
    Есть решения - замена репликации на отправку доков по почте, но тогда надо будет реализовывать проверку доставки, уведомление может не дойти, надо проверять доставку уведомления и т.д. до бесконечности... мне кажется, что это отстойное решение.

    Проверка синхронизированности данных? Думаю никак..

    Идеи кардинальные )) :
    - сбросить старые доки в архивные базы, чтобы реплицировались только актуальные доки, например, последнего года (недостаток - наличие разработки);
    - потратиться на хороший канал, если данная проблема имеется, благо сейчас это недорого.

    Добавлено:
    Тогда надо иметь часть функциональности репликатора, чтобы произвести сравнение и определить, какие доки являются новыми.
    И доки могут быть не только новыми, а и изменившимися.
    По моему, это путь в никуда...
     
  4. Мыш

    Мыш Lotus team
    Lotus team

    Регистрация:
    12 фев 2008
    Сообщения:
    1.019
    Симпатии:
    8
    Я анализирую агентом log.nsf, при обнаружении ошибок репликации шлю уведомления. Верна ли указанная там инфа на все 100% - не могу сказать, но пока проблем (тьфу-тьфу-тьфу!) не наблюдал.
     
  5. VladSh

    VladSh начинающий
    Lotus team

    Регистрация:
    11 дек 2009
    Сообщения:
    1.251
    Симпатии:
    2
    Мыш
    Конкретному пользователю важно не прошла ли репликация между серверами, а отреплицировался ли конкретный документ, и если да, то когда...

    Если бы я писал этот, блин, репликатор, то результат в виде <журнал сравнения> минус <отреплицировавшиеся документы> помещал бы в какую-либо базу на обоих серверах + функцию, чтобы возвращала бы инфу по доку: время последней модификации и время последней репликации дока.
     
  6. Constantin A Chervonenko

    Constantin A Chervonenko Well-Known Member

    Регистрация:
    30 май 2006
    Сообщения:
    1.288
    Симпатии:
    0
    М-дяяя... Неблагодарная задача: Для того, что-б проверить наличие связи надо иметь связь в наличии.

    Вариантики:
    1.На принимающем конце цепочки ставить на новых/обновленных док-тах флажок: "получено" (с датой?)
    2.Читать журнал репликации (через C API :) ): если док-т обновлён ДО последнего сеанса, значит он дошел (верим репликатору). Правда, для цепочки серверов так просто не получится
     
  7. TIA

    TIA :-)
    Lotus team

    Регистрация:
    15 май 2009
    Сообщения:
    790
    Симпатии:
    0
    Теоретически, если при репликации был сбой, то в историю репликации не должна прописываться новая временная отсечка. Можно попробовать основать решение на анализе этой истории на всех серверах цепочки. На API история репликаций точно выдирается.
     
  8. VladSh

    VladSh начинающий
    Lotus team

    Регистрация:
    11 дек 2009
    Сообщения:
    1.251
    Симпатии:
    2
    Это значит, что мы разрешаем доку меняться на 2-х и более серверах, что чревато конфликтами...

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

    Добавлено:
    Я не знаю, как устроен журнал репликации... но если предположить такую ситуацию: док отреплицировался, сервер-1 его отправил полностью, - делает у себя пометку, сервер-2 ещё не раздуплился, что док пришёл полностью и в это время обрывается связь... Или наоборот: сервер-2 принял док, сдалал у себя отметку, шлёт системмное сообщение серверу-1 о том, что док принят, в это время обрубается связь...

    Что-то можно вымутить (условно) в пределах 2-х серверов, 3-й сервер не знает вообще об изменении некоторых документов, т.к. журнал серверов 1-2 не будет синхронизироваться с журналом серверов 2-3, будет происходить сравнение доков между серверами 2 и 3, а части доков на сервере 2 нет, т.е. сервер 3 даже не получит инфы о том, что некоторые доки менялись...
     
  9. Constantin A Chervonenko

    Constantin A Chervonenko Well-Known Member

    Регистрация:
    30 май 2006
    Сообщения:
    1.288
    Симпатии:
    0
    Ну зачем-же "до бесконечности", велосипеды изобретать..
    1.Sender повторяет отсылку до тех пор, пока не придет подтверждение
    2.Receiver отвечает квиточком на всё принятое (можно - с кАментом, мол - повторное)
    Усё...
     
  10. Akupaka

    Akupaka А че я?.. О.о

    Регистрация:
    4 окт 2007
    Сообщения:
    3.373
    Симпатии:
    2
    В принципе, у меня задача сводится к проверке кол-ва документов (подпадающих под условие) и сумме значений определенного поля в этом кол-ве.

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

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

    Читать журнал репликации без особого толку. В некоторых случаях, что-то где-то залипает, и в журнале запись есть, а изменения не синхронизированы.
     
  11. Constantin A Chervonenko

    Constantin A Chervonenko Well-Known Member

    Регистрация:
    30 май 2006
    Сообщения:
    1.288
    Симпатии:
    0
    Не более, а ровно на 2-х: 1-м и последнем в цепочке (если их - first/last - можно выделить). Причём, если передача данных одностороняя, возможные конфликты легко разрешаются

    Про журнал репликации: пока сеанс успешно не завершился, в журнал отметка не пишется. Т.е. если к примеру в ЖР написано, что сеанс от 10:00 завершился, это значит что ВСЕ док-ты, модифицированные ДО 10:00, успешно синхронизированы.

    Вы спросите: а что с док-тами, которые модифицированы ВО ВРЕМЯ сеанса?
    Да, в 4.х была такая ошибка, док-ты модифицированные во время сеанса могли из репликации выпасть. Позже - поправили
     
  12. Akupaka

    Akupaka А че я?.. О.о

    Регистрация:
    4 окт 2007
    Сообщения:
    3.373
    Симпатии:
    2
    Эх, если бы так было на самом деле...
     
  13. Мыш

    Мыш Lotus team
    Lotus team

    Регистрация:
    12 фев 2008
    Сообщения:
    1.019
    Симпатии:
    8
    Т.е., у вас не все документы попадают в target-базу, но при этом репликация завершается успешно? Можно еще поиграться параметром LOG_REPLICATION, он, вроде, в каком-то режиме выводил в логи ID реплицированных документов - вот только, по-моему, без указания базы :-(
     
  14. Akupaka

    Akupaka А че я?.. О.о

    Регистрация:
    4 окт 2007
    Сообщения:
    3.373
    Симпатии:
    2
    Там страшные логи. Имхо, легче свой сервис написать, чем читалку этих дивных логов :(

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

    Но вопрос сейчас не именно в этом, а в том, каким методом лучше передавать заключение о состоянии данных.
    Но, видать, такими задачами редко занимаются.
     
  15. Klido

    Klido Гость

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

    Akupaka А че я?.. О.о

    Регистрация:
    4 окт 2007
    Сообщения:
    3.373
    Симпатии:
    2
    Я бы тоже не против, но...
    Некачественные каналы + немалый объем/количество данных + большой объем накопленных данных + несвоевременная репликация + какие-то внутренние глюки...
    делают свое дело :(
     
  17. VladSh

    VladSh начинающий
    Lotus team

    Регистрация:
    11 дек 2009
    Сообщения:
    1.251
    Симпатии:
    2
    При большом объёме данных веселуха выйдет - сервера почтой напрягать, и не дай бог где-то затык будет и потом роутер будет это всё "раскачивать".
    Было такое когда-то давно, отказались, как раз по причине того, что это велосипед с квадратными колёсами...

    По условиям задачи это не подходит.

    Если же запись в оба журнала идёт после полностью успешной репликацией, то тогда да, а если после репликации каждого отдельного документа, то, думаю, рассинхронизация (запись разных данных в оба журнала) вполне возможна.
     
  18. rinsk

    rinsk Lotus team
    Lotus team

    Регистрация:
    12 ноя 2009
    Сообщения:
    795
    Симпатии:
    78
    Коллеги! поздновато увидел увидел топик... Тем не менее хотелось бы высказаться по данной теме...

    Никогда и нигде факт ГАРАНТИРОВАННОЙ доставки сообщения не базируется на транспортных протоколах. Всегда используются именно ответные СООБЩЕНИЯ. Все остальное - от лукавого^_^ Пример - MS MQ, IBM MQ и аналогичные брокеры сообщений...

    В контексте Домино ИМХО данный вопрос можно решить 2-мя путями:
    1 - для факта появления на целевом сервере новых документов использовать фолдеры. Т.е.
    при появлении док-та перености его в фолдер. при обратной репликации на сервер-источник - и наличии документа в фолдере уже можно со 100% гарантией говорить что документ появился на сервере назначения. Данный способ ест-сно неприменим, когда необходимы передачи изменений уже существующего документа.
    2- использовать документы-ответы к основному документу. Это самый универсальный способ - каждый сервер в цепочке формирует док-ответ на новое\измененное сообщение. Накладных расходов тут немного - одна вьюха с колонкой и агент работающий с отсечками времени. Размер ответных в разы меньше основного дока. Чистить от мусора всю эту байду можно на одном сервере - где известно активное время жизни всей информации...
     
  19. VladSh

    VladSh начинающий
    Lotus team

    Регистрация:
    11 дек 2009
    Сообщения:
    1.251
    Симпатии:
    2
    Задача как бы в том, чтобы пользователь, сделавший изменения, всегда мог получить информацию о том, что его изменения доставлены определённому пользователю (на определённый сервер). Ответные документы - это такие же документы, они могут отреплицироваться или отреплицироваться частично или не отреплицироваться вовсе.. т.е. проверить гарантированность доставки всё равно невозможно. Или я чего-то не понял..
     
  20. Klido

    Klido Гость

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

    вариант с почтовой доставкой - застрелиться в случае сбоя роутинга (кроме всего, оно может с 1-го на 3-й сервак доставить почту окольным путём, а контролировать ещё и это - жестяк)
    вариант с ответами - для мегабаз на несколько КК доков это счиатай анриал сверок (ну и ясно как ты и сказал, это такой же док как и остальные ^_^)

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

Поделиться этой страницей