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

Область применения:SQL Server

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

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

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

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

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

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

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

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

Примечание.

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

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

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

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

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

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

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

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

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

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

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

Атрибут сети

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

Network=dbmssocn;   

Внимание

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

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

Network=dbnmpntw;   

Внимание

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

Атрибут сервера

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

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

Server=Partner_A;

или

Server=Partner_A\Instance_2;

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

Примечание.

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

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

Server=123.34.45.56,4724;   

Примечание.

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

Атрибут базы данных

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

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

" Server=Partner_A; Database=AdventureWorks "

Примечание.

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

Внимание

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

Атрибут Failover Partner

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

API	Ключевое слово атрибута партнёра по аварийному переключению
Поставщик OLE DB	FailoverPartner
драйвер ODBC;	Failover_Partner
Объекты данных ActiveX (ADO)	Партнёр по аварийному переключению

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

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

Примечание.

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

Примечание.

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

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

Например, чтобы явно подключиться к базе данных 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 Browser при попытке подключения к первоначальному партнеру см. в разделе Установка первоначального соединения с сеансом зеркального отображения базы данных, выше в данной теме.

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

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

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

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

RetryTime=PreviousRetryTime+( 0.08 *LoginTimeout)

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

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

Круглый	Вычисление RetryTime	Время повтора на попытку
1	0 +(0.08 * 15)	1,2 с
2	1.2 +(0.08 * 15)	2,4 с
3	2.4 +(0.08 * 15)	3,6 с
4	3.6 +(0.08 * 15)	4,8 с

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

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

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

Примечание.

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

Задержки повторных попыток при переключении при отказе

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

Примечание.

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

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

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

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

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

Примечание.

SQL Server Native Client проверяет, что он подключается к основному экземпляру сервера, но не проверяет, является ли этот экземпляр партнёром экземпляра сервера, указанного в параметре initial partner name строки подключения.

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

Внимание

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

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

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

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

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

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

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

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

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

Примечание.

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

Настройка	Основной сервер	Зеркальный сервер	Поведение при попытке подключения при указании Partner_A и Partner_B
Исходная зеркальная конфигурация.	Partner_A	Партнёр_B	Partner_A сохраняется в кэше в качестве имени изначального участника. Клиент успешно соединяется с сервером Partner_A. Затем клиент загружает имя зеркального сервера, Partner_B, и кэширует его, не учитывая указанное клиентом имя партнера по обеспечению отработки отказа.
У Partner_A происходит аппаратный сбой, и выполняется переключение на резервный узел (при этом клиенты отключаются).	Партнер_B	ничего	В качестве имени изначального участника в кэше все еще указан Partner_A, но сообщенное клиентом имя партнера по обеспечению отработки отказа, Partner_B, позволяет клиенту соединиться с текущим основным сервером.
Администратор баз данных прекращает зеркальное отображение (отключая клиентов), заменяет Partner_A на Partner_C и перезапускает зеркальное отображение.	Партнёр_B	Partner_C	Клиент пытается соединиться с сервером Partner_A и это не удается; затем клиент пытается соединиться с Partner_B (текущему основному серверу) и это завершается успешно. Поставщик доступа к данным получает имя текущего зеркального сервера Partner_C и сохраняет его в кэше как текущее имя партнера по отработке отказа.
Переход службы на сервер Partner_C производится вручную (с отключением клиентов).	Partner_C	Партнёр_B	Клиент изначально пытается подключиться к серверу Partner_A, а затем к серверу Partner_B. Обе попытки завершаются неудачно, в результате время ожидания соединения истекает и соединение завершается неудачно.

Связанные материалы

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