Подключение клиентов к сеансу зеркального отображения базы данных (SQL Server)

Чтобы подключиться к сеансу зеркального отображения базы данных, клиент может использовать либо программу собственного клиента SQL Server, либо поставщика данных .NET Framework для SQL Server. Если эти поставщики доступа к данным настроены для использования базы данных SQL Server 2012, то они поддерживают зеркальное отображение базы данных. Дополнительные сведения о замечаниях по программированию при использовании зеркальной базы данных см. в разделе Использование зеркального отображения базы данных. Кроме того, текущий экземпляр основного сервера должен быть доступен, и имя входа клиента должно быть создано на экземпляре сервера. Дополнительные сведения см. в разделе Диагностика пользователей, утративших связь с учетной записью (SQL Server). Клиентские соединения с сеансом зеркального отображения базы данных не задействуют экземпляр следящего сервера, если он существует.

В этом разделе:

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

• Алгоритм повторного соединения (для соединений по протоколу TCP/IP)
  Описывает алгоритм повторения для соединений TCP/IP.

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

• Влияние устаревшего имени партнера по обеспечению отработки отказа
  Рассмотрено влияние изменения администратором базы данных одного из участников зеркального отображения для зеркальной базы данных.

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

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

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

В строке соединения должно также содержаться имя базы данных. Это необходимо, чтобы предоставить возможность поставщику доступа к данным пытаться совершать отработку отказа.

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

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

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

Примечание
Если сеанс зеркального отображения приостановлен, то клиент обычно подключается к основному серверу и загружает имя участника. Однако база данных не будет доступна клиенту до тех пор, пока не возобновится процесс зеркального отображения.

Если попытка завершилась неудачей, поставщик доступа к данным пытается подключиться с помощью имени партнера по обеспечению отработки отказа, если оно доступно. Если имя другого участника правильно идентифицирует текущий основной сервер, то поставщику доступа к данным обычно удается открыть первоначальное соединение. После завершения данного соединения поставщик доступа к данным загружает имя экземпляра текущего зеркального сервера. Это имя сохраняется в кэше как имя партнера по обеспечению отработки отказа, при этом предоставленное клиентом имя партнера по обеспечению отработки отказа, если оно существует, перезаписывается. После этого поставщик данных .NET Framework Data Provider для SQL Server не обновляет имя партнера по обеспечению отработки отказа. Однако, собственный клиент SQL Server обновляет кэш каждый раз, когда последующее соединение или переустановка соединения возвращает другое имя участника.

На приведенной ниже схеме показано соединение клиента с изначальным участником Участник А для отображаемой базы данных Db_1. Схема иллюстрирует случай, когда имя изначального участника, предоставленное клиентом, верно идентифицирует текущий основной сервер Участник А. Первоначально соединение завершается успешно, и поставщик доступа к данным сохраняет имя текущего зеркального сервера (Участник Б) в локальном кэше в качестве имени партнера по обеспечению отработки отказа. Наконец, клиент подключается к основной копии базы данных Db_1.

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

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

Если в строке подключения приведено имя партнера по обеспечению отработки отказа, то поведение поставщика доступа к данным зависит от сетевого протокола и операционной системы клиента следующим образом:

• Для протокола TCP/IP попытки соединения регулируются алгоритмом повторения подключений, специфичным для зеркального отображения базы данных. Алгоритм повторного соединения определяет максимальное время (время повтора), отведенное для открытия соединения в рамках данной попытки соединения.

• Для других сетевых протоколов

  Если возникла ошибка или изначальный участник недоступен, то попытки первоначального соединения продолжаются до тех пор, пока не истечет время ожидания сетевого подключения либо не истечет время ожидания входа на поставщике доступа к данным. Обычно это время ожидания составляет примерно 20—30 секунд. После этого, если время ожидания поставщика доступа к данным не истекло, поставщик пытается подключиться к партнера по обеспечению отработки отказа. Если время ожидания соединения истекло до успешного завершения подключения или партнер по обеспечению отработки отказа недоступен, попытка подключения завершается неудачно. Если до окончания времени ожидания входа партнер по обеспечению отработки отказа доступен и в данный момент является основным сервером, попытка соединения обычно завершается успешно.

[В начало]

Строки подключения с зеркальной базой данных

Сообщаемая клиентом строка подключения содержит сведения, используемые поставщиком доступа к данным для подключения к базе данных. В этом разделе описаны ключевые слова, относящиеся к соединению с зеркальной базой данных с помощью драйвера Native Client ODBCSQL Server.

Атрибут Network

Строка подключения должна содержать атрибут Network, указывающий сетевой протокол. Это гарантирует сохранение указанного сетевого протокола при соединении с разными участниками. Протокол TCP/IP — наилучший протокол для соединения с отображаемой базой данных. Чтобы гарантировать запрос протокола TCP/IP клиентом при каждом подключении к участникам, необходимо включить в строку соединения следующий атрибут:

Network=dbmssocn; 

