Мы находимся в процессе создания нашей производственной среды для будущего веб-продукта. Для этого стека основной SQL Server 2008 будет использоваться для операций с живой базой данных, а вторичный SQL Server 2008 будет получать зеркальные данные с основного SQL Server (через встроенную в SQL Server функциюЗеркальное отображение(возможность). Мы запустим Report Service на вторичном SQL Server, при этом он будет находиться в горячем резерве, когда основной SQL Server станет недоступным.
На уровне приложения у нас есть 2 варианта:
- Реализовать обнаружение сбоев на уровне приложений, чтобы в случае неответа основного сервера SQL наш DAL обращался к дополнительному серверу SQL. ИЛИ
- Настройте уровень приложения так, чтобы он указывал на VIP-уровень, а HAProxy обрабатывал обнаружение сбоев.
Вопрос в том, является ли вариант №2 жизнеспособным?
ПРИМЕЧАНИЕ: Мы понимаем, что существуют и другие способы обеспечения высокой доступности на уровне базы данных (например, кластеризация), но мы стремимся к экономически эффективному решению.
решение1
Что вы подразумеваете под «зеркалированием данных»?
Вы можете использовать зеркалирование базы данных, в этом случае клиент (т. е. ваш DAL) может использовать FailoverPartner в строке подключения и отслеживать событие переключения и подключаться к новому принципалу. Ваши отчеты будут работать с моментальными снимками базы данных, а не с самой базой данных, поскольку зеркало недоступно.
У вас может быть отказоустойчивый кластер, и клиент сначала подключается к имени ресурса кластера, не имея при этом информации об имени хоста активного узла, но это не дает вам никакого доступа к данным на резервном партнере.
Можно использовать аппаратное зеркалирование, но это уже отдельная тема.
Некоторые говорят, что репликация — это вариант, но я не в этом лагере.
И... в общем-то, это все. За исключением разработки собственной технологии зеркалирования данных, что бы это ни значило.
Обновлено
Если вы используете зеркалирование базы данных, то вам просто нужно указать партнера по отказоустойчивости в строке подключения, см.Подключение клиентов к зеркальной базе данных. Ваше приложение должно обрабатывать транзакционную согласованность в условиях событий отказоустойчивости. Событие отказоустойчивости резко отключит клиентов, и в клиентском коде возникнет исключение. Любая ожидающая транзакция будет прервана. Клиентский код должен повторно подключиться, прочитать сохраненное состояние и возобновить работу из состояния, найденного в базе данных. Правильно написанные приложения справятся с этим изящно и без проблем.
Зеркало всегда находится в автономном режиме и недоступно. Если вы хотите запустить отчеты на зеркале, вы должны сделать снимок базы данных и запустить отчеты на снимке. Снимок должен периодически обновляться (удаляться и создаваться заново). СмотритеЗеркальное отображение базы данных и моментальные снимки базы данных.
Балансировщики нагрузки сетевого уровня не имеют никакого отношения к зеркалированию и ничего не решают.
решение2
Как насчетни один из вышеперечисленных?
Пожалуйста, уточните, что вы подразумеваете под зеркальными серверами SQL. Используете ли вы SAN для зеркалирования или встроенную функцию зеркалирования SQL Server?
Я понимаю, как можно использовать HAProxy на веб-уровне, но зачем это делать с SQL Server? Есть и другие, гораздо более поддерживаемые варианты HA с SQL Server, такие как кластеризация, зеркалирование и репликация. Я бы сначала изучил их.