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

[Akupaka]

Всем привет!

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

 

[ToxaRat]

может создать агент на 2м чтобы тот на новых документоа слал реквестиы клиенту, что его данные получены?

 

[VladSh]

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

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

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

Добавлено:

может создать агент на 2м чтобы тот на новых документоа слал реквестиы клиенту, что его данные получены?

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

 

[Мыш]

Я анализирую агентом log.nsf, при обнаружении ошибок репликации шлю уведомления. Верна ли указанная там инфа на все 100% - не могу сказать, но пока проблем (тьфу-тьфу-тьфу!) не наблюдал.

 

[VladSh]

Мыш

Возникает вопрос: как убедиться, что данные на уровнях синхронизированны? Сейчас абсурдно - звонят переспрашивают.

Конкретному пользователю важно не прошла ли репликация между серверами, а отреплицировался ли конкретный документ, и если да, то когда...

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

 

[Constantin A Chervonenko]

М-дяяя... Неблагодарная задача: Для того, что-б проверить наличие связи надо иметь связь в наличии.

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

 

[TIA]

Теоретически, если при репликации был сбой, то в историю репликации не должна прописываться новая временная отсечка. Можно попробовать основать решение на анализе этой истории на всех серверах цепочки. На API история репликаций точно выдирается.

 

[VladSh]

1.На принимающем конце цепочки ставить на новых/обновленных док-тах флажок: "получено" (с датой?)

Это значит, что мы разрешаем доку меняться на 2-х и более серверах, что чревато конфликтами...

2.Читать журнал репликации (через C API ): если док-т обновлён ДО последнего сеанса, значит он дошел (верим репликатору).

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

Добавлено:

Теоретически, если при репликации был сбой, то в историю репликации не должна прописываться новая временная отсечка. Можно попробовать основать решение на анализе этой истории на всех серверах цепочки. На API история репликаций точно выдирается.

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

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

 

[Constantin A Chervonenko]

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

Ну зачем-же "до бесконечности", велосипеды изобретать..
1.Sender повторяет отсылку до тех пор, пока не придет подтверждение
2.Receiver отвечает квиточком на всё принятое (можно - с кАментом, мол - повторное)
Усё...

 

[Akupaka]

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

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

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

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

 

[Constantin A Chervonenko]

Это значит, что мы разрешаем доку меняться на 2-х и более серверах, что чревато конфликтами...

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

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

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

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

 

[Akupaka]

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

Эх, если бы так было на самом деле...

 

[Мыш]

Эх, если бы так было на самом деле...

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

 

[Akupaka]

Можно еще поиграться параметром LOG_REPLICATION, он, вроде, в каком-то режиме выводил в логи ID реплицированных документов

Там страшные логи. Имхо, легче свой сервис написать, чем читалку этих дивных логов

Т.е., у вас не все документы попадают в target-базу, но при этом репликация завершается успешно?

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

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

 

[Klido]

такими задачами редко занимаются

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

 

[Akupaka]

я, например, за модернизацию каналов

Я бы тоже не против, но...

видно какое-то сочетание редких параметров вызывает глюки репликации

Некачественные каналы + немалый объем/количество данных + большой объем накопленных данных + несвоевременная репликация + какие-то внутренние глюки...
делают свое дело

 

[VladSh]

Ну зачем-же "до бесконечности", велосипеды изобретать..
1.Sender повторяет отсылку до тех пор, пока не придет подтверждение
2.Receiver отвечает квиточком на всё принятое (можно - с кАментом, мол - повторное)

При большом объёме данных веселуха выйдет - сервера почтой напрягать, и не дай бог где-то затык будет и потом роутер будет это всё "раскачивать".
Было такое когда-то давно, отказались, как раз по причине того, что это велосипед с квадратными колёсами...

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

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

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

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

 

[rinsk]

Коллеги! поздновато увидел увидел топик... Тем не менее хотелось бы высказаться по данной теме...

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

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

 

[VladSh]

2- использовать документы-ответы к основному документу. Это самый универсальный способ - каждый сервер в цепочке формирует док-ответ на новое\измененное сообщение.

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

 

[Klido]

Задача как бы в том, чтобы пользователь, сделавший изменения, всегда мог получить информацию о том, что его изменения доставлены определённому пользователю (на определённый сервер)

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

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

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