Что происходит во время репликации между серверами, если доступ для чтения отменяется

Question

Я хотел бы понять, что происходит в следующем сценарии репликации сервера Lotus-Domino на сервер:

• Сервер A имеет точную копию базы данных.
• Сервер B имеет реплику той же базы данных.
• Оба сервера имеют доступ менеджера к базе данных, включая привилегию удаления документа.
• Процесс репликации только что реплицировал A и B, и все синхронизировано.
• База данных содержит заметку с полем для чтения, где упоминаются оба сервера.
• На сервере A запись для сервера B удалена из поля считывателей.
• Сервер A инициирует репликацию с B.

В этом сценарии я ожидаю, что сервер A удалит документ с сервера B. В этом сценарии существуют разные варианты: сервер C реплицируется с B, B инициирует репликацию с A.

У меня есть приложение, построенное на основе этого ожидания, и оно работало в большинстве случаев. Но есть заметки, которые остаются на сервере B и исключены из процесса репликации. OID остается другим. В некоторых случаях DSN обновляется в обеих заметках без какого-либо результата в процессе репликации.

Answer 1

На самом деле, я не согласен с ответом AndrewB.По моему опыту, это должно работать в соответствии с вашими ожиданиями.Использование полей readernames для управления репликацией является частью моего стандартного арсенала уже более 15 лет, и я обнаружил, что он гораздо более надежен, чем альтернатива выборочной репликации - что является злом и его следует избегать любой ценой, но это уже другая история!

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

Вы пытались очистить историю репликации с обеих сторон?

Answer 2

IBM создала SPR для этого:

Проблема Обычно, когда сервер удаляется из поля читателя документа, после выполнения запланированной репликации документудаляется с сервера, поскольку этот сервер больше не имеет доступа к документу.В некоторых случаях, когда вторичный сервер удаляется из поля считывателя документа, находящегося на первичном сервере, после репликации между двумя серверами документ не удаляется со вторичного сервера, как ожидается.Включение отладки репликации выявляет следующую ошибку на исходном сервере: «Вы не авторизованы для выполнения этой операции».Очистка журнала репликации и запуск репликации с обоих серверов не решают проблему.В ходе дальнейшего расследования было установлено, что документ на вторичном сервере имеет более высокий порядковый номер, что означает, что он был обновлен позднее, чем документ на первичном сервере.Обычно, когда документ не содержит поля считывателя или если оба сервера, участвующие в репликации, перечислены в поле считывателя обеих копий документа, конфликт репликации будет создан, когда документ будет изменен на обоих серверах до начала репликации.,Однако в этой конкретной ситуации, поскольку вторичный сервер не имеет доступа к документу на первичном сервере, репликация завершается неудачно, как и ожидалось, и конфликт репликации не создается, поскольку для генерации конфликтного документа оба сервера должныиметь доступ к документу.

Решение проблемы 1.) Краткосрочным решением будет изменение документа на первичном сервере так, чтобы его порядковый номер был больше, чем документ на вторичном сервере.После того, как репликация произойдет, изменения должны реплицироваться на вторичный сервер, а документ должен быть удален со вторичного сервера, как и ожидалось.2.) Более постоянное решение - запретить пользователям и серверам вносить изменения в документ на обоих серверах одновременно.Кроме того, более частая репликация должна снизить вероятность возникновения такого условия, поскольку изменения, внесенные на одном сервере, возможно, будут реплицированы до того, как изменения будут внесены на другом сервере.Эта проблема отслеживается в SPR MKHS8MLQVD

Answer 3

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

Причина, по которой документы остаются / не обновляются на сервере B, заключается в том, что удаление сервера B из поля считывателя в документе делает его невидимым для сервера, поэтому он не подозревает, что он был изменен или удален. Причина, по которой удаление на сервере A было выбрано сервером B, заключается в том, что при удалении документ конвертируется в заглушку удаления, которая немного больше UNID, поэтому поле считывателей также делает удаление «видимым» для сервера B. Вы не можете даже вынудите сервер A выполнить запись на сервер B, потому что сервер A будет знать, что серверу B не разрешено видеть документ, поэтому принудительная репликация будет игнорировать данный документ.

Answer 4

У нас было что-то подобное, когда мы консолидировали серверы, и у нас это не получилось. Если я использую сценарий «ваш сервер А / сервер Б», то у нас получилось, что сервер Б реплицировался на сервер А, а документ исчез с сервера Б. К сожалению, это было отслежено как удаление, поэтому при повторной репликации А и Б документы были удалены с сервера. A.

К счастью, у нас были резервные копии.