Время ожидания подключения при использовании Multisubnetfailover=True

Недавно я обнаружил, что соединение одного из наших веб-серверов с прослушивателем MSSQL AlwaysOn не работает. Слушатель имеет два IP-адреса, поскольку он охватывает подсети, поэтому мы указываем Multisubnetfailover=true в нашей строке подключения.

При попытке подключиться к слушателю я получаю следующую ошибку:

System.Data.SqlClient.SqlException (0x80131904): Connection Timeout Expired.  The timeout period elapsed while
attempting to consume the pre-login handshake acknowledgement.  This could be because the pre-login handshake
failed or the server was unable to respond back in time.  The duration spent while attempting to connect to this
server was - [Pre-Login] initialization=20991; handshake=0;  ---> System.ComponentModel.Win32Exception     
(0x80004005): The wait operation timed out at     
System.Data.ProviderBase.DbConnectionPool.TryGetConnection(DbConnection owningObject, UInt32     
waitForMultipleObjectsTimeout, Boolean allowCreate, Boolean onlyOneCheckConnection, DbConnectionOptions     
userOptions, DbConnectionInternal& connection)
at System.Data.ProviderBase.DbConnectionPool.TryGetConnection(DbConnection owningObject, TaskCompletionSource`1 
retry, DbConnectionOptions userOptions, DbConnectionInternal& connection)
at System.Data.ProviderBase.DbConnectionFactory.TryGetConnection(DbConnection owningConnection, 
TaskCompletionSource`1 retry, DbConnectionOptions userOptions, DbConnectionInternal oldConnection, 
DbConnectionInternal& connection)
at System.Data.ProviderBase.DbConnectionInternal.TryOpenConnectionInternal(DbConnection outerConnection, 
DbConnectionFactory connectionFactory, TaskCompletionSource`1 retry, DbConnectionOptions userOptions)
at System.Data.ProviderBase.DbConnectionClosed.TryOpenConnection(DbConnection outerConnection, 
DbConnectionFactory connectionFactory, TaskCompletionSource`1 retry, DbConnectionOptions userOptions)
at System.Data.SqlClient.SqlConnection.TryOpenInner(TaskCompletionSource`1 retry)
at System.Data.SqlClient.SqlConnection.TryOpen(TaskCompletionSource`1 retry)
at System.Data.SqlClient.SqlConnection.Open()
at IRNXMLGateway.Controllers.IRNXMLGatewayController.GenericCall(String methodCall) in 
CODELINE:line 376
ClientConnectionId:92074b33-176a-4006-b7c7-892e01a3eea7

Я также пытался подключиться с помощью SSMS и столкнулся с той же проблемой тайм-аута.

Я могу успешно устанавливать соединения:

  • Подключение напрямую к хосту без слушателя
  • Прямое подключение к текущему IP-адресу слушателя
  • Увеличение времени ожидания соединения до 200 секунд
  • Удаление параметра MultiSubnetFailover в строке подключения

Я не сталкиваюсь с этой проблемой при попытке подключения с других серверов. В журналах событий SQL или Windows нет ошибок, которые помогли бы определить причину тайм-аутов. Трассировка сети показывает правильное подтверждение соединения с текущим IP-адресом прослушивателя. Ни на одном из серверов не включен брандмауэр или антивирус. Веб-сервер работает под управлением веб-версии сервера 2008, сервер SQL работает под управлением Windows Server 2012 и SQL Server 2012.


person vesuvious    schedule 01.05.2014    source источник
comment
Каково обычное время ожидания соединения, если вы не устанавливаете его на 200 секунд?   -  person Russ960    schedule 02.05.2014
comment
Время ожидания соединения по умолчанию (30 секунд). С других машин соединения обычно занимают ‹1 секунду.   -  person vesuvious    schedule 02.05.2014


Ответы (4)


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

Если это так, в MS есть статья базы знаний по этому вопросу.
http://support.microsoft.com/kb/2870437

person Russ960    schedule 01.05.2014
comment
Я видел эту базу знаний, но она применима только к случаям, когда экземпляр SQL 2012 работает на сервере 2008 R2, а мой экземпляр SQL работает на сервере 2012. - person vesuvious; 02.05.2014

Итак, «Я ДУМАЮ», я смог это исправить. Я переустановил .NET 4.5 и перезагрузил сервер, и теперь соединения устанавливаются без проблем. Моя текущая мысль заключается в том, что тот, кто изначально установил 4.5, не выполнил требуемую перезагрузку системы, оставив все в странном состоянии. Я собираюсь продолжать следить за этим сервером в течение нескольких недель, чтобы увидеть, не возникнет ли проблема снова. Я все еще ценю любые другие мнения о том, что могло вызвать это.

person vesuvious    schedule 02.05.2014

Таким образом, у нас было то же самое недавно, и, похоже, это совпало с патчем вторника от MS за сентябрь 2014 года. В качестве временного исправления я добавил «активный» IP-адрес слушателя в файл hosts, чтобы он всегда разрешался локально, и все работало. Я полагаю, что мог бы также удалить второй IP-адрес в отказоустойчивом кластере.

Telnet, похоже, подтверждает, что при подключении к прослушивателю требуется 21 секунда до истечения времени ожидания, что соответствует последовательному поиску IP-адресов прослушивателя в DNS и получению «неправильного». Все еще ищу окончательный ответ, но определенно собираюсь попробовать переустановить 4.5 .NET, поскольку я читал, что время ожидания библиотеки .NET истекает через 15 секунд, поэтому DNS никогда не получает возможности отправить второй IP-адрес клиенту.

person user4117247    schedule 07.10.2014

Это проблема на стороне клиента. У меня только что это произошло на Sql 2012 из клиентского приложения Windows 7. Совет, который вы получили ранее по поводу статьи в базе знаний, был правильным. Первоначально он был предоставлен мне инженером Microsoft для решения нашей проблемы.

Если у вас такая же проблема, вы можете создать тестовое приложение, которое зацикливает соединение. Установите время ожидания соединения = 6000 и отобразите счетчик циклов. Вы увидите, что сначала он колеблется, а затем увеличивает масштаб итераций.

Установите рекомендуемое исправление базы знаний.

Повторно запустите тестовое приложение, и вы не увидите никаких колебаний.

person Flora    schedule 08.10.2014