Подключение клиентов к сеансу зеркального отображения базы данных (SQL Server)
Чтобы подключиться к сеансу зеркального отображения базы данных, клиент может использовать либо программу SQL Native Client, либо поставщика данных .NET Framework для SQL Server. При настройке базы данных SQL Server 2014 эти поставщики доступа к данным полностью поддерживают зеркальное отображение базы данных. Дополнительные сведения о замечаниях по программированию при использовании зеркальной базы данных см. в разделе Using Database Mirroring. Кроме того, текущий экземпляр основного сервера должен быть доступен, и имя входа клиента должно быть создано на экземпляре сервера. Дополнительные сведения см. в статье Диагностика пользователей, утративших связь с учетной записью (SQL Server). Клиентские соединения с сеансом зеркального отображения базы данных не задействуют экземпляр следящего сервера, если он существует.
Установка первоначального соединения с сеансом зеркального отображения базы данных
Чтобы выполнить первоначальное соединение с отображаемой базой данных, клиент должен предоставить строку соединения, которая обязательно содержит имя экземпляра сервера. Это необходимое имя сервера должно идентифицировать текущий экземпляр основного сервера, и называется имя изначального участника.
При необходимости строка соединения может также содержать имя другого экземпляра сервера, которое идентифицирует текущий экземпляр зеркального сервера, используемого в том случае, когда изначальный участник недоступен во время первой попытки соединения. Второе имя называется именем партнера по обеспечению отработки отказа.
В строке соединения должно также содержаться имя базы данных. Это необходимо, чтобы предоставить возможность поставщику доступа к данным пытаться совершать отработку отказа.
После получения строки соединения поставщик доступа к данным сохраняет имя изначального участника и имя партнера по обеспечению отработки отказа (если оно приведено) в кэше в энергозависимой памяти (для управляемого кода кэш содержится в домене приложения). После кэширования имя изначального участника поставщиком доступа к данным не обновляется. Если клиент предоставляет имя участника отработки отказа, то в случае, если поставщик доступа к данным не может подключиться с использованием имени изначального участника, поставщик также сохраняет имя партнера по обеспечению отработки отказа.
Сеанс зеркального отображения базы данных не обеспечивает защиты от проблем, связанных с доступом клиента к серверам, например если компьютер клиента испытывает проблемы во взаимодействии с сетью. Попытка соединения с отображаемой базой может завершиться неудачно по множеству причин, не относящихся к поставщику доступа к данным, например попытка соединения может оказаться неудачной, если экземпляр основного сервера неактивен; это происходит, когда выполняется переход на другую базу данных, или по причине ошибки в сети.
При попытке подключения поставщик доступа к данным пытается подключиться сначала с помощью имени изначального участника. Если указанный экземпляр сервера доступен и является текущим экземпляром основного сервера, то попытка соединения обычно завершается успешно.
Примечание.
Если сеанс зеркального отображения приостановлен, то клиент обычно подключается к основному серверу и загружает имя участника. Однако база данных не будет доступна клиенту до тех пор, пока не возобновится процесс зеркального отображения.
Если попытка завершилась неудачей, поставщик доступа к данным пытается подключиться с помощью имени партнера по обеспечению отработки отказа, если оно доступно. Если имя другого участника правильно идентифицирует текущий основной сервер, то поставщику доступа к данным обычно удается открыть первоначальное соединение. После завершения данного соединения поставщик доступа к данным загружает имя экземпляра текущего зеркального сервера. Это имя сохраняется в кэше как имя партнера по обеспечению отработки отказа, при этом предоставленное клиентом имя партнера по обеспечению отработки отказа, если оно существует, перезаписывается. После этого поставщик данных .NET Framework для SQL Server не обновляет имя партнера по обеспечению отработки отказа. Однако, SQL Server Native Client обновляет кэш каждый раз, когда последующее соединение или переустановка соединения возвращает другое имя участника.
На приведенной ниже схеме показано соединение клиента с изначальным участником Участник Адля отображаемой базы данных Db_1. Схема иллюстрирует случай, когда имя изначального участника, предоставленное клиентом, верно идентифицирует текущий основной сервер Участник А. Первоначально соединение завершается успешно, и поставщик доступа к данным сохраняет имя текущего зеркального сервера ( Участник Б) в локальном кэше в качестве имени участника по обеспечению отработки отказа. Наконец, клиент подключается к основной копии базы данных Db_1 .
Попытка первоначального соединения может завершиться неудачно, например в результате ошибки сети или из-за того, что экземпляр сервера неактивен. Так как изначальный участник недоступен, клиент должен предоставить имя партнера по обеспечению отработки отказа в строке соединения, чтобы поставщик доступа к данным попытался подключиться к партнеру по обеспечению отработки отказа.
В случае если имя партнера по обеспечению отработки отказа недоступно, попытки первоначального подключения продолжаются до тех пор, пока не истечет время ожидания подключения к сети или не будет возвращена ошибка (аналогично подключению к неотображаемой базе данных).
Если в строке подключения приведено имя партнера по обеспечению отработки отказа, то поведение поставщика доступа к данным зависит от сетевого протокола и операционной системы клиента следующим образом:
Для протокола TCP/IP попытки соединения регулируются алгоритмом повторения подключений, специфичным для зеркального отображения базы данных. Алгоритм повторного соединения определяет максимальное время ( время повтора), отведенное для открытия соединения в рамках данной попытки соединения.
Для других сетевых протоколов
Если возникла ошибка или изначальный участник недоступен, то попытки первоначального соединения продолжаются до тех пор, пока не истечет время ожидания сетевого подключения либо не истечет время ожидания входа на поставщике доступа к данным. Обычно это время ожидания составляет примерно 20—30 секунд. После этого, если время ожидания поставщика доступа к данным не истекло, поставщик пытается подключиться к партнера по обеспечению отработки отказа. Если время ожидания соединения истекло до успешного завершения подключения или партнер по обеспечению отработки отказа недоступен, попытка подключения завершается неудачно. Если до окончания времени ожидания входа партнер по обеспечению отработки отказа доступен и в данный момент является основным сервером, попытка соединения обычно завершается успешно.
Строки подключения с зеркальной базой данных
Сообщаемая клиентом строка подключения содержит сведения, используемые поставщиком доступа к данным для подключения к базе данных. В этом разделе описаны ключевые слова, относящиеся к соединению с зеркальной базой данных с помощью драйвера ODBC SQL Server Native Client.
Атрибут Network
Строка подключения должна содержать атрибут Network , указывающий сетевой протокол. Это гарантирует сохранение указанного сетевого протокола при соединении с разными участниками. Протокол TCP/IP — наилучший протокол для соединения с отображаемой базой данных. Чтобы гарантировать запрос протокола TCP/IP клиентом при каждом подключении к участникам, необходимо включить в строку соединения следующий атрибут:
Network=dbmssocn;
Внимание
Рекомендуется, чтобы протокол TCP/IP был указан в самой верхней строке списка протоколов клиента. Однако, если в строке подключения указан атрибут Network , то он переопределяет порядок элементов списка.
С другой стороны, чтобы гарантировать запрос именованных каналов клиентом каждый раз при подключении к участникам, необходимо включить в строку подключения следующий атрибут:
Network=dbnmpntw;
Внимание
Так как именованные каналы не используют алгоритм повторения протокола TCP/IP, во многих случаях время попытки подключения с помощью именованных каналов истекает до соединения с отображаемой базой данных.
Атрибут Server
В строке соединения должен присутствовать атрибут Server, предоставляющий исходное имя участника, которое должно определять текущий экземпляр основного сервера.
Самый простой способ идентифицировать экземпляр сервера — указать его имя: <имя_сервера>[\<имя_экземпляра_SQL_Server>]. Например:
Server=Partner_A;
or
Server=Partner_A\Instance_2;
Однако, если используется системное имя, то клиент должен выполнить уточняющий запрос к DNS, чтобы получить IP-адрес сервера и запрос к браузеру SQL Server, чтобы получить номер порта сервера, на котором расположен участник. Эти уточняющие запросы можно обойти, если указать IP-адрес и номер порта участника в атрибуте Server вместо указания имени сервера. Это рекомендуется для сведения к минимуму возможности внешних задержек при соединении с участником.
Примечание.
Запрос к браузеру SQL Server необходим, если в строке подключения указано имя именованного экземпляра, а не порт.
Чтобы указать IP-адрес и порт, Server атрибут принимает следующую форму, Server=<ip_address<,>порт>, например:
Server=123.34.45.56,4724;
Примечание.
IP-адреса бывают версии 4 (IPv4) или 6 (IPv6).
Атрибут Database
Кроме того, в строке соединения должен содержаться атрибут Database, который предоставляет имя зеркальной базы данных. Если база данных во время клиентской попытки соединения недоступна, инициируется исключение.
Например, чтобы явным образом установить соединение с базой данных AdventureWorks на основном сервере Partner_A, клиент должен указать следующую строку подключения:
" Server=Partner_A; Database=AdventureWorks "
Примечание.
В данной строке пропущены сведения для проверки подлинности.
Внимание
Объединение префикса протокола с атрибутом Server (<Server=tcp:имя> сервера) несовместимо с атрибутом Network и указанием протокола в обоих местах, скорее всего, приведет к ошибке. Поэтому мы рекомендуем строка подключения указать протокол с помощью сетевого атрибута и указать только имя сервера в атрибуте Server ("Network=dbmssocn; Server=<имя>" сервера).
Атрибут Failover Partner
В дополнение к имени изначального участника клиент может также указать имя партнера по обеспечению отработки отказа, являющегося резервным сервером, которое должно идентифицировать текущий экземпляр зеркального сервера. Участник отработки отказа задается в одном из ключевых слов для атрибута партнера по обеспечению отработки отказа. Ключевое слово для этого атрибута зависит от используемого API-интерфейса. В следующей таблице перечислены эти ключевые слова.
| API | Ключевое слово для атрибута партнера по обеспечению отработки отказа |
|---|---|
| Поставщик OLE DB | FailoverPartner |
| драйвер ODBC; | Failover_Partner |
| Объекты ADO | Failover Partner |
Самый простой способ идентифицировать экземпляр сервера — указать его системное имя: <имя_сервера>[\<имя_экземпляра_SQL_Server>].
Можно также указать IP-адрес и порт в атрибуте Failover Partner. В случае неудачи первоначальной попытки подключения во время первого соединения с базой данных попытка соединения с партнером по обеспечению отработки отказа, являющимся резервным сервером, не будет более зависеть от DNS и браузера SQL Server. После того как соединение установлено, имя партнера по обеспечению отработки отказа перезаписывается именем партнера по обеспечению отработки отказа, являющегося резервным севером; таким образом, в случае сбоя перенаправленные соединения потребуют DNS и браузер SQL Server.
Примечание.
Если указано только имя изначального участника, разработчикам приложения нет необходимости предпринимать какие-либо действия или писать какой-либо код, кроме кода, предназначенного для повторного соединения.
Примечание.
Разработчики приложений с управляемым кодом указывают имя партнера по обеспечению отработки отказа в свойстве 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 при подключении к исходному участнику см. в разделе Установка первоначального соединения с сеансом зеркального отображения базы данныхвыше в данной теме.
Если попытка соединения не удается или время повтора истекает до успешного создания соединения, поставщик данных пытается подключиться к другому участнику. Если к этому моменту подключение не открыто, поставщик также пытается использовать начальные и отработки отказа имена партнеров, пока не будет открыто соединение или период входа истекает. Время ожидания входа по умолчанию — 15 секунд. Рекомендуется устанавливать значение интервала времени ожидания не менее 5 секунд. Задание меньшего интервала времени ожидания может препятствовать успешному выполнению любых попыток соединения.
Время повтора — это процент от времени входа. Время повтора для попытки соединения увеличивается при каждом успешном цикле. В первом цикле время повтора для каждой из двух попыток составляет 8 процентов от общего времени входа. При каждом успешном цикле алгоритм повтора увеличивает максимальное время повтора на то же число. Следовательно, время повтора для первых восьми попыток соединения будет следующим:
8%, 8%, 16%, 16%, 24%, 24%, 32%, 32%
Время повтора рассчитывается при помощи следующей формулы:
RetryTime PreviousRetryTime +( 0.08 *LoginTimeout) =
где PreviousRetryTime изначально равно 0.
Например, при использовании времени ожидания входа 15 секунд LoginTimeout= 15. В этом случае время повтора, назначенное на первые три цикла, будет следующим:
| Round | Вычисление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 проверяет, подключился ли он к экземпляру основного сервера, но не проверяет, является ли этот экземпляр участником экземпляра сервера, заданного в качестве имени первоначального участника в строке подключения.
Если соединение использует протокол TCP/IP, алгоритм повторного соединения определяет количество времени, отведенного на подключение при каждой попытке.
Внимание
Если клиент отключается от базы данных, поставщик доступа к данным не будет пытаться возобновить соединение. Клиент должен выдать новый запрос на соединение. Кроме того, если приложение закрывается при потере соединения, оно также теряет кэшированные имена участников. Если соединение было потеряно в результате недоступности основного сервера, единственным способом, с помощью которого приложение может подключиться к зеркальному серверу, является предоставление имени партнера по обеспечению отработки отказа в строке подключения.
Влияние перенаправления на клиентское приложение
После отработки отказа поставщик доступа к данным перенаправляет соединение на текущий экземпляр основного сервера. Однако это перенаправление является прозрачным для клиентов. Для клиента перенаправленное соединение выглядит как соединение с экземпляром сервера, определяемым именем изначального участника. Если первоначальный участник является в настоящее время зеркальным сервером, то клиент считает, что он подключен к зеркальному серверу и обновляет зеркальную базу данных. В действительности же клиент перенаправлен к партнеру по обеспечению отработки отказа, который является текущей основной базой данных, и обновляет новую основную базу данных.
После перенаправления к партнеру по обеспечению отработки отказа клиент может получать непредвиденные результаты, если использует инструкцию USE Transact-SQL для работы в другой базе данных. Это может случиться в том случае, если в текущем экземпляре основного сервера (партнера по обеспечению отработки отказа) имеется набор баз данных, отличающийся от набора баз данных изначального участника.
Влияние устаревшего имени партнера по обеспечению отработки отказа
Администратор базы данных может в любой момент изменить имя участника, являющегося сервером партнера по обеспечению отработки отказа. Следовательно, предоставленное клиентом имя участника обеспечению отработки отказа может оказаться неактуальным или устаревшим. Например, рассмотрим ситуацию, когда партнер по обеспечению отработки отказа 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 сохраняется в кэше в качестве имени изначального участника. Клиент успешно соединяется с сервером Partner_A. Затем клиент загружает имя зеркального сервера, Partner_B, и кэширует его, не учитывая указанное клиентом имя партнера по обеспечению отработки отказа. |
| На сервере Partner_A происходит сбой оборудования и начинается отработка отказа (с отключением клиентов). | Участник Б | ничего | В качестве имени изначального участника в кэше все еще указан Partner_A, но сообщенное клиентом имя партнера по обеспечению отработки отказа, Partner_B, позволяет клиенту соединиться с текущим основным сервером. |
| Администратор баз данных прекращает зеркальное отображение (отключая клиентов), заменяет Partner_A на Partner_C и перезапускает зеркальное отображение. | Участник Б | Partner_C | Клиент пытается соединиться с сервером Partner_A и это не удается; затем клиент пытается соединиться с Partner_B (текущему основному серверу) и это завершается успешно. Поставщик доступа к данным загружает имя текущего зеркального сервера, Partner_C, и кэширует его в качестве текущего имени партнера по обеспечению отработки отказа. |
| Переход службы на сервер Partner_C производится вручную (с отключением клиентов). | Partner_C | Участник Б | Клиент изначально пытается подключиться к серверу Partner_A, а затем к серверу Partner_B. Обе попытки завершаются неудачно, в результате время ожидания соединения истекает и соединение завершается неудачно. |
См. также
Зеркальное отображение базы данных (SQL Server)
Возможные неполадки при зеркальном отображении базы данных