Важно!
Рекомендуется, чтобы протокол TCP/IP был указан в самой верхней строке списка протоколов клиента. Однако, если в строке подключения указан атрибут Network, то он перекрывает порядок элементов списка.

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

Network=dbnmpntw; 

Важно!
Так как именованные каналы не используют алгоритм повторения протокола TCP/IP, во многих случаях время попытки подключения с помощью именованных каналов истекает до соединения с отображаемой базой данных.

Атрибут Server

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

Самый простой способ идентифицировать экземпляр — это указать его имя, <server_name>[\<SQL_Server_instance_name>]. Например.

Server=Partner_A;

или

Server=Partner_A\Instance_2;

Однако, если используется системное имя, то клиент должен выполнить уточняющий запрос к DNS, чтобы получить IP-адрес сервера и запрос к браузеру SQL Server, чтобы получить номер порта сервера, на котором расположен участник. Эти уточняющие запросы можно обойти, если указать IP-адрес и номер порта участника в атрибуте Server вместо указания имени сервера. Это рекомендуется для сведения к минимуму возможности внешних задержек при соединении с участником.

Примечание
Запрос к браузеру SQL Server необходим, если в строке подключения указано имя именованного экземпляра, а не порт.

Чтобы указать IP-адрес и порт, нужно записать атрибут Server в следующем виде: Server=<ip_address>,<port>, например:

Server=123.34.45.56,4724; 

Примечание
IP-адреса бывают версии 4 (IPv4) или 6 (IPv6).

Атрибут Database

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

Например, чтобы явным образом установить соединение с базой данных AdventureWorks на основном сервере Partner_A, клиент должен указать следующую строку подключения:

" Server=Partner_A; Database=AdventureWorks "

Примечание
В данной строке пропущены сведения для проверки подлинности.

Важно!
Указание префикса протокола с атрибутом Server (Server=tcp:<servername>) несовместимо с атрибутом Network, и указание протокола в двух местах, вероятнее всего, приведет к ошибке. Поэтому рекомендуется задавать протокол в строке подключения с помощью атрибута Network и указывать только имя сервера в атрибуте Server ("Network=dbmssocn; Server=<servername>").

Атрибут Failover Partner

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

Самый простой способ идентифицировать экземпляр сервера — это указать его системное имя, <server_name>[\<SQL_Server_instance_name>].

Можно также указать IP-адрес и порт в атрибуте Failover Partner. В случае неудачи первоначальной попытки подключения во время первого соединения с базой данных попытка соединения с партнером по обеспечению отработки отказа, являющимся резервным сервером, не будет более зависеть от DNS и браузера SQL Server. После того как соединение установлено, имя партнера по обеспечению отработки отказа перезаписывается именем партнера по обеспечению отработки отказа, являющегося резервным севером; таким образом, в случае сбоя перенаправленные соединения потребуют DNS и браузер SQL Server.

Примечание
Если указано только имя изначального участника, разработчикам приложения нет необходимости предпринимать какие-либо действия или писать какой-либо код, кроме кода, предназначенного для повторного соединения.

Примечание

Разработчики приложений с управляемым кодом указывают имя партнера по обеспечению отработки отказа в свойстве ConnectionString объекта SqlConnection. Дополнительные сведения об использовании данной строки соединения см. в разделе «Поддержка зеркального отображения баз данных в поставщике данных .NET Framework для SQL Server» документации по ADO.NET, являющейся частью пакета Microsoft .NET Framework SDK.

Пример строки соединения

Например, чтобы явно подключиться к базе данных AdventureWorks с помощью протокола TCP/IP на сервере «Участник А» или «Участник Б», клиентское приложение, использующее драйвер ODBC, должно указать следующую строку соединения:

"Server=Partner_A; Failover_Partner=Partner_B; Database=AdventureWorks; Network=dbmssocn"

Либо клиент может использовать IP-адрес и номер порта, чтобы идентифицировать изначального участника Участник А; например для IP-адреса 250.65.43.21 и номера порта 4734 строка подключения может быть следующей:

"Server=250.65.43.21,4734; Failover_Partner=Partner_B; Database=AdventureWorks; Network=dbmssocn"

Алгоритм повторного соединения (для соединений по протоколу TCP/IP)

Для соединения по протоколу TCP/IP, когда имена обоих участников находятся в кэше, поставщик доступа к данным устанавливает соединение по алгоритму повторного соединения. Это справедливо как для начального соединения с сеансом, так и для повторного соединения после потери связи. После установки соединения выполнение предварительных и основных шагов подключения требует дополнительного времени.

Примечание

Время, затраченное на создание соединения, может превышать время повтора по причине внешних факторов, таких как медленные уточняющие запросы DNS, медленный контроллер домена или KDC, время, затраченное на связь с браузером SQL Server, загруженность сети и так далее. Такие внешние факторы могут препятствовать подключению клиента к зеркально отображаемой базе данных. Также внешние факторы могут сделать время создания соединения большим, чем установленное время повтора. Дополнительные сведения об обходе DNS и браузера SQL Server при подключении к исходному участнику см. в разделе Установка первоначального соединения с сеансом зеркального отображения базы данных выше в данной теме.

