Фундаментальная Проблема: Различия В Репликах На Уровне Полей

[severov]

Уважаемые коллеги,

Приходилось ли вам видеть различия в репликах на уровне полей? Когда "Modified (Initially)" у документов одинаковые, но содержимое отличается (брр...)
Нет? Никогда? Может пора проверить?

В моей компании это обнаружилось более года назад, во многих базах и серверах, и даже в кластерных парах. Мы пытаемся это исправить, но, к сожалению, без особых успехов (даже с помощью от IBM).

Поэтому... Если хотите проверить свои базы - можете воспользоваться инструментом "ReplicasMatcher". Он предназначен для сравнения документов из разных реплик, на уровне полей. Также возможно слияние различающихся документов.
Пожалуйста, скачайте отсюда -

Ссылка скрыта от гостей

(все руководства можно найти на страницах About и Using).

Если вы уже сталкивались с подобными проблемами или обнаружили их с помощью ReplicasMatcher - пожалуйста дайте мне знать.
Хорошо знать, что ты не одинок в борьбе с такой бедой

Желаю всем удачи,
Павел Северов
severov@gmail.com

 

[lmike]

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

 

[Crock]

Можно поподробнее - при каких условиях, в каких релизах вылезает эта ошибка?
Очень уж устрашающе звучит B)

 

[severov]

> есть рассинхронизация часов на серверах...
У меня были сомнения на этот счёт. Проверял, скрипт написал. Никакого криминала найти не смог. Точно сейчас не помню, но если что и было, то гораздо меньше секунды.
А большая должна быть разница в часах, чтоб начались траблы? Дайте, пожалуйста, ссылочку на соотв. описание проблемы и/или измерительный инструмент.

> есть селективные реплики, бывает ограничение по объему репликации (partial),
Ну это же не может быть причиной пропуска некоторых полей в некоторых документах при репликации?
Всё это происходит довольно редко и нерегулярно. Но если база с большим количеством документов, и интенсивно обновляемых реплик по всему миру, то эта дрянь в конце-концов вылезает.

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

> коротко описать (скопировать) эбаут
Вот, пожалуйста:

What's inside:
Agent compares each field in the documents by notesItem.Text property.
If content is not matched then agent compares notesItem.LastModified properties.
Field with latest notesItem.LastModified wins in the merging.
In case of equal notesItem.LastModified of at least one field in the document agent skip its merging (as it can't choose field-winner)
Merging consist of updating of only doc1 (FilePath1 @ Server1)
Backup copy of each merged field is saved to FieldName$RM# field
Log of merging is saved to RepMtchTrack# field of each document
Each merging session must be preceded and followed by replication of merged replicas.
Agent ignores all documents with unmatched timestamps (not yet replicated) and documents which are absent
"Run (detect only)" works in the same way as "Run (detect and merge)", but without document's saving
It is safe to run agent repeatedly
Log file automatically opens after session completion
Run Time Errors can occurs on the merging. They are not often and related to manipulation with rich text fields. Total number of Run Time Errors is presented in the log.

 

[savl]

Может у кого с английским плохо.
<div class="sp-wrap"><div class="sp-head-wrap"><div class="sp-head folded clickable">Примерный перевод</div></div><div class="sp-body"><div class="sp-content">Агент сравнивает каждое поле в документах через свойство notesItem.Text
Если содержимое не соответствует, то агент сравнивает свойства notesItem.LastModified
Поле с последними notesItem.LastModified используется для слияния.
В случае равенства notesItem.LastModified агент не будет объединять поля, так как не может выбрать правильное.
Слияние заключается в обновлении только doc1 (FilePath1 @ Server1)
Резервная копия каждого объединенного поля сохраняется в FieldName $ RM поле #
Log слияния сохраняется в RepMtchTrack# поле каждого документа
Каждый процесс слияния должен предшествовать и следовать за репликацией.
Агент игнорирует все документы с не совпадающим временем (еще не реплицировались) и документы, которые отсутствуют
"Run (detect only)" работает точно так же, как «Run Run (detect and merge)", но без сохранения документа
Это безопасно для запуска агента неоднократно (или теста)
Лог-файл автоматически открывается после завершения работы.
RunTime ошибки могут происходит во время слияния. Они не постоянны и связаны с манипуляцией RichText полей.
Общее число ошибок во время выполнения представлены в лог-файле.

От себя добавлю, что проверял на своих базах. Нашел только конфликты.
Сервера не так далеко друг от друга, Москва-Тверь.

 

[severov]

Релизы самые разнообразные - от R7 до R85. У админов (я-разработчик) есть идея, что очередной апгрейд поможет. Может что-то и помогает, но пока не очень ощутимо.

Условия и признаки следующие:
При репликации игнорируются некоторые обновлённые, удалённые или изменённые поля.
Всё это происходит довольно редко и нерегулярно.
Следующие условия увеличивают шанс возниконовения очередных ошибок:
- база с большим количеством документов
- много реплик в разных часовых зонах
- все реплики интенсивно обновляются

 

[ToxaRat]

ни разу такое не замечал

 

[VladSh]

Посмотрите в ченьжлоге на 9-ку, они там по репликации много поправили; меня это сильно удивило, т.к. раньше репликатор не сильно трогали, - 2-3 трабла исправляли в каждом релизе, не больше.

 

[susinmn]

Если вы уже сталкивались с подобными проблемами или обнаружили их с помощью ReplicasMatcher - пожалуйста дайте мне знать.

Даю знать .

Не так давно одно поле не реплицировалось, в документе create conflict.

Есть случаи, что на некоторых серверах в документе обнуляются почти все поля, в том числе и form. Причем, если *нормальный* документ править, данные в *битый* не приходят, а вот если *битый* сохранить все пустые поля переливаются в *нормальный* и он превращается в битый. В документе merge conflict.

Были случаи: на одном сервере документ(unid1) к нему конфликт(unid2); на другом документ(unid2) основной, а к нему конфликт(unid1).

Выйду с больничного, прогоню в некоторых бд, спасибо.