Ошибка проверки доступности URL конечной точки провайдера

Обновлено: 02.07.2024

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

Роли авторизации/разрешения: любой может выполнить эту операцию.

Эта тема включает следующие разделы:

Образец запроса

В приведенном ниже примере показан запрос информации о провайдере OpenID Connect для Google.

Пример URL-адреса запроса

Примеры заголовков запроса

Пример тела запроса

Заголовки запроса

Заголовок	Описание
Принять	application/json

Параметры запроса

Ответ

Пример ответа

В приведенном ниже образце ответа показано успешное выполнение этой операции для примера запроса к поставщику Google OpenID Connect.

Примеры заголовков ответов

Пример тела ответа

Заголовки ответов

Заголовок	Описание
Content-Type	application/json

Тело ответа

Тело ответа представляет собой файл конфигурации поставщика. Структура файла конфигурации и конкретные значения зависят от провайдера, но в целом он включает следующие типы информации, которая потребуется проверяющей стороне OpenID Connect:

Эмитент (поставщик OpenID Connect)

Конечные точки:

Конечная точка авторизации
Конечная точка токена
Конечная точка UserInfo
Конечная точка отзыва
URI JWKS

Коды ошибок/сообщения

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

Не удалось найти ресурс. Это может произойти по одной из следующих причин:

Чтобы разместить реплику доступности для группы доступности, экземпляр сервера должен иметь конечную точку зеркального отображения базы данных. Экземпляр сервера использует эту конечную точку для прослушивания сообщений групп доступности Always On от реплик доступности, размещенных на других экземплярах сервера. Чтобы определить реплику доступности для группы доступности, необходимо указать URL-адрес конечной точки экземпляра сервера, на котором будет размещена реплика. URL-адрес конечной точки определяет транспортный протокол конечной точки зеркалирования базы данных — TCP, системный адрес экземпляра сервера и номер порта, связанный с конечной точкой.

Термин "URL-адрес конечной точки" является синонимом термина "сетевой адрес сервера", используемого в пользовательском интерфейсе и документации зеркалирования базы данных.

Синтаксис URL конечной точки

Синтаксис URL-адреса конечной точки имеет следующий вид:

TCP:// :

— это строка, которая однозначно идентифицирует целевую компьютерную систему. Как правило, адрес сервера представляет собой имя системы (если системы находятся в одном домене), полное доменное имя или IP-адрес:

Поскольку узлы кластера Windows Server Failover Clustering (WSFC) находятся в одном домене, вы можете использовать имя компьютерной системы; например, SYSTEM46 .

Чтобы использовать IP-адрес, он должен быть уникальным в вашей среде. Мы рекомендуем использовать IP-адрес только в том случае, если он является статическим. IP-адрес может быть IP версии 4 (IPv4) или IP версии 6 (IPv6). Адрес IPv6 должен быть заключен в квадратные скобки, например: [ ].

Чтобы узнать IP-адрес системы, в командной строке Windows введите команду ipconfig.

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

имя_компьютера . сегмент_домена[. .сегмент_домена]

Содержание и количество сегментов домена определяются внутри компании или организации. Дополнительные сведения см. в разделе Поиск полного доменного имени далее в этом разделе.

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

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

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

Найдите строку, значение type_desc которой равно "DATABASE_MIRRORING", и используйте соответствующий номер порта.

Примеры

А. Использование имени системы

Следующий URL-адрес конечной точки указывает имя системы, SYSTEM46 и порт 7022.

Б. Использование полного доменного имени

С. Использование IPv4

Следующий URL конечной точки указывает адрес IPv4, 10.193.9.134 и порт 7023 .

Д. Использование IPv6

Следующий URL-адрес конечной точки содержит адрес IPv6, 2001:4898:23:1002:20f:1fff:feff:b3a3 и порт 7022 .

Поиск полного доменного имени системы

