Репликация одноранговых узлов в SQL Server 2005/08

Question

Имеет ли кто-либо опыт настройки peer to peer replication с использованием SQL Server 2005 или 2008?

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

Если вы использовали репликацию P2P:

Были ли у вас какие-либо проблемы во время синхронизации и было ли легко контролировать?

Насколько легко было/было разрешение конфликтов?

Вам нужно было внести изменения схемы (т. Е. Заменить столбцы идентификации и т. Д.)?

В качестве альтернативы, если вы рассматривали репликацию P2P и пошли с другим вариантом, почему вы это исключили?

Answer 1

(Отказ от ответственности: я являюсь разработчиком, а не DBA)

У нас есть сервер репликация 2005 слияния SQL настроить репликацию между двумя активными/активными географически разделенными узлами для обеспечения устойчивости в прежней системе.

Я не знаю, легко ли его контролировать; вне моей компетенции.

Он создает триггеры в каждой таблице для создания механизма публикации/подписания, каждый из которых вызывает свою собственную хранимую процедуру.

В нашем случае он был настроен на использование тождеств 1-1bn в узле 0, 1bn-2bn в узле 1, чтобы избежать конфликтов идентичности (вместо использования составного ключа NodeId + EntityId для каждой таблицы или изменения ключей например GUID).

Я думаю, что латентность репликации составляет около 15 с (между Лондоном и Нью-Йорком по выделенной полосе пропускания).

Это огромная боль для работы с:

• Потребовалось высокооплачиваемую подрядчику в год, чтобы установить его (как должное, часть это было связано с унаследованной природы дизайна БД)
• у нас нет никого в доме с опытом, чтобы поддержать его (АБД в доме мы приняли ~ 6 месяцев, чтобы узнать его, и с тех пор перешел)
• обновлений схемы теперь болезненного.Из того, что я понимаю:
  • Некоторые обновления должны выполняться только на одном узле; Репликация затем берет на себя выяснить, что делать на другом узле (ов)
  • Некоторые обновления должны быть выполнены на обоих узлах
  • обновления данных должны быть выполнены на одном узле только (я думаю)
  • Все обновления в настоящее время требуется значительно больше времени - от сплит-секунд, необходимых для запуска сценария изменения DDL до ~ 30 минут
• Я не знаю точно, но я думаю, что требование пропускной способности для репликации очень велико (в диапазоне MBit/s)
• В нем представлено много «шумовых» объектов (3 строки в таблице, 3 триггера на таблицу) в базу данных, что затрудняет поиск в объектном проводнике объекта, над которым нужно работать.
• never установил третий узел для этой системы, основанный в основном на воспринимаемой сложности и дополнительной боли, которую она представила во время развертывания.
• У нас также нет промежуточной среды, которая отражает производство, потому что это слишком болезненно для настройки.
• Anecdotal: DBA, выполняющий настройку, часто проклинал факт, что это был «MS v1», с которым он был вынужден работать.
• Dimely помнил: администратору базы данных необходимо было поднять несколько приоритетных билетов поддержки, чтобы получить помощь от MS напрямую.

Предоставлено - часть боли связана с нашей конкретной средой и не имеет собственного таланта для поддержки этой установки. Ваш пробег может отличаться.