Репликация SQL Server – это мощная функция, которая позволяет реплицировать данные между несколькими серверами. Однако иногда могут возникать проблемы при попытке реплицировать изменения схемы. В этой статье мы рассмотрим реальный сценарий, когда репликация схемы не работала ожидаемым образом и как она была устранена.

Представьте себе ситуацию, когда у нас есть два кластера SQL Server, ServerA и ServerB, оба работающих на SQL Server 2008 R2 Enterprise Edition. У этих серверов есть идентичная база данных с названием “MyDatabaseA”, и между ними настроена репликация Peer-to-Peer для некоторых таблиц внутри “MyDatabaseA”. Эта конфигурация работала должным образом в течение длительного времени.

Однако, когда возникла необходимость добавить дополнительные столбцы в одну из реплицируемых таблиц, изменения схемы не реплицировались ожидаемым образом. Если новые столбцы были добавлены на ServerA, они не могли быть реплицированы на ServerB. Однако, если новые столбцы были добавлены на ServerB, они успешно реплицировались на ServerA.

Эта проблема смутила администраторов, так как репликация данных работала нормально, и в мониторе репликации или журнала ошибок SQL Server не было ошибок. Согласно Microsoft Book Online, репликация Peer-to-Peer должна быть способна реплицировать изменения схемы с обеих сторон, и необходимая настройка уже была включена.

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

На этом этапе возникла смутная идея – могут ли быть триггеры в “MyDatabaseA” ServerA, которые препятствуют или откатывают изменения схемы? После дальнейшего исследования было обнаружено, что на обоих экземплярах SQL было создано четыре триггера: tr_MStran_alterschemaonly, tr_MStran_altertable, tr_MStran_altertrigger и tr_MStran_alterview.

Эти триггеры были связаны с репликацией SQL Server и оказались отключены на ServerA, в то время как на ServerB они были включены. Включение этих триггеров на ServerA немедленно устранило проблему репликации схемы с ServerA на ServerB.

Дальнейшее исследование показало, что эти триггеры действительно необходимы для репликации SQL Server. Однако причина, по которой они были отключены на ServerA, остается неизвестной. Тем не менее, проблема была устранена, и репликация схемы работала правильно.

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

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