Чтобы найти полное доменное имя системы, в командной строке Windows введите:

IPCONFIG/ВСЕ

Чтобы сформировать полное доменное имя, соедините значения * * и

Например, конфигурация IP

Имя хоста . . . . . . : МОЙ СЕРВЕР

соответствует следующему полному доменному имени:

Если вам нужна дополнительная информация о полном доменном имени, обратитесь к системному администратору.

Связанные задачи

Настройка конечной точки зеркального отображения базы данных

Укажите URL-адрес конечной точки при добавлении или изменении реплики доступности (SQL Server)

Просмотр информации о конечной точке зеркального отображения базы данных

В этом разделе содержится информация, которая поможет вам устранить типичные проблемы с настройкой экземпляров сервера для групп доступности Always On. Типичные проблемы с конфигурацией включают в себя: группы доступности Always On отключены, учетные записи настроены неправильно, конечная точка зеркального отображения базы данных не существует, конечная точка недоступна (ошибка SQL Server 1418), отсутствует доступ к сети и не удается выполнить команду присоединения к базе данных (SQL Server Ошибка 35250).

Убедитесь, что выполняются предварительные требования для групп доступности Always On. Дополнительные сведения см. в разделе Предварительные требования, ограничения и рекомендации для групп доступности Always On (SQL Server).

В этой теме:

Раздел	Описание
Всегда включенные группы доступности не включены< /td>	Если экземпляр SQL Server не включен для групп доступности Always On, экземпляр не поддерживает создание группы доступности и не может размещать какие-либо реплики доступности.
Учетные записи	Обсуждает требования для правильной настройки учетных записей, под которыми работает SQL Server.
Конечные точки	Обсуждает, как диагностировать проблемы с конечная точка зеркального отображения базы данных экземпляра сервера.
Доступ к сети	Документирует требование о том, что каждый экземпляр сервера, на котором размещена реплика доступности, должен иметь доступ порт каждого другого экземпляра сервера через TCP.
Доступ к конечной точке (ошибка SQL Server 1418)	Содержит информацию об этом сообщении об ошибке SQL Server.
Сбой присоединения к базе данных (ошибка SQL Server 35250)	Discu определяет возможные причины и способы устранения сбоя при присоединении баз данных-получателей к группе доступности из-за того, что соединение с первичной репликой неактивно.
Маршрутизация только для чтения работает неправильно.
Связанные задачи	Содержит список ориентированных на задачи тем в электронной документации по SQL Server, которые особенно важны для устранения неполадок в конфигурации группы доступности.
Связанное содержимое	Содержит список соответствующих ресурсов, которые являются внешними по отношению к электронной документации по SQL Server.

Всегда включенные группы доступности не включены

Функция групп доступности Always On должна быть включена на каждом из экземпляров SQL Server. Дополнительные сведения см. в разделе Включение и отключение групп доступности Always On (SQL Server).

Аккаунты

Учетные записи, под которыми работает SQL Server, должны быть правильно настроены.

У учетных записей есть правильные разрешения?

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

Если два экземпляра сервера работают под разными учетными записями, каждая учетная запись должна быть создана в главном экземпляре удаленного сервера, и этому логину должны быть предоставлены разрешения CONNECT для подключения к конечной точке зеркального отображения базы данных этого экземпляра сервера. Дополнительные сведения см. в разделе Настройка учетных записей входа для зеркального отображения базы данных или групп доступности Always On (SQL Server). Вы можете использовать следующий запрос для каждого экземпляра, чтобы проверить, есть ли у входа разрешения CONNECT:

Если SQL Server работает под встроенной учетной записью, такой как локальная система, локальная служба или сетевая служба, или учетной записью, не относящейся к домену, необходимо использовать сертификаты для проверки подлинности конечной точки. Если ваши учетные записи служб используют учетные записи домена в том же домене, вы можете предоставить доступ CONNECT для каждой учетной записи службы во всех расположениях реплик или использовать сертификаты. Дополнительные сведения см. в статье Использование сертификатов для конечной точки зеркального отображения базы данных (Transact-SQL).

