Как бы оживить док к репликации?

[Akupaka]

Всем привет!

Столкнулся с проблемой репликации "устаревших" документов, подскажите как бороться, пжлста.
Схема репликации такая: центральный сервер (ЦС) - областной сервер (БС) (БС -> ЦС, Pull Push) - удаленное рабочее место (УРМ).
Версии серверов 5, клиентов 5-6.
Enforce a consistent ACL across all replicas - on.
Я имею полный доступ к каждой реплике (логически). Но! на уровне БС и УРМ пользователи только Author.
Удаленно управлять репликами на уровне БС и УРМ у меня часто нет возможности, т.е. изменить параметры/историю репликации на уровне интерфейса нотес я не могу.

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

В общем, сейчас у меня есть проблема вот какая:
- документ присутствует только на уровне УРМ, на БС и ЦС отсутствует.
- документ присутствует на всех репликах. давно не изменялся. на ЦС его изменили, но он не реплицируется на БС.

Как исправить такие и подобные ситуации?
Заранее спасибо!

 

[phantom76]

чистить репликейшн хистори в репликах..

 

[puks]

чистить репликейшн хистори в репликах..

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

И потом, все это не объясняет, почему эти документы не реплицируются после их модификации на центральном сервере.

А селективная репликация, случаем, не используется?

 

[phantom76]

В общем, сейчас у меня есть проблема вот какая:
- документ присутствует только на уровне УРМ, на БС и ЦС отсутствует.
- документ присутствует на всех репликах. давно не изменялся. на ЦС его изменили, но он не реплицируется на БС.

по второму случаю, могу сказать, что "лечил" очищением хистори..

по первому, нужно проверить, есть ли все права у пользователя реплицировать изменения на сервер..

 

[Akupaka]

Повторюсь, что "обычно" все нормально реплицируется, т.е. права есть, селективные формулы правильные...
phantom76, проблема действительно в очистке, т.е. я не могу почистить историю на БС. Если бы мог, то тогда, по-идее, очистив репликацию хотя бы на БС, я смог бы заставить реплицироваться док из первого и второго случая...
Но, "там" админов нет, а отсюда нет доступа к домино...
Кто-нить решал подобную задачу?.. имеется в виду, очистка истории репликации "удаленно"...

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

 

[Akupaka]

пытался почистить историю, но не получил желаемого результата, наверное не правильно почистил. если есть кто знающий, прошу помощи
в общем, исходя из справки по репликации:
"Before replication starts between two databases, Domino checks the replication history of both databases to make sure that they agree. If they don't, Domino scans each document created or modified since the date specified in the "Only replicate incoming documents saved or modified after"..."
я почистил историю на ЦС (напомню: Схема репликации такая: центральный сервер (ЦС) - областной сервер (БС) (БС -> ЦС, Pull Push) - удаленное рабочее место (УРМ).), таким образом создав условия для того, чтобы лотус реплицировал все доки с cutoff даты...
cutoff на ЦС 11.08.2008 03:01:47, на БС не известно, но думаю, что около того.
документ изменен на ЦС: 19.02.2007, на БС: 11.11.2008. кол-во записей в $Revisions не совпадает в репликах...

в итоге, вопросы:
- соответствует ли то, что написано в справке реальности и достаточно ли почистить историю с одной только стороны? если нет, то как корректно провести репликацию?..
- как читать это значение $Revisions вообще?
у меня на ЦС значения по доку такие:
Created: 20.10.2004 09.32.07 (in)
Modified: 19.02.2007 10.32.08
Added: 25.10.2004 08.51.27 (itf)
Modified: 19.02.2007 11.43.09
$Revisions: Seq Num = 3
20.10.2004 09:43:37 ZE2
20.10.2004 09:43:37 ZE2
т.е. с датой модификации как-то не очень совпадает... или я не понимаю это поле и оно не должно содержать дату модификации? О_о

значения на БС:
Created: 20.10.2004 09.32.07 (in)
Modified: 11.11.2008 14.20.58
Added: 25.10.2004 08.45.29 (itf)
Modified: 11.11.2008 14.40.39
$Revisions: Seq Num = 8
20.10.2004 09:43:37 ZE2
20.10.2004 09:43:37 ZE2
25.01.2007 14:51:19 ZE2
11.11.2008 14:19:31 ZE2
11.11.2008 14:19:43 ZE2
11.11.2008 14:19:57 ZE2
11.11.2008 14:20:09 ZE2

 

[puks]

Надо чистить историю в филиале. У тебя нет доступа к филиальному серверу? Если репликация проходит, то порт открыт. Прав не хватает? Каких? У вас один домен?

 

[Akupaka]

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

 

[phantom76]

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

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

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

 

[Kee_Keekkenen]

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

 

[Akupaka]

получать историю для анализа получал,

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

как я понимаю, то история репликации сидит в каком-то документе, но как его вытащить, я пока не нашел

 

[Kee_Keekkenen]

из других стандартных средств - notes API

 

[Akupaka]

а можно увидеть пример кода, либо имена функций, которые могут помочь?