Чтобы добавить больше о репликации транзакций:
- он использует задание чтения журнала агента SQL для сбора зафиксированных транзакций из журнала транзакций базы данных публикации. Это означает, что журнал нельзя очистить, пока не будут прочитаны записи журнала. Если периодичность агента чтения журнала изменена, ваш журнал может неожиданно вырасти. Агент чтения журнала также может вызвать конфликт в журнале транзакций в OLTP-системах большого объема, конечно, в зависимости от вашей подсистемы ввода-вывода.
- Репликация не гарантирует нулевую потерю данных, поскольку существует задержка, связанная с чтением записей журнала и их передачей через дистрибьютора подписчику (ам). Для нулевой потери данных обратите внимание на синхронное зеркальное отображение базы данных или синхронную репликацию SAN.
- Одноранговая репликация - хороший способ масштабирования рабочей нагрузки запросов, а также может добавить некоторую избыточность вашим данным
- вам необходимо тщательно разработать схему с одноранговой связью, чтобы избежать коллизий, вызванных аналогичными изменениями на разных узлах. Не используйте для этого разделенные идентификаторы. Используйте составной суррогатный ключ (например, идентификатор узла + bigint)
- с одноранговой связью может быть сложно добавить дополнительную избыточность для различных узлов в топологии. Издателя можно отразить, подписчика можно отразить (достаточно легко в 2008 году, не так просто в 2005 году), а распространитель - нет. Его необходимо кластеризовать, чтобы добавить избыточность.
Несколько мыслей. Вы также можете проверить технический документ по зеркалированию + ответ, который я написал в прошлом году на http://download.microsoft.com/download/d/9/4/d948f981-926e-40fa-a026-5bfcf076d9b9/ReplicationAndDBM.docx
Изменить: хорошо - это обед, и мне нужно добавить еще:
- одноранговая репликация: в 2005 году, если вы хотите вообще изменить топологию (добавить или удалить узлы), вы должны заморозить всю топологию. В 2008 году этого не нужно.
- Одноранговая репликация не обнаруживала конфликтов до 2008 года, но даже в этом случае разрешение конфликтов практически бессмысленно - побеждает узел с наивысшим идентификатором (называемым идентификатором однорангового отправителя) - возможно, это не то, что вам нужно.
- одноранговая репликация: все узлы видят все изменения от других узлов. Это означает, что в трехсторонней топологии, скажем, с Сиэтлом, Лондоном, Токио - если Сиэтл рухнет, Лондон и Токио продолжат работу. Если затем Токио рухнет и Сиэтл подключится к сети, он будет получать все лондонские обновления из Лондона И все токийские обновления, о которых знает Лондон, из Лондона. Довольно аккуратно.
- нет никакой формы обнаружения сбоев или автоматического переключения при отказе с репликацией. Может, вместо этого посмотрите на зеркалирование. Думаю, вы могли бы использовать какую-то форму NLB.
При выборе любого решения высокой доступности (удачное время, поскольку сегодня я преподаю класс высокой доступности для внутренних администраторов баз данных Microsoft), вам нужно начать с анализа требований, прежде чем оценивать технологии. Сложно давать рекомендации, не зная всех ваших требований.
Я написал в блоге о вопросах, которые нужно задать себе при разработке стратегии высокой доступности: см. http://www.sqlskills.com/BLOGS/PAUL/post/HA-Where-do-you-start-when-choosing-a-high-availability-solution.aspx
Снова отредактируйте:
- Пример его использования: различные серверы на уровне данных с балансировкой нагрузки среднего уровня. Одноранговая связь позволяет всем узлам поддерживать (в конечном итоге) синхронизацию.
- Однако неприятная проблема: если пользователь перенаправлен на узел 1 и выполняет транзакцию, сколько времени до того, как данные будут реплицированы на другие узлы, поскольку задержка ответа может варьироваться? Если пользователь снова подключится к сервису, к какому узлу его направить? Тот же узел, что и раньше, или прошло достаточно времени, чтобы иметь возможность безопасно маршрутизировать к любому узлу и гарантировать, что предыдущая транзакция, которую она совершила, была реплицирована на все узлы?
ок - больше никаких правок! :-)
Репликация - это довольно разноплановая технология, которую можно использовать для различных сценариев, выбор которых будет определять конкретный тип репликации, которая реализуется.
Например, репликация слиянием может использоваться для поддержки распределенной обработки путем распределения рабочей нагрузки приложения по нескольким серверам, то есть архитектурам распределенной обработки.
Для репликации слиянием часто требуется приложение, которое относительно осведомлено о своей среде. Такие методы, как разрешение конфликтов, также должны быть приняты во внимание, чтобы гарантировать согласованность данных во всей интегрированной среде.
Репликацию транзакций можно использовать аналогично доставке журналов, однако вы можете ограничить количество конкретных объектов, которые реплицируются подписчику. Это может быть полезно, если для целей отчетности требуется только подмножество таблиц.
Полный список доступных архитектур см. В следующем справочнике по репликации Microsoft.
http://msdn.microsoft.com/en-us/library/ms151827.aspx
Тип используемой репликации определит тип проблем, с которыми вы можете столкнуться и которые необходимо учитывать. Например, репликация слиянием требует, чтобы изменения схемы были внесены в вашу базу данных.
Также необходимо принять во внимание соображения безопасности, например, если ваши данные будут реплицированы через общедоступный Интернет, или потребуется ли или потребуется ли шифровать сообщения и т. Д.
Репликация - большая тема, но я надеюсь, что эта информация направит вас в правильном направлении.
Если вам необходимо отключить репликацию по какой-либо причине и перезапустить ее (или просто запустить в первый раз), это может привести к тому, что ОБЕИ серверы почти не отвечают во время обработки. Однако после запуска (и оставления в покое) это не заметно (по крайней мере, для нас).