Конечные точки

Конечные точки должны быть правильно настроены.

Убедитесь, что каждый экземпляр SQL Server, на котором будет размещаться реплика доступности (каждое расположение реплики), имеет конечную точку зеркального отображения базы данных. Чтобы определить, существует ли конечная точка зеркального отображения базы данных на данном экземпляре сервера, используйте представление каталога sys.database_mirroring_endpoints:

Проверьте правильность номеров портов.

В случае проблем с настройкой групп доступности Always On, которые сложно объяснить, мы рекомендуем проверить каждый экземпляр сервера, чтобы определить, прослушивает ли он правильные порты.

Убедитесь, что конечные точки запущены (STATE=STARTED). На каждом экземпляре сервера используйте следующую инструкцию Transact-SQL:

Дополнительные сведения о столбце state_desc см. в разделе sys.database_mirroring_endpoints (Transact-SQL).

Чтобы запустить конечную точку, используйте следующую инструкцию Transact-SQL:

Убедитесь, что для входа с другого сервера есть разрешение CONNECT. Чтобы определить, у кого есть разрешение CONNECT для конечной точки, на каждом экземпляре сервера используйте следующую инструкцию Transact-SQL:

Убедитесь, что в URL конечной точки используется правильное имя сервера

Для имени сервера в URL-адресе конечной точки рекомендуется использовать полное доменное имя (FQDN), хотя вы можете использовать любое имя, которое однозначно идентифицирует компьютер. Адрес сервера может быть именем Netbios (если системы находятся в одном домене), полным доменным именем (FQDN) или IP-адресом (предпочтительно статическим IP-адресом). Рекомендуется использовать полное доменное имя.

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

Затем сравните выходные данные endpoint_url с именем сервера (Netbios или FQDN). Чтобы запросить Netbios и полное доменное имя, запустите в командной строке на локальной реплике следующее:

Чтобы запросить имя сервера удаленного компьютера, запустите его из командной строки. Затем сравните endpoint_url

Доступ к сети

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

Используйте Telnet для проверки подключения. Вот примеры команд, которые вы можете использовать:

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

Если подключение Telnet к IP-адресу работает, а к ServerName — нет, вероятно, проблема в DNS или разрешении имен

Если соединение работает по имени сервера, а не по IP-адресу, то на этом сервере может быть определено несколько конечных точек (возможно, другой экземпляр SQL), которые прослушивают этот порт. Хотя состояние конечной точки рассматриваемого экземпляра показывает «СТАРТИРОВАНО», другой экземпляр может на самом деле иметь привязку к порту и препятствовать тому, чтобы правильный экземпляр прослушивал и устанавливал TCP-соединения.

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

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

Захватите выходные данные NETSTAT -a и убедитесь, что статус ПРОСЛУШИВАЕТСЯ или УСТАНОВЛЕН на IP-порту для указанной конечной точки

Доступ к конечной точке (ошибка SQL Server 1418)

Это сообщение SQL Server указывает, что сетевой адрес сервера, указанный в URL-адресе конечной точки, недоступен или не существует, и предлагает проверить имя сетевого адреса и повторить команду.

Сбой присоединения к базе данных (ошибка SQL Server 35250)

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

Сообщение 35250 Соединение с первичной репликой неактивно. Команда не может быть обработана.

Решение:

Сводка шагов представлена ниже.

Подробные пошаговые инструкции см. в статье Ошибка ядра MSSQLSERVER_35250

Убедитесь, что конечная точка создана и запущена.
Проверьте, можете ли вы подключиться к конечной точке через Telnet, и убедитесь, что никакие правила брандмауэра не блокируют подключение
Проверьте наличие ошибок в системе. Вы можете запросить в sys.dm_hadr_availability_replica_states значение last_connect_error_number, которое может помочь вам диагностировать проблему присоединения.
Убедитесь, что конечная точка определена так, чтобы она правильно соответствовала IP/порту, используемому AG.
Проверьте, есть ли у учетной записи сетевой службы разрешение ПОДКЛЮЧИТЬСЯ к конечной точке.
Проверьте возможные проблемы с разрешением имен.
Убедитесь, что на вашем SQL Server установлена последняя сборка (предпочтительно последняя сборка, чтобы не столкнуться с исправленными проблемами).

Маршрутизация только для чтения работает неправильно

Убедитесь, что вы настроили маршрутизацию только для чтения, следуя инструкциям в документе Настройка маршрутизации только для чтения.

Обеспечить поддержку клиентского драйвера

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

Если вы подключаетесь к прослушивателю распределенного сетевого имени (DNN), провайдер также должен поддерживать параметр MultiSubnetFailover

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

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

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

Если вы используете программы командной строки, такие как SQLCMD, убедитесь, что вы указали правильные переключатели для имени сервера. Например, в SQLCMD вы должны использовать переключатель -S в верхнем регистре, который указывает имя сервера, а не переключатель -s в нижнем регистре, который используется для разделителя столбцов.
Пример: sqlcmd -S AG_Listener,port -E -d AgDb1 -K ReadOnly -M

Убедитесь, что прослушиватель группы доступности подключен к сети. Чтобы убедиться, что прослушиватель группы доступности подключен к сети, выполните следующий запрос на первичной реплике:

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

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

Чтобы просмотреть свойства каждой реплики, вы можете запустить этот запрос и проверить конечную точку подключения (URL) реплики только для чтения.

Чтобы просмотреть список маршрутизации, доступный только для чтения, и сравнить его с URL-адресом конечной точки:

Чтобы изменить список маршрутизации, доступный только для чтения, вы можете использовать такой запрос:

Убедитесь, что порт READ_ONLY_ROUTING_URL открыт. Убедитесь, что брандмауэр Windows не блокирует порт READ_ONLY_ROUTING_URL. Настройте брандмауэр Windows для доступа к ядру базы данных для каждой реплики в списке read_only_routing_list и для всех клиентов, которые будут подключаться к этим репликам.

Если вы используете SQL Server на виртуальной машине Azure, необходимо выполнить дополнительные действия по настройке. Убедитесь, что группа безопасности сети (NSG) каждой реплики виртуальной машины разрешает трафик на порт конечной точки и порт DNN, если вы используете прослушиватель DNN. Если вы используете прослушиватель VNN, необходимо убедиться, что балансировщик нагрузки настроен правильно.

