Мне нужно настроить автоматическое переключение при отказе с двумя экземплярами SQL Server и зеркалированием. Существует несколько хостеров DNS (например, DNS Made Easy и Netriplex), обеспечивающих автоматическое переключение при отказе. Они отслеживают экземпляры вашего сервера каждую минуту, и если первичный выйдет из строя, доменное имя преобразуется в IP-адрес вторичного сервера.
Моя проблема в том, что мне также нужно переключать роли сервера в случае автоматического переключения на другой ресурс, а это не поддерживается моим текущим поставщиком услуг хостинга DNS (DNS Made Easy).
Другими словами: предположим, что у меня есть два сервера баз данных - A и B. A является основным сервером, а B просто ждет, если A выйдет из строя. Когда A выходит из строя, B берет на себя управление и становится новым основным сервером. Когда A возвращается в рабочее состояние, это новый вторичный сервер, который находится в режиме ожидания, пока B не выйдет из строя. Когда B терпит неудачу, A снова становится основным сервером.
Есть ли какой-нибудь DNS-хостер, который предлагает такую функциональность?
Спасибо,
Адриан
Я не думаю, что DNS является подходящим механизмом для такого рода аварийного переключения. По моему опыту, отказоустойчивость базы данных обычно выполняется следующими способами:
Проблема с использованием DNS для этого заключается в том, что запросы DNS могут кэшироваться на многих уровнях между конечным пользователем и вашим сервером. Поэтому, даже если вы измените запись DNS немедленно, может пройти несколько часов, прежде чем изменение будет распространено на конечного пользователя, и ваша служба на это время не будет работать.
Извините, но вы не можете этого сделать.
SQL-серверы обычно не имеют прямого доступа к Интернету, поэтому общедоступные DNS и SQL-серверы вместе - довольно необычная комбинация. По этой причине вы не найдете DNS-хосты с автоматическими проверками работоспособности для SQL Server.
В принципе, вы можете защитить SQL Server до такой степени, чтобы он мог выходить в Интернет. Но даже так; Вы совершенно уверены, что хотите, учли ли вы все возможные риски безопасности, связанные с использованием эксплойта переполнения буфера в SQL Server? Я не знаю особенностей вашей архитектуры, но на первый взгляд такой дизайн кажется неправильным.
Следующий, SQL Server - вещь с отслеживанием состояния. Если основной SQL Server дает сбой прямо в середине продолжительной ALTER TABLE
или транзакция, тогда не очевидно, в каком состоянии находится сервер резервного копирования. Обработку отказа SQL Server часто не совсем возможно автоматизировать, вам может понадобиться администратор баз данных, чтобы вернуть серверы в согласованное состояние. Я бы определенно не стал доверять внешнему DNS-узлу, который не знает моего домена приложения, для правильной обработки отказа базы данных и целостности данных.
Наконец, Восстановление после отказа DNS может занять много времени. Кеширует DNS, ну, результаты запроса кеша, и даже если вы установите для DNS TTL низкий, время перехода в реальной жизни может быть довольно большим.
Как я только что узнал, есть простой способ справиться именно с этим сценарием: указать партнера по отработке отказа в строке подключения. Что-то вроде этого может помочь:
Data Source=myServerAddress;Failover Partner=myMirrorServerAddress;Initial Catalog=myDataBase;Integrated Security=True;
Редактировать: Я не уверен, как понять возражение в комментарии ниже. Разве это не схема взято из MSDN точно описать мой сценарий?
Также из Эта статья:
Если вы подключаетесь с помощью ADO.NET или собственного клиента SQL к базе данных, которая зеркалируется, ваше приложение может воспользоваться возможностью драйверов автоматически перенаправлять подключения при отказе зеркального отображения базы данных. Вы должны указать исходный основной сервер и базу данных в строке подключения и сервер-партнер по отработке отказа.