Service broker что это
Управление компонентом Service Broker
В SMO объект ServiceBroker является классом верхнего уровня, который заключает всю функциональность компонента Компонент Service Broker. Реализация компонента Компонент Service Broker необходима для каждой базы данных, которая участвует в работе приложений с распределенным обменом сообщениями. Поэтому объект ServiceBroker является потомком объекта Database.
Объект ServiceBroker содержит коллекции следующих объектов, используемых в определении реализации компонента Компонент Service Broker.
Объекты MessageType представляют типы сообщений, которые определяют содержимое сообщений.
Объекты MessageTypeMapping представляют контракты, которые указывают направление и тип сообщений заданного диалога.
Объекты ServiceQueue хранят сообщения до их отправки и после их получения. Они обеспечивают асинхронную связь между службами, а также и другие преимущества, такие как автоматическая блокировка сообщений внутри группы диалога.
Объект BrokerService представляет собой компонент Компонент Service Broker, которые являются адресуемыми конечными точками для диалогов. Сообщения компонента Компонент Service Broker отправляются от одной службы к другой. Служба определяет очередь для ожидания сообщений и указывает контракты, для которых служба может быть целью.
Объекты RemoteServiceBinding представляют настройки, которые компонент Компонент Service Broker использует для безопасности и проверки подлинности при связи с удаленным сервером.
Объекты ServiceRoute представляют маршрут компонента Компонент Service Broker, который содержит информацию о нахождении службы и базы данных, в которой она определена. Маршрут необходим для доставки сообщения. По умолчанию каждая база данных содержит маршрут, который указывает расположение как текущий экземпляр SQL Server.
Один день из жизни DBA Microsoft SQL Server
В арсенале Microsoft SQL Server есть одна интересная штука – service broker. По сути своей это очередь сообщений, встроенная в СУБД, способная обеспечить транзакционную целостность данных. Вещь удобная и, в грамотных руках, способная выстроить систему обмена между SQL Server’ами без применения дополнительных внешних сервисов – прямо из коробки.
С одной стороны service broker удобен, но с другой – от него не мало сюрпризов, способных поломать голову нюансами своей работы. О решении одного из таких сюрпризов поговорим прямо сейчас.
Обнаружили, что логи MS SQL Server, одной из наших, систем жутко забиты сообщениями от service broker типа :
Не долгие поиски на просторах всемирной сети так или иначе выводили на информацию о том, что какие то данные в БД закораптились и требуется их обнаружение (для дальнейшего восстановления) при помощи инструкции DBCC CHECKDB. Счастье было не долгим, ибо данный подход не выявил ни одной проблемы – ни в пользовательских БД, ни в системных.
Так как логи продолжали ужасать своим натиском (пару десятков записей за несколько секунд), а первый план по выявлению причин этого “наводнения” провалился – было решено вести поиски на стороне service broker, ибо читался след от брокера – как минимум по словам “dialog transmission ”.
Подобные поиски в системах начинаются с просмотра очереди на отправку sys.transmission_queue – не стал исключением и наш случай. Первый же select из sys.transmission_queue вывалил на экран тот самый “Could not continue scan with NOLOCK due to data movement”, что с одной стороны вселило уверенности, что копаем в правильную сторону, но с другой – как выявить проблему, если select заканчивается таким сообщением?
Лезем в данные по конечным точкам диалогов sys.conversation_endpoints. С ужасом обнаруживаю, что там висит около 12 миллионов не закрытых диалогов. Первые 10 минут зачистки ненужных накоплений показали, что впереди нас ждет целая неделя ожиданий – ибо чистка протекала крайне медленно. Само закрытие диалога было долгим. У нас был главный подозреваемый — куча не закрытых диалогов service broker’а и надо было его “расколоть”.
Так как сидеть целую неделю, и закрывать диалоги не хотелось, был накидан такой план:
через sqlcmd пачками вычитываем хендлеры подвисших диалогов
формируем sql batch на завершение полученых диалогов
через sqlcmd выполняем сформированный sql batch и гоняем это по циклу, пока не закроем все подвисшие диалоги
batch.sql (пример sql batch – для пункта 2)
end_conversation.bat (батник для пунктов 1 и 3)
Этот товарищ отработал чуть менее двух суток и закрыл все подвисшие диалоги. Как видно из примера – все эти диалоги были открыты для одного конкретного сервиса. С самим удаленным сервисом брокера разобрались до начала массового закрытия диалогов.
К счастью или сожалению, но после закрытия всех не нужных диалогов брокера – ошибки в логах так и не прекратились массово появляться.
Следующей мыслью было потушить service broker end point на СУБД в целом и отключить брокер на основной БД в частности, но и это, увы, не спасло от продолжающихся ошибок в логах.
В какой то из дней решения вопроса возникла необходимость переключиться на зеркало от основной БД. Именно в момент переключения на зеркало нашей БД и вылезла в логах информация о проблеме:
16:42:40.41 spid41s SQL Server detected a logical consistency-based I/O error: incorrect pageid (expected 6:260707; actual 559:-641654744). It occurred during a read of page (6:260707) in database ID 2 at offset 0x0000007f4c6000 in file ‘D:\TempDB\tempdb_mssql_5.ndf’. Additional messages in the SQL Server error log or operating system error log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.
Глядя на неё и стало понятно, что виновником торжества выступает tempdb нашей СУБД.
Как известно, у tempdb одно лекарство – рестарт службы sql. Выбиваем окно у бизнеса для простоя сервиса и перезагружаем основную ноду. После рестарта сервера логи перестало заваливать.
Как оказалось – проблема на самом деле крылась в закорапченных данных. Так, что применяя DBCC CHECKDB – не забывайте применять его и к tempdb и следите за диалогами.
Компонент Service Broker с группами доступности AlwaysOn (SQL Server)
В этом разделе содержатся сведения о настройке компонента Service Broker для работы с Группы доступности AlwaysOn в SQL Server.
Требования к службе в группе доступности для получения удаленных сообщений
Убедитесь, что группа доступности имеет прослушиватель.
Убедитесь, что конечная точка компонента Service Broker существует и правильно настроена.
Установите параметр LISTENER_IP в значение ALL. Этот параметр разрешает соединения по любому допустимому IP-адресу, привязанному к прослушивателю группы доступности.
Установите в параметре PORT компонента Service Broker одинаковый номер порта во всех экземплярах сервера.
В следующем примере создается конечная точка компонента Service Broker с проверкой подлинности Windows, которая использует порт компонента Service Broker по умолчанию (4022) и прослушивает все допустимые IP-адреса.
Дополнительные сведения см. в разделе CREATE ENDPOINT (Transact-SQL).
Компонент SQL Server Service Broker не поддерживает несколько подсетей. Задайте для параметра RegisterAllProvidersIP значение 0 и убедитесь, что кластер имеет необходимое разрешение в DNS для использования статических IP-адресов. Дополнительные сведения см. в разделе Настройка прослушивателя группы доступности. При попытке использовать отключенный IP-адрес Service Broker может отложить сообщение с состоянием CONVERSING.
Предоставьте разрешение CONNECT на конечную точку.
Предоставьте разрешение CONNECT на конечную точку компонента Service Broker роли PUBLIC или некоторому имени входа.
В следующем примере разрешение на подключение к конечной точке компонента Service Broker с именем broker_endpoint предоставляется роли PUBLIC.
Дополнительные сведения см. в статье GRANT (Transact-SQL).
Убедитесь, что база данных msdb содержит маршрут AutoCreatedLocal или маршрут к некоторой службе.
По умолчанию все пользовательские базы данных, включая msdb, содержат маршрут AutoCreatedLocal. Он соответствует имени любой службы и любому экземпляру компонента Service Broker и указывает, что сообщение должно быть доставлено внутри текущего экземпляра. Маршрут AutoCreatedLocal имеет более низкий приоритет, чем маршруты, в которых явно указывается служба, обменивающаяся данными с удаленным экземпляром.
Сведения о создании маршрутов см. в статьях Примеры маршрутизации для компонента Service Broker (версия SQL Server 2008 R2 электронной документации) и CREATE ROUTE (Transact-SQL).
Требования к отправке сообщений удаленной службе в группе доступности
Создайте маршрут к целевой службе.
Настройте маршрут следующим образом.
Задайте в параметре ADDRESS IP-адрес прослушивателя группы доступности, в которой размещается база данных службы.
Задайте в параметре PORT порт, указанный в конечной точке компонента Service Broker в каждом из удаленных экземпляров SQL Server.
Дополнительные сведения см. в статье CREATE ROUTE (Transact-SQL).
Убедитесь, что база данных msdb содержит маршрут AutoCreatedLocal или маршрут к некоторой службе. (Дополнительные сведения см. в подразделе Требования к службе в группе доступности для получения удаленных сообщенийвыше.)
Компонент Service Broker
SQL Server Компонент Service Broker предоставляют встроенную поддержку для обмена сообщениями и очередей в Компонент SQL Server Database Engine и Управляемом экземпляре SQL Azure. Это облегчает разработчикам создание сложных, надежных распределенных приложений, использующих компоненты Компонент Database Engine для связи между разнородными базами данных.
Когда следует использовать компонент Service Broker
Обзор
Компонент Service Broker — это инфраструктура доставки сообщений, дающая возможность создания ориентированных на службы приложений в базе данных. В отличие от функциональных возможностей классической обработки, которые требуют постоянно считывать данные из таблиц и обрабатывать их во время жизненного цикла запроса, в ориентированных на службы приложениях имеются службы базы данных, которые позволяют обмениваться сообщениями. Каждая служба имеет очередь, куда помещаются сообщения до их обработки.
Сообщения в очередях можно извлечь с помощью команды Transact-SQL RECEIVE или процедуры активации, которая будет вызываться всякий раз, когда сообщение поступает в очередь.
Создание служб
Службы базы данных создаются с помощью инструкции Transact SQL CREATE SERVICE. Службы могут быть связаны с очередью сообщений, созданной с помощью инструкции CREATE QUEUE:
Отправка сообщений
Обработка сообщений
После обработки всех сообщений из очереди необходимо закрыть диалог с помощью инструкции Transact-SQL END CONVERSATION.
Где найти документацию по компоненту Service Broker?
См. информацию об инструкциях CREATE, ALTER и DROP в разделе Инструкции на языке описания данных (DDL) (Transact-SQL)
Новые возможности (компонент Service Broker)
Service Broker и Управляемый экземпляр SQL Azure
Обмен сообщениями через Service Broker поддерживается только между управляемыми экземплярами SQL Azure:
Защита транспорта поддерживается, а защита обмена данными — нет:
Компонент Service Broker включен по умолчанию и его нельзя отключить. Следующие параметры ALTER DATABASE не поддерживаются:
В SQL Server 2019 (15.x) не были внесены значимые изменения. В SQL Server 2012 (11.x)появились следующие изменения.
Сообщения могут отправляться в несколько целевых служб (многоадресная рассылка)
Синтаксис инструкции SEND (Transact-SQL) расширен для включения многоадресной рассылки благодаря поддержке нескольких дескрипторов диалога.
Очереди предоставляют время нахождения сообщения в очереди
Очереди содержат новый столбец message_enqueue_time, в котором показано время нахождения сообщения в очереди.
Service Broker, соединяемся через сертификаты
Случилось так, что мне пришлось разобраться с тем, как в Service Broker сделать передачу сообщений, используя для аутентификации сертификаты.
Исходные:
— 2 компьютера mf-2007 и mf-1689 (названия взяты от балды [названия рабочих компов]);
— На обоих Microsoft SQL Server 2014.
Задача послать сообщение.
Решение под катом (пошаговая инструкция).
Итак, начнём с mf-1689. Для mf-2007 всё то же самое с точностью до цифр.
Выполнять нужно параллельно на 2-х машинах.
Создаём мастер ключ:
Создаём логин для пользователя, от имени которого будет проходить авторизация и аутентификация:
Создадим пользователя в мастере, к нему привяжем сертификат:
Создадим сертификат для аутентификации и сохраним его открытый ключ:
Этот ключик перепишем на соседний компьютер и восстановим из него сертификат для подключения:
Создаём конечную точку для сервис брокера и предоставляем нашему пользователю право на коннект через эту конечную точку:
Создадим БД, в которой будем держать очереди и сервисы:
Создадим мастер ключ в новой БД:
Для авторизации пользователя внутри БД создадим сертификат и сохраним его:
Далее файлик с сертификатом перенесём на другой комп и создадим сертификат из файлика:
Создадим объекты брокера (очередь, тип сообщения, контракт, сервис, маршрут):
Создадим привязку для определения учётных данных безопасности:
И дадим права пользователю на отправку сообщений:
Если вы проделали всё зеркально на 2-х машинах, то вы готовы к обмену сообщениями: