Назад | Перейти на главную страницу

Используйте HAProxy для обеспечения отказоустойчивости зеркальных серверов SQL

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

На уровне приложения у нас есть 2 варианта:

  1. Реализуйте обнаружение сбоев на уровне приложений, чтобы, если основной SQL Server не отвечает, наш DAL попадет на дополнительный SQL Server. ИЛИ
  2. Сделайте так, чтобы уровень приложения указывал на VIP и обнаруживал сбой дескриптора HAProxy.

Вопрос в том, является ли вариант №2 жизнеспособным?

ПРИМЕЧАНИЕ. Мы понимаем, что есть и другие способы обеспечения высокой доступности на уровне базы данных (например, кластеризация), но мы стремимся к экономичному решению.

Что вы имеете в виду под «зеркалированием данных»?

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

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

У вас может быть аппаратное зеркалирование, но это отдельная тема.

Некоторые говорят, что репликация - это вариант, я не в этом лагере.

И ... почти все. Если не считать создания собственной технологии зеркалирования данных, что бы это ни значило.

Обновлено

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

Зеркало всегда офлайн и недоступно. Если вы хотите запускать отчеты на зеркале, вы должны сделать снимок базы данных и запустить отчеты на этом снимке. Снимок необходимо периодически обновлять (отбрасывать и воссоздавать). Видеть Зеркальное отображение базы данных и моментальные снимки базы данных.

Балансировщики нагрузки сетевого уровня не имеют ничего общего с зеркалированием и ничего не решают.

Как насчет ни один из вышеперечисленных?

Пожалуйста, поясните, что вы имеете в виду под зеркальными серверами sql. Используете ли вы какую-либо сеть SAN для зеркалирования или встроенную функцию зеркалирования в SQL Server?
Я понимаю, как можно использовать HAProxy на веб-уровне, но зачем это делать с SQL Server? есть и другие гораздо более поддерживаемые параметры высокой доступности с SQL Server, такие как кластеризация, зеркальное отображение и репликация. Я бы сначала исследовал их.