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

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

6 голосов
/ 26 октября 2008

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

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

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

Были ли у вас какие-либо проблемы во время синхронизации, и было ли это легко контролировать? Насколько легко / легко было разрешить конфликт? Пришлось ли вам вносить изменения в схему (т.е. заменять столбцы идентификаторов и т. Д.)?

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

1 Ответ

2 голосов
/ 26 октября 2008

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

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

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

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

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

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

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

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

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

...