Убедитесь, что READ_ONLY_ROUTING_URL (TCP://системный-адрес:порт) содержит правильное полное доменное имя (FQDN) и номер порта. См.:

Убедитесь в правильной конфигурации сети SQL Server в диспетчере конфигурации SQL Server.

Убедитесь на каждой реплике в read_only_routing_list, что:
- Удаленное подключение к SQL Server включено
- TCP/IP включен
- IP-адреса настроены правильно
Вы можете быстро убедиться, что все они правильно настроены, если сможете подключиться с удаленного компьютера к имени экземпляра SQL Server целевой вторичной реплики, используя синтаксис TCP:SQL_Instance.

Недавно у нас был проект по настройке групп доступности AlwaysOn SQL Server между тремя узлами, размещенными в среде с несколькими подсетями.Среда с несколькими подсетями требует, чтобы кластер Windows использовался в качестве основы для AlwaysOn, а каждый из серверных узлов располагался в нескольких/разных подсетях. Если вы хотите узнать, как настроить SQL Server AlwaysOn между кластером с несколькими подсетями, я рекомендую вам прочитать этот совет.

В этом совете я объясню, как исправить проблему, с которой я столкнулся при настройке SQL Server AlwaysOn. Этот совет поможет вам решить эту проблему и поможет перенастроить SQL Server AlwaysOn в сети с несколькими подсетями.

Решение

Согласно электронной документации «Группы доступности AlwaysOn — это решение для обеспечения высокой доступности и аварийного восстановления, которое представляет собой альтернативу зеркальному отображению базы данных на уровне предприятия. Представленные в SQL Server 2012 группы доступности AlwaysOn обеспечивают максимальную доступность набора пользовательских баз данных для предприятия. Группа доступности поддерживает среду отработки отказа для дискретного набора пользовательских баз данных, известных как базы данных доступности, которые переходят на другой ресурс вместе. Группа доступности поддерживает набор первичных баз данных для чтения и записи и от одного до восьми наборов соответствующих вторичных баз данных. Базы данных-получатели можно сделать доступными только для чтения и/или для некоторых операций резервного копирования."

Сценарий конфигурации и настройка

У нас есть три машины с именами PRI-DB1 (IP: 10.X.3.XXX), PRI-DB2 (IP: 10.X.4.XXX) и SEC-DB2 (IP: 172.X.15. ХХХ). IP-адреса машин отражают их подсеть, указывая на то, что они принадлежат к разным сериям. PRI-DB1 и PRI-DB2 размещаются в корпоративном центре обработки данных, тогда как SEC-DB2 размещается на облачной платформе Amazon. Все три машины работают под управлением Windows Server 2012 R2 Enterprise Edition и SQL Server 2014 Enterprise Edition. PRI-DB1 будет первичной репликой, а оставшиеся два узла будут вторичными репликами. Репликация данных между PRI-DB1 и PRI-DB2 будет использовать режим синхронной фиксации, а режим аварийного переключения будет автоматическим без потери данных, который можно использовать для обеспечения высокой доступности в случае выхода из строя первичной реплики. Репликация данных между PRI-DB1 и SEC-DB2 использует асинхронный режим, а аварийный режим — ручной, что может привести к некоторой потере данных в случае аварии.

Прежде чем продолжить, я хотел бы сообщить вам, что я выполнил пошаговый процесс настройки SQL Server AlwaysOn между кластерами с несколькими подсетями, но закончился ошибкой 35250 в конце окна настройки SQL Server AlwaysOn. . Я не могу настроить SQL Server AlwaysOn из-за ошибки Не удалось присоединиться к базе данных "DRTest" к группе доступности "DBAG" на реплике доступности "PRI-DB2" (ошибка: 35250). Хотя вы можете увидеть такие сведения, как вторичные реплики, базы данных и т. д., созданные в папке AlwaysOn High Availability, несмотря на появление этой ошибки, но базы данных не будут присоединены к группе доступности, что мы сделаем позже в этом совете, чтобы исправить проблему. /p>
В этом совете я не рассматривал установку SQL Server и отказоустойчивого кластера Windows Server, а также начальные шаги по настройке AlwaysOn SQL Server. Вы можете использовать мои последние советы для настройки группы доступности AlwaysOn. Я предполагаю, что вы позаботитесь об этих шагах, прежде чем решить эту проблему с помощью этого совета.

ПРИМЕЧАНИЕ: СНАЧАЛА ОБЯЗАТЕЛЬНО ВНЕДРЯЙТЕ ЭТО РЕШЕНИЕ НА МЛАДШИЙ ЖИЗНЕННЫЙ ЦИКЛ. НЕ ВНОСИТЕ НИКАКИХ ИЗМЕНЕНИЙ В ПРОИЗВОДСТВО БЕЗ НАДЛЕЖАЩИХ ИСПЫТАНИЙ В УСЛОВИЯХ С МАЛЫМ СРОКОМ СЛУЖБЫ.

Устранение ошибки 35250

Как я уже сказал выше, я не буду показывать вам шаги по настройке SQL Server AlwaysOn, поскольку я предполагаю, что вы уже выполнили шаги, упомянутые в моем последнем совете. Здесь я перейду непосредственно к последнему окну конфигурации SQL Server AlwaysOn, где мы получим ошибки (если они есть) после выполнения. Вы можете щелкнуть ссылку "Ошибка", чтобы получить сведения об ошибке, как показано на снимке экрана ниже.

Я провел небольшое исследование в социальных сетях и Интернете, чтобы исправить эту проблему. Я нашел эту ссылку MSDN, где было предложено много решений. Я решил сначала проверить статус конечной точки на всех репликах, выполнив приведенную ниже команду.

Сначала я выполнил приведенную выше команду на первичной реплике, и результат отмечен как "Подключено".

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

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

По умолчанию AlwaysOn настраивает конечные точки на использование порта 5022, который мы сохранили в нашей конфигурации. Вы можете видеть, что номер порта конечной точки 5022 используется на изображении выше. Вы можете запросить sys.tcp_endpoints для каждой реплики, чтобы подтвердить, какой порт используется в вашей среде. В соответствии с MSDN «Порт 5022 используется первичной и вторичной репликами для синхронизации и связи. Входящий трафик должен быть разрешен на этом порту. Тестирование показало, что если входящий трафик порта 5022 или в обоих случаях вы не сможете создать группу доступности, и появится сообщение 35250."

Итак, здесь мы создадим новое правило входящего порта для порта 5022 на основном и обоих дополнительных серверах. Запустите консоль «Брандмауэр Windows в режиме повышенной безопасности», чтобы создать новое правило для входящего порта. Вы можете ввести «Брандмауэр Windows в режиме повышенной безопасности» в параметре поиска Windows, чтобы получить эту консоль, как показано на изображении ниже.

Нажмите "Брандмауэр Windows в режиме повышенной безопасности", как показано выше.

Появится консоль «Брандмауэр Windows в режиме повышенной безопасности». Вы можете увидеть консоль «Брандмауэр Windows в режиме повышенной безопасности» на снимке экрана ниже.

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

На экране появится окно под названием «Мастер создания правила для нового входящего трафика». Вы можете увидеть это окно на снимке экрана ниже.

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

В следующем окне выберите соответствующий протокол и номер порта, для которых мы создаем это правило. Выберите TCP в качестве протокола, выберите опцию «Определенные локальные порты» и введите номер порта 5022, как показано на рисунке ниже. Нажмите кнопку «Далее», чтобы продолжить.

Следующее окно с названием «Действие» будет использоваться для настройки действия, которое будет выполняться при использовании этого правила. Выберите соответственно согласно вашему требованию. Здесь я выбрал первый вариант: «Разрешить подключение», как показано на изображении ниже.

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

Следующий вариант — настроить профиль для этого правила. Здесь вы увидите три варианта. Я перейду к варианту по умолчанию, который предлагает все три варианта, но вы можете выбрать в соответствии со своими требованиями.

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

< бр />
Теперь нажмите кнопку "Готово", чтобы применить это изменение. После того, как вы нажмете кнопку "Готово", это окно исчезнет, и новое правило можно будет увидеть на правой панели правил для входящих подключений.

Повторите те же действия для всех реплик.Я повторил эти шаги на обеих репликах PRI-DB2 и SEC-DB2.

Повторное присоединение баз данных доступности к группе доступности

Как показано в начале этого совета, после завершения установки SQL Server AlwaysOn будет выдана ошибка 35250. Однако программа установки создаст все необходимые сведения, такие как вторичные реплики, базы данных и т. д., в папке AlwaysOn High Availability. . Единственное, что не произойдет, — это связь/передача данных между этими репликами, поскольку базы данных доступности не будут присоединены к группе доступности. Теперь это исправлено с помощью шагов из раздела выше. Как только базы данных будут успешно добавлены в группу доступности, AlwaysOn будет успешно работать.

Теперь подключитесь к вторичным репликам с помощью SQL Server Management Studio, где вы столкнулись с проблемой. Разверните папку «AlwaysOn High Availability», затем «Группы доступности», затем разверните имя группы доступности «DBAG» и, наконец, разверните «Базы данных доступности». Вы можете видеть обе базы данных, но со значком предупреждения. Статус обеих баз данных должен быть зеленым, если проблем нет. Начнем с базы данных «Тест». Щелкните правой кнопкой мыши базу данных «Тест» и выберите «Присоединиться к группе доступности», как показано ниже.

< бр />
После того, как вы выберете параметр "Присоединиться к группе доступности", появится мастер "Присоединить базу данных к группе доступности "DBAG"", как показано ниже.

Мы видим имя базы данных, которую мы присоединяем к группе доступности DBAG. Проверьте детали в окне и нажмите кнопку «ОК», чтобы продолжить это изменение. Как только вы нажмете кнопку «ОК», он начнет выполняться в течение нескольких секунд, а затем исчезнет с экрана. Вы можете видеть, что предупреждающий знак базы данных «Тест» теперь изменился в SSMS и теперь показывает зеленый статус, что означает, что база данных присоединилась к группе доступности. В случае возникновения ошибки приведенный выше экран не исчезнет, но в этом окне будут отображаться сведения об ошибке. Вы можете увидеть процесс обработки на изображении ниже.

< бр />
Проделайте то же самое для других баз данных, которые столкнулись с той же проблемой на вторичных репликах. У нас есть еще одна база данных с именем «DRTest», поэтому мы сделали то же самое для этой базы данных. Обе базы данных успешно присоединены к группе доступности DBAG на этой вторичной реплике.

Если у вас есть несколько вторичных реплик и вы столкнулись с этой проблемой и на них, повторите то же упражнение.

Подключиться к вторичной реплике. Разверните папку «AlwaysOn High Availability», затем «Группы доступности», затем разверните имя группы доступности «DBAG» и, наконец, разверните «Базы данных доступности». Вы можете увидеть свои базы данных доступности, в которых возникла проблема, с помощью значка предупреждения. Статус обеих баз данных должен быть зеленым, если проблем нет. Обязательно присоедините все затронутые базы данных к соответствующей группе доступности. Я сделал это на обеих вторичных репликах для обеих баз данных, и, наконец, после этого ваша база данных доступности будет выглядеть так, как показано на снимке экрана ниже.

Проверка

Теперь мы проверим эту конфигурацию, чтобы убедиться, что SQL Server AlwaysOn настроен и работает правильно. Мы запустим отчет панели мониторинга, чтобы увидеть статус AlwaysOn, а затем выполним проверку аварийного переключения, чтобы убедиться, что аварийное переключение работает. Подключитесь к первичной реплике, разверните папку «AlwaysOn High Availability» до имени вашей группы доступности. Здесь имя группы доступности — DBAG. Щелкните правой кнопкой мыши имя группы доступности DBAG и выберите параметр «Показать панель мониторинга», чтобы отобразить отчет панели мониторинга на правой панели.

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

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

Теперь мы видим, что первичной репликой является PRI-DB2. PRI-DB1 и SEC-DB2 действуют как вторичные реплики, что означает, что конфигурация SQL Server AlwaysOn работает правильно, и данные также реплицируются во вторичные реплики.

Теперь мы можем проверить состояние конечной точки на вторичной реплике, как мы это делали на шаге 2 в первом разделе, где конечная точка показывала "ОТКЛЮЧЕНО" на вторичной реплике. Теперь запустите код SQL, который мы запустили на шаге 2, на вторичной реплике и посмотрите, что изменилось.

Теперь он отображается как ПОДКЛЮЧЕН, тогда как до создания правила для входящего трафика он был отключен.

Читайте также: