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

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

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

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

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

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

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

Я прав?

Спасибо.

Ответ 1

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

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

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

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

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

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

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

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

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

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

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

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

Приветствия, Джон

Ответ 2

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

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

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

Ответ 3

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

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

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

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

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