Одноранговая репликация в SQL Server 2005/08

Question

Был ли у кого-нибудь опыт настройки одноранговая репликация используя SQL Server 2005 или 2008?

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

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

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

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

Пришлось ли вам вносить изменения в схему (т.заменить столбцы идентификаторов и т. д.)?

С другой стороны, если вы рассматривали возможность репликации P2P и выбрали другой вариант, почему вы его исключили?

Answer 1

(Отказ от ответственности:Я разработчик, а не администратор базы данных)

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

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

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

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

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

Это огромная боль, с которой работать:

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

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