Если попытка соединения не удается или время повтора истекает до успешного создания соединения, поставщик данных пытается подключиться к другому участнику. Если создать соединение не удалось, поставщик пытается менять имена исходного участника и партнера по обеспечению отработки отказа, пока не установится соединение или не истечет время входа. По умолчанию период ожидания входа составляет 15 секунд. Рекомендуется устанавливать значение интервала времени ожидания не менее 5 секунд. Задание меньшего интервала времени ожидания может препятствовать успешному выполнению любых попыток соединения.

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

8%, 8%, 16%, 16%, 24%, 24%, 32%, 32%

Время повтора рассчитывается при помощи следующей формулы:

RetryTime = PreviousRetryTime + ( 0.08 * LoginTimeout )

где PreviousRetryTime изначально равно 0.

Например, при использовании времени ожидания входа, равного 15 секунд, LoginTimeout = 15. В этом случае время повтора, назначенное на первые три цикла, будет следующим:

На следующем рисунке показаны периоды повторов для успешных попыток соединения, время ожидания каждой из которых истекает.

Для времени ожидания периода входа, установленного по умолчанию, максимальное время, назначенное на первые три цикла попыток соединения, составляет 14,4 секунды. Если бы каждая попытка использовала все свое назначенное время, то оставалось бы всего 0,6 секунды до истечения времени входа. В этом случае четвертый цикл будет сокращен, допуская только последнюю быструю попытку соединения с использованием имени исходного участника. Однако попытка соединения может не удаться за время повтора, меньше назначенного, особенно в последующих циклах. Например, возникновение ошибки сети может привести к прекращению попытки до истечения времени повтора. Если предыдущие попытки не удались из-за ошибки сети, для четвертого и, возможно, дополнительных циклов будет доступно дополнительное время.

Другая причина неудавшихся попыток — неактивный экземпляр сервера, что случается при переводе экземпляром сервера на другой ресурс своей базы данных. В этом случае выполняется задержка повтора для предотвращения перегрузки участников быстрым выполнением попыток соединения.

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

[В начало]

Задержки повторов во время отработки отказа

Если клиент пытается подключиться к участнику, переходящему на другой ресурс, участник немедленно отвечает, что он недоступен. В этом случае каждый цикл попыток соединения будет значительно короче назначенного времени повтора. Это означает, что до истечения времени входа может возникнуть множество циклов попыток подключения. Чтобы избежать перегрузки участников быстрыми сериями попыток соединения во время отработки отказа, поставщик доступа к данным добавляет краткую задержку повтора после каждого цикла повтора. Продолжительность заданной задержки повтора определяется алгоритмом задержки повтора. После первого цикла задержка составляет 100 миллисекунд. После каждого из следующих трех раундов задержка повтора удваивается — до 200, 400 и 800. Для всех последующих циклов задержка повтора составляет 1 секунду вплоть до успешного выполнения попытки соединения или истечения времени.

Примечание
Если экземпляр сервера остановлен, запрос на подключение прекращается немедленно.

На следующем рисунке показано, как задержки повторов влияют на попытки подключения во время перехода на другой ресурс вручную, при котором партнеры переключают свои роли. Период ожидания составляет 15 секунд.

Повторное подключение к сеансу зеркального отображения базы данных

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

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

Примечание
Собственный клиент SQL Server проверяет, подключился ли он к экземпляру основного сервера, но не проверяет, является ли этот экземпляр участником экземпляра сервера, заданного в качестве имени первоначального участника в строке подключения.

Если соединение использует протокол TCP/IP, алгоритм повторного соединения определяет количество времени, отведенного на подключение при каждой попытке.

Важно!

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

[В начало]

Влияние перенаправления на клиентское приложение

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

После перенаправления к партнеру по обеспечению отработки отказа клиент может получать непредвиденные результаты, если использует инструкцию Transact-SQL USE для работы в другой базе данных. Это может случиться в том случае, если в текущем экземпляре основного сервера (партнера по обеспечению отработки отказа) имеется набор баз данных, отличающийся от набора баз данных изначального участника.

[В начало]

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

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

Например, клиент использует одну строку соединения для последовательности из четырех попыток соединения: В строке соединения имя начального участника — Partner_A, а имя партнера по обеспечению отработки отказа — Partner_B:

"Server=Partner_A; Failover Partner=Partner_B; Database=AdventureWorks"

В следующей таблице показаны четыре конфигурации участников и указано, будет ли работать данная строка соединения при подключении клиента в первый раз.

Примечание
Приложение может следить за изменениями конфигурации и изменять строку соединения соответствующим образом. Это требует дополнительного кода, но снимает с администратора часть забот.

[В начало]

См. также

Основные понятия

Зеркальное отображение базы данных (SQL Server)

Возможные неполадки при зеркальном отображении базы данных