Повторное подключение к сеансу зеркального отображения базы данных
Если установленное соединение с сеансом зеркального отображения базы данных по какой-то причине разрывается — например вследствие перехода с основной базы данных на зеркальную — и приложение пытается подключиться к исходному серверу, поставщик доступа к данным может повторно подключиться, используя имя резервного участника, хранящееся в клиентском кэше. Однако повторное подключение не выполняется автоматически. Приложение должно распознать ошибку. Затем приложению необходимо закрыть сбойное соединение и открыть новое, используя те же атрибуты строки соединения. В этом случае поставщик доступа к данным перенаправляет соединение на резервного участника. Если экземпляр сервера, определяемый именем отказоустойчивого участника, является в настоящий момент основным сервером, попытка соединения обычно завершается успешно. Если неясно, была ли транзакция зафиксирована или произошел ее откат, приложение должно проверить состояние транзакции таким же образом, как при подключении к автономному экземпляру сервера.
Повторное подключение напоминает первоначальное, в строке соединения которого указано имя резервного участника. Если первая попытка соединения завершается неудачно, соединение поочередно пытается подключиться к исходному имени участника и имени резервного участника, пока не произойдет соединение клиента с основным сервером или не истечет время ожидания поставщика доступа к данным.
.gif "Примечание") Примечание |
|---|
Собственный клиент SQL Server проверяет, подключился ли он к экземпляру основного сервера, но не проверяет, является ли этот экземпляр участником экземпляра сервера, заданного в качестве имени первоначального участника в строке соединения. |
Если соединение использует протокол TCP/IP, а клиент использует Windows XP или более позднюю версию, алгоритм повторного подключения определяет количество времени, отведенного на подключение при каждой попытке. Дополнительные сведения см. в разделе Использование ключевых слов строки соединения с собственным клиентом SQL Server.
.gif "Важное примечание") Важно! |
|---|
Если клиент отключается от базы данных, поставщик доступа к данным не будет пытаться возобновить соединение. Клиент должен выдать новый запрос на соединение. Кроме того, если приложение закрывается при потере соединения, оно также теряет кэшированные имена участников. Если соединение было потеряно в результате недоступности основного сервера, единственным способом, с помощью которого приложение может подключиться к зеркальному серверу, является предоставление имени резервного участника в строке соединения. |
Влияние перенаправления на клиентское приложение
При возникновении ошибки поставщик доступа к данным перенаправляет соединение на текущий экземпляр основного сервера. Однако это перенаправление является прозрачным для клиентов. Для клиента перенаправленное соединение выглядит как соединение с экземпляром сервера, определяемым именем изначального участника. Если первоначальный участник является в настоящее время зеркальным сервером, то клиент считает, что он подключен к зеркальному серверу и обновляет зеркальную базу данных. В действительности же клиент перенаправлен к резервному участнику, который является текущей основной базой данных, и обновляет новую основную базу данных.
После перенаправления к резервному участнику клиент может получать непредвиденные результаты, если использует инструкцию Transact-SQL USE для работы в другой базе данных. Это может случиться в том случае, если в текущем экземпляре основного сервера (резервного участника) имеется набор баз данных, отличающийся от набора баз данных изначального участника.
См. также