Каковы сценарии использования зеркалирования, доставки журналов, репликации и кластеризации в SQL Server

Question

Насколько я знаю, SQL Server предоставляет 4 метода для лучшей доступности.

Я думаю, что это основные сценарии использования, в итоге: -

1) Репликация в первую очередь подходит для сценариев синхронизации данных в режиме офлайн (ноутбук, мобильные устройства, удаленные серверы).

2) Доставка журналов может использоваться для резервного сервера с переключением вручную, тогда как

3) Зеркальное отображение базы данных - это метод автоматического переключения при сбое

4) Отказоустойчивая кластеризация - это расширенный тип зеркалирования базы данных.

Я прав?

Спасибо.

Answer 1

Отказоустойчивая кластеризация - это технология доступности, которая обеспечивает избыточность на аппаратном уровне и построена на основе технологии кластеризации Windows, т. Е. Она не специфична для SQL Server.

Например, процессор взорвался на сервере A. К счастью, сервер A является частью кластера SQL Server, и поэтому сервер B берет на себя работу по предоставлению службы SQL Server в течение нескольких секунд. Все это происходит автоматически и прозрачно для пользователей базы данных и / или приложения, обслуживаемого кластером.

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

Следующая ссылка обеспечивает сравнение между этими двумя технологиями, которые могут вам пригодиться.

http://msdn.microsoft.com/en-us/library/ms191309(SQL.90).aspx

Доставка журналов считается более избыточной технологией.

Например, его можно использовать для предоставления полной копии вашей основной среды, обычно используемой в качестве «горячего» резервирования, который можно вручную подключить к сети. Это может быть использовано для обеспечения дополнительной избыточности в вашей стратегии резервного копирования. Доставка журналов также может использоваться для разгрузки отчетов с основного сервера путем создания копии рабочей базы данных только для чтения в альтернативном местоположении / сервере.

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

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

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

Транзакционная репликация может использоваться аналогичным образом для регистрации доставки, однако вы можете ограничить определенные объекты, которые реплицируются для подписчика. Это может быть полезно, если для отчетности требуется только подмножество таблиц.

Надеюсь, это немного прояснит для вас. Вы можете найти множество документации по каждой из этих технологий в книгах по SQL Server в Интернете или по поиску каждой технологии в Google. Тем не менее, если у вас есть какие-либо конкретные вопросы, я был бы рад помочь, поэтому не стесняйтесь, напишите мне.

Ура, Джон

Answer 2

В SQL 2008 Enterprise также есть что-то, называемое Change Data Capture (CDC), которое мы успешно используем там, где я работаю.

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

Это работает очень хорошо для нас.

Answer 3

AFAIK доставка журналов и репликация, вероятно, будут лучше подходить наоборот.

Доставка журналов - это запланированная синхронизация, поэтому репликация лучше подходит для ручного переключения, поскольку сервер резервного копирования будет обновлен настолько, насколько это возможно, если у вас не возникнет проблем со связью (однако доставка журналов будет иметь такую ​​же проблему). ).

офлайн-данные не так чувствительны к задержкам, как сервер резервного копирования, но лично я вообще не вижу необходимости в доставке журналов, я не вижу, когда это будет более подходящей альтернативой к репликации (но может быть, что репликация не была реализована до sql2005)

Возможно, я путаю репликацию с зеркалированием, и, как примечание, зеркалирование не дает вам автоматического переключения при отказе, только HA-кластер предоставляет вам такую ​​функциональность, что означает:

с использованием по крайней мере стандарта SQL Server 2005, Windows Enterprise и общего хранилища данных (например, SAN).