Сервисный брокер и Alwayson Groups Groups: нечетное поведение очереди передачи

Question

Я также опубликовал этот вопрос в своем блоге: http://www.sqldiablo.com/2012/04/15/service-broker-alwayson-vailability-groups-odd-transmission-queue-behavior/.

В течение последних нескольких месяцев я работал над проектом, в котором будут использоваться сервисный брокер и AlwaysOn доступных групп для достижения некоторых целей HA и DR компании, над которой я работаю (Подробнее: http://www.sqldiablo.com/service-broker-replication/) Совсем недавно я смог внедрить полное решение в моей лаборатории разработки и указать на экземпляр нашего веб -сайта. В то время как мы тренировались в нашей базе данных и на веб -сайте, чтобы оба хорошо работали с моим проектом репликации сервисного брокера, я начал замечать какое -то странное поведение в сервисном броке Попытка увидеть, видел ли кто -нибудь еще эту проблему, и может иметь представление о том, как ее решить.

Настройка:

У меня есть Hyper-V-хост, управляющий 6 Windows Server 2008 R2 VMS (BTDEVSQLVM1-BTDEVSQLVM6). Виртуальные машины сгруппированы в 2-узловые WSFCs с кворумом обмена узлами и файлами. Я установил автономные экземпляры Developer Edition SQL 2012 на каждом из виртуальных машин и создал группу доступности со слушателем на каждом кластере (Sbrepldistrib, SBREPL1 и SBREPL2).

Для целей этого поста в блоге я сосредоточусь на общении между SBREPL1 и SBREPLDISTRIB. На рисунке ниже показаны объекты сервисного брокера для каждой стороны разговора:

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

Сервисный брокер конечные точки и маршруты настроены на Эта статья MSDN. Проезд SBREPL_RECEIVE в MSDB предназначен для службы локального сервера (// SBREPLDISTRIB/SBREPL на SBREPLDISTRIB и // SBREPL1/SBREPL на SBREPL1) и указывает на локальный экземпляр. Маршрут SBREPL_SEND на SBREPL1 MAPS SERVICE // SBREPLDISTRIB/SBREPL TO TCP: // SBREPLDISTRIB: 4022, и маршрут SBREPL_SEND_SBREPL1 на SBREPLDISTRIB - это аналогичное картирование для Сервиса на SBREPL1.

Ожидаемое поведение:

Мое понимание того, как сервисный брокер обрабатывает отправку и получение сообщения, таким образом, (это довольно упрощено. В книге Клауса Ашенбреннера есть гораздо больше подробностей в книге Клауса Ашенбреннера «Pro SQL Server 2008 Service Broker»):):

1. Приложение инициатора создает сообщение (в данном случае хорошо сформирован XML)
2. Если существует существующий диалоговый разговор между службой инициатора и целевым сервисом, который находится в статусе разговора, приложение может просто отправить сообщение на существующую беседку. В противном случае приложение инициатора должно начать диалоговый разговор между службой инициатора и целевой службой и отправить сообщение на эту беседу.
3. Сообщение размещено в таблице системы SYS.Transmission_Queue, и сервисный брокер начинает предпринимать попытки доставить сообщение в целевую службу.
4. Service Broker ищет соответствующий маршрут и удаленное привязку к обслуживанию и использует их для определения адреса, к которому можно подключиться, чтобы доставить сообщение.
5. Сервисный брокер открывает соединение с целью, аутентифицирует и доставляет сообщение для целевого сервисного брокера.
6. Целевой сервисный брокер пытается классифицировать сообщение и определить, какой локальный сервис будет обрабатывать сообщение (он использует данные маршрута в базе данных MSDB для этого).
7. Целевой сервисный брокер доставляет сообщение в очередь целевой службы
8. Как только сообщение будет успешно доставлено в целевую очередь, целевой брокер сервисов ищет информацию о маршруте обратно к инициатору и попытка предоставить подтверждение того, что сообщение было получено.
9. Сервисный брокер инициатора получает подтверждение и использует информацию о маршрутизации в MSDB, чтобы определить, для чего предназначена локальная служба.
10. После успешной маршрутизации подтверждения в службу инициации сообщение затем удаляется из таблицы системы sys.transmission_queue.
11. Если инициатор не получит подтверждение того, что сообщение было получено, оно будет периодически повторно передавать сообщение в цель. Если цель уже получила сообщение, она просто отбросит любые дополнительные возвраты доставки и отправит для них подтверждения.

Странное поведение:

Шаг 11 - это то, где я вижу очень странное поведение с сервисным брокером и Alwessonon. Я вижу, как сообщение доставляется в цель и успешно обрабатывается, и я также вижу, что подтверждение отправляется обратно в инициатор и полученное. Тем не менее, сообщение остается в sys.transmission_queue, как будто не было получено никакого подтверждения. Чтобы сделать вещи еще более странными, сервисный брокер не пытается отправить сообщение, как будто я ожидал, если подтверждение не будет получено. Вместо этого сообщение просто остается в sys.transmission_queue, и по мере того, как они отправляются, их доставляют, они доставляются, и они также остаются в sys.transmission_queue. Мне кажется, что сервисный брокер получает подтверждения и, следовательно, перестает пытаться доставить сообщение, но по какой -то причине не удаляет его из sys.transmission_queue. Cransmission_status для этих сообщений остается пустым, что должно указывать на то, что сервисный брокер еще не пытался их доставить.

Я проверил настройку удержания в очереди обслуживания, и он настроен на выключение, но это должно влиять только на очередь службы, а не на sys.transmission_queue. Я также проследил обе стороны разговора с помощью SQL Profiler, и я могу увидеть отправленное сообщение, и подтверждение отправлено обратно в инициатор и получение (см. Данные XML Trace в конце этого поста).

Одна странная вещь выпрыгнула на меня в следах. Я заметил, что обе стороны, казалось, были немного смущены подключениями TCP, потому что сообщения отправляются с IP -адреса самого узла, в то время как сервисные маршруты и сами сообщения указывают на имя/IP слушателя AG. Эта путаница, по -видимому, заставляет каждую сторону закрыть существующее соединение между двумя службами и создать новое, чтобы доставить сообщение или подтверждение. Я не уверен, что это нормально или нет, или это имеет какое -либо отношение к тому, почему признание не обрабатываются правильно, но это было единственное, что я мог видеть, которое могло бы объяснить странное поведение.

Призыв о помощи:

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

Данные трассировки:

Пожалуйста, смотрите мой пост в блоге (URL -адрес в начале вопроса).

Answer 1

За последние несколько месяцев я работал с командой поддержки продуктов Microsoft, и они признали две ошибки в SQL Server 2012 в отношении этой проблемы. Они будут выпускать исправления для этих ошибок в рамках следующего пакета обслуживания для SQL Server 2012.