Одноранговая репликация в SQL Server 2005/08
У кого-нибудь был опыт настройки одноранговая репликация с использованием SQL Server 2005 или 2008?
В частности, меня интересует, рассматривались ли другие варианты / альтернативы и почему в конечном итоге была выбрана репликация P2P.
Если вы использовали репликацию P2P:
В качестве альтернативы, если вы рассматривали репликацию P2P и выбрали другой вариант, почему вы исключили ее?
К сожалению нет! Я действительно очень хотел получить обратную связь / опыт, потому что я не видел репликации P2P в производственной среде (пока).
Ответы 1
(Отказ от ответственности: я разработчик, а не администратор базы данных)
У нас есть репликация слиянием SQL Server 2005, настроенная для репликации между двумя активными / активными географически разделенными узлами для обеспечения устойчивости в устаревшей системе.
Я не знаю, легко ли это контролировать; вне моей компетенции.
Он создает триггеры для каждой таблицы для выполнения механизма публикации / подписки, каждый из которых вызывает свою собственную хранимую процедуру.
В нашем случае он был настроен на использование идентификаторов 1-1bn в узле 0, 1bn-2bn в узле 1, чтобы избежать конфликтов идентификаторов (вместо использования составного ключа NodeId + EntityId для каждой таблицы или изменения ключей на GUID, Например).
Я думаю, что задержка репликации составляет около 15 секунд (между Лондоном и Нью-Йорком по выделенной полосе пропускания).
Это огромная боль работать с:
- На его установку у высокооплачиваемого подрядчика ушло год (конечно, частично это было связано с унаследованным характером дизайна БД)
- Нам не хватает кого-нибудь в штате, обладающего опытом, чтобы поддержать его (штатному администратору баз данных у нас потребовалось ~ 6 месяцев, чтобы изучить его, и с тех пор он перешел)
- Обновления схемы теперь болезненный. Насколько я понимаю:
- Определенные обновления должны выполняться только на одном узле; затем репликация заботится о том, чтобы выяснить, что делать на другом узле (ах)
- Определенные обновления должны выполняться на обоих узлах
- Обновление данных должно производиться только на одном узле (я думаю)
- Все обновления теперь занимают значительно больше времени - от доли секунды, необходимой для запуска сценария изменения DDL, до ~ 30 минут.
- Я не знаю точно, но думаю, что требования к пропускной способности для репликации очень высоки (в диапазоне МБит / с)
- Он вводит в базу данных «шумовые» объекты много (3 спрока на таблицу, 3 триггера на таблицу), что затрудняет поиск в проводнике объектов элемента, над которым нужно работать.
- Мы настроим никогда третий узел для этой системы, в основном, исходя из предполагаемой сложности и дополнительных проблем, которые она может вызвать во время развертывания.
- Также нам сейчас не хватает промежуточной среды, отражающей производство, потому что ее слишком болезненно настраивать.
- Анекдотический: администратор базы данных, выполняющий настройку, часто проклинал тот факт, что его заставляли работать именно с «MS v1».
- Смутно вспомнил: администратору базы данных нужно было поднять несколько заявок на приоритетную поддержку, чтобы получить помощь напрямую от MS.
Конечно, некоторые проблемы связаны с нашей специфической средой и отсутствием штатных специалистов для поддержки этой установки. Ваш пробег может отличаться.
(Репликация PTP не имеет ничего общего с репликацией слиянием. Она работает с репликацией транзакционного канала, где все серверы являются издателями / подписчиками). Я действительно удивлен вашими комментариями по репликации слиянием, обновлениям схемы и проблемам с пропускной способностью. Можете ли вы подтвердить это, или это всего лишь то, что вы слышали?
Это проблемы, с которыми я должен помочь во время развертывания в 5 часов утра. (Спасибо за разъяснение PTP и репликации слиянием; я не понимал, что это две разные вещи.)
Роб - вы когда-нибудь настраивали одноранговую репликацию или получали лучший ответ (ответ Питера касался его опыта с репликацией слиянием, а не P2P)