Я изучаю высокую доступность SQL Server для своей диссертации. Я узнал, что есть несколько способов заархивировать это:
Насколько мне известно, эти решения поддерживались в предыдущей версии SQL Server 2008. SQLS 2008 обеспечивает зеркальное отображение базы данных, которое предполагается как лучшее решение. Я очень сомневаюсь в этом. Не могли бы вы рассказать мне о минусах и плюсах этих решений, какие стратегии их следует использовать, а какие нет. Подробная информация и объяснение мне очень помогут
Большое спасибо.
Доставка журналов:
Обзор: транзакции на главном сервере ставятся в очередь на диск, а затем отправляются на зеркало в соответствии с расписанием репликации. Журналы применяются к зеркальной базе данных по расписанию.
Выпуск SQL: стандартный, корпоративный
Усилия администратора: настроить общий сетевой ресурс на зеркале в качестве места для хранения журналов транзакций, запустить мастер SQL для настройки
Автоматическое переключение при отказе: невозможно, если не присутствует следящий сервер
Ручное переключение при отказе: включает в себя применение файлов журнала незафиксированных транзакций к базе данных.
Проблемы, связанные с ошибкой: средний, поскольку он полагается на Windows для представления общего сетевого ресурса на зеркале. Если применение журналов транзакций на зеркале прекратится, они будут накапливаться.
Ввод / вывод: выше, чем зеркальное отображение
Зеркальное отображение:
Обзор: транзакции с принципалом фиксируются на основе принципала и отправляются на зеркало. Когда зеркало фиксирует транзакцию, оно сообщает принципалу, что готово для другой транзакции.
Версия SQL: предприятие
Автоматическое переключение при отказе: невозможно, если не присутствует следящий сервер
Ручное переключение при отказе: при наличии подключения переключите режим зеркалирования на синхронный. Если подключение отсутствует, выполните инструкцию SQL для выполнения принудительного восстановления службы. Затем пары могут быть повторно синхронизированы
Производительность: низкая по сравнению с доставкой журналов
Персональная лабораторная работа:
Проведено с использованием SQL 2005 Standard и Enterprise.
Я обнаружил, что доставка журналов - это хорошая идея на бумаге, но в моей лаборатории ее было сложно настроить и выполнить аварийное переключение. Зеркалирование было очень элегантным, и я точно знал, что транзакции совершаются для обеих пар.
Когда приходит время сделать цель основной, я не хочу возиться с применением файлов журнала транзакций. Если вам нужен короткий RTO, я бы попробовал зеркалирование.
Вам нужно будет узнать больше о синхронном (транзакция фиксируется в обеих парах, прежде чем помечена как завершенная) и асинхронном (фиксация на основном сервере, затем отправка на целевой) режимах репликации для зеркальной пары. В локальной сети вы можете запускать их в синхронном режиме, но в глобальной сети вам придется следить за задержкой в синхронном режиме (менее 10-20 мсек), иначе ваше время отклика на приложение замедлится.
Обратите внимание, что только выпуск SQL 2005 Enterprise поддерживает асинхронный режим, который также называется «режимом высокой производительности» или отключение свойства БЕЗОПАСНОСТЬ на сервере SQL.
Извините, у меня нет опыта кластеризации.
Источники MSDN
Обзор зеркального отображения базы данных http://msdn.microsoft.com/en-us/library/ms189852%28SQL.90%29.aspx
Брент хорошо рассказал о доставке журналов и зеркалировании базы данных, поэтому я не буду вдаваться в подробности. Обязательным к прочтению по этой теме является книга Аллана Хирта. Pro SQL Server 2005 Высокая доступность. Я знаю, что это для 2005 года, но на 95% это актуально и для SQL Server 2008. Вы должны прочитать это, чтобы иметь хорошее представление о доступных вариантах. Вот мои дополнения к ответу Брента:
Отказоустойчивая кластеризация
Если финансовые, энергетические ресурсы и ресурсы серверной комнаты не являются ограничением, то это мой предпочтительный выбор для обеспечения высокой доступности для SQL Server. Вам нужно общее дисковое хранилище, обычно SAN, чтобы это работало, и я предпочитаю размещать диски C в SAN для упрощения аварийного восстановления. Я настроил его так: иметь кворум LUN (Q), MSDTC LUN (M) и точку монтирования для каждого экземпляра SQL Server в кластере. В точке монтирования настройте LUN для SQLData, SQLLogs, SQLBackups и, возможно, SQLtempdb. Для ОДНОГО экземпляра вы получите D: \ SQLData, D: \ SQLLogs, D: \ SQLBackups, D: \ SQLtempdb (например). Для следующего экземпляра у вас могут быть E: \ SQLData, E: \ SQLLogs, E: \ SQLBackups, E: \ SQLtempdb. Все общие диски должны быть представлены всем узлам кластера. Переход на другой ресурс происходит автоматически и в моей производственной среде занимает около 20 секунд. Это надежно, но может быть сложно настроить, если у вас нет опыта.
Виртуализированные серверы SQL
Вариант, который вы не изучали, - это использование сервера vmware ESX для размещения серверов баз данных. Мне очень нравится этот вариант, но пока я не уверен, что смогу развернуть его в производственной среде. Я очень успешно развернул его в непроизводственной среде, и технология выдающаяся. Я думаю, что он подходит только для умеренно или слабо загруженных SQL-серверов и не должен использоваться, если производительность критична или у вас высокие рабочие нагрузки. Сопоставление SQL Server с хостами ESX один к одному - очень желательная конфигурация. vmware VMotion - отличная технология с гораздо более коротким временем простоя, чем отказоустойчивый кластер. Однажды я видел демонстрацию видео, воспроизводимого на сервере, и сервер был отключен, видео работало без сбоев. Это впечатляет!
Репликация SQL Server
Это может не работать для сторонних приложений, поскольку может потребовать изменения схемы. Репликация SQL Server не была разработана для обеспечения высокой доступности, скорее она была разработана для того, чтобы копии данных были доступны в других местах. Я бы не рекомендовал использовать это для высокой доступности из-за его сложности. Однако он может быть полезен в определенных сценариях из-за низкого уровня детализации, который он предлагает - например, вы можете выполнять горизонтальное и вертикальное разбиение данных.
Сторонняя репликация дисков
Такое решение, как двойной дубль NSI, также можно рассматривать для обеспечения высокой доступности, однако я предпочитаю использовать его для аварийного восстановления систем, не основанных на SAN. Он в основном реплицирует данные на уровне блоков на целевой сервер, а целевой сервер наблюдает за исходным сервером на предмет доступности. Если он становится недоступным, он запускает условие аварийного переключения, и вы можете настроить его на автоматическое переключение при сбое или оповещение о переключении вручную. Время восстановления при отказе аналогично кластеризации SQL Server. Преимущества заключаются в том, что для этого не требуется никакого специального оборудования, но лицензии на программное обеспечение могут быть дорогими.
Резервное копирование и восстановление
Не совсем решение для высокой доступности, но для некоторых людей с более слабыми требованиями это очень простое решение может предложить все, что вам нужно. Просто создайте резервную копию баз данных по расписанию на сервере резервного копирования и убедитесь, что файлы резервных копий доступны на целевой машине. Настройте задание на восстановление файлов по мере их резервного копирования, и вы получите недорогое грубое решение для обеспечения высокой доступности.