Отследить процесс репликации, сжатия и др.

[AlexeyStaf]

Нет, а зачем именно такая запись?

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

 

[nvyush]

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

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

 

[Akupaka]

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

В логах репликации есть записи о кол-ве отреплицированных доков, объеме, что еще надо?
см в Log.nsf на серверах: Replication Events, Database usage\By User
У меня такое впечатление, что ты сам еще не понял, что тебе надо и надо ли оно тебе

 

[AlexeyStaf]

У меня такое впечатление, что ты сам еще не понял, что тебе надо и надо ли оно тебе

Нет, мое желание изначальное было - узнать на какой стадии идет процесс репликации (раз уж все уперлось именно в нее). Зачем? Для того, чтобы облегчить жизнь пользователям системы - в головной базе появляется нужный документ среди многих и необходимо знать приблизительно когда он уйдет в филиал. Например, если еще саму реплику можно запустить вне очереди, то один документ пропихивать - это уже через чур (а если все документы главные?). А если знать когда реплика завершится, то сотрудник сможет сориентироваться задержаться ему на 15 минут на работе или идти домой, т.к. реплика завершиться глубокой ночью. В итоге все будут дергать админа, который будет разводить руками.
Ситуация с головной базой и филиалом взята из головы для примера.

 

[nvyush]

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

Ответ: "сэмь-восэмь". Откуда Вы узнаете, каким именно по порядку будет среплицирован именно этот документ? Где гарантия, что он будет доставлен именно в эту репликацию, вдруг она оборвётся? Были случаи из практики, когда большие документы ползли по "узкому" каналу несколько дней.

 

[AlexeyStaf]

Ответ: "сэмь-восэмь". Откуда Вы узнаете, каким именно по порядку будет среплицирован именно этот документ? Где гарантия, что он будет доставлен именно в эту репликацию, вдруг она оборвётся? Были случаи из практики, когда большие документы ползли по "узкому" каналу несколько дней.

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

 

[Znake]

Хотя и не уверен в своей правде.

писал по памяти не глядя в справку, надеясь что топиккастер сам это сдает. Поэтому и вроде.
Ну да ладно.

что клиент нотес эту информацию выводит в окне репликатора или в прогресс баре,

А что тогда мешает запускать оттуда ?

 

[Akupaka]

А что тогда мешает запускать оттуда ?

Запскать межсерверную реплиацию из клиента? Так она ж от имени пользователя и будет выполняться!

 

[Anonimous]

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

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

 

[lmike]

Средства мониторинга строятся на логах, но отслеживать репликацию таким способом очень затратно.

весь мир так живет - мониторинг на логах

 

[Wanderstep]

Domino domain monitoring - гуглим в этом направлении.
Там централизованно мониторить можно всё, что угодно.
В том числе, и ваши репликации через replication probes.

Настройка DDM производится через Monitoring Configuration application (EVENTS4.NSF)

 

[rinsk]

Вернее на SysLog-ах ))
На коленках- поднять везде логирование в syslog, можно еще SNMP,+trap - логирование в log.nsf по моему можно отключить и хранить все в файлах с ротацией.
Но на такое кол-во серверов и точек контроля нужны соотв. системы типа HP OpenView и т.п. С соответствующей серьезной постановке задач и его решению. У IBM наверняка есть решения.