Проблема заключалась в том, что у одного из подписчиков были старые публикации и подписки в системных таблицах, которые были реплицированы по всей системе. Что вызвало нарушение ограничения UNIQUE KEY.
Как только мы удалили эти старые объекты, мы смогли перезапустить репликацию.
Нам удалось идентифицировать действительные записи в sysmergepublication, потому что мы знали состояние этой таблицы до того, как недопустимые записи были реплицированы. В этом сообщении на форуме показано, как найти недействительные публикации, если вам нужно.
Мы использовали следующий sql для проверки дополнительных записей подписки:
select *
from sysmergepublications
select *
from sysmergesubscriptions
where pubid in ( select pubid from sysmergepublications)
select *
from sysmergesubscriptions
where pubid not in ( select pubid from sysmergepublications)
Вот sql, который мы использовали для удаления недействительных подписок:
delete from sysmergesubscriptions
where pubid not in ( select pubid from sysmergepublications)
Примечание. В приведенном выше примере кода предполагается, что публикация sysmergepublication содержит только допустимые публикации
В качестве альтернативы: Вы можете использовать EXEC sp_removedbreplication @dbname='<dbname>'
для полного удаления репликации из базы данных. Эта команда выводит все триггеры репликации из базы данных.