Azure Service Bus Premium - Geo-Recovery - удаленные сообщения

У меня есть пространство имен служебной шины Premium в одном регионе, и я создал еще одно в другом регионе в качестве дополнительного. Я включил геовосстановление на первичном и настроил сопряжение с вторичным. Я запустил тест, чтобы постоянно отправлять сообщения в тему, и у меня есть принимающее приложение, на которое подписано. Отправитель отправит «Отправляющее сообщение: Сообщение {номер в последовательности}», а получатель отобразит «Полученное сообщение: SequenceNumber: {назначенный SB порядковый номер} Тело: Сообщение {номер в последовательности}». Однако, когда я попытался инициировать переключение на вторичный через портал, я заметил, что, хотя отправитель продолжал отправлять сообщения, получатель сбросил некоторые сообщения при завершении аварийного переключения. См. Ниже:

Журналы от отправителя:

Sending message: Message 244
Sending message: Message 245
Sending message: Message 246
Sending message: Message 247
Sending message: Message 248
Sending message: Message 249
Sending message: Message 250
Sending message: Message 251
Sending message: Message 252
Sending message: Message 253
Sending message: Message 254
Sending message: Message 255
Sending message: Message 256
Sending message: Message 257
Sending message: Message 258
Sending message: Message 259
Sending message: Message 260

Журналы от получателя:

Received message: SequenceNumber:255 Body:Message 244
Received message: SequenceNumber:256 Body:Message 245
Received message: SequenceNumber:257 Body:Message 246
Received message: SequenceNumber:258 Body:Message 247
Message handler encountered an exception Microsoft.Azure.ServiceBus.UnauthorizedException: Connection rejected after GeoDRFailOver. TrackingId:7bb0b78d-2bf5-4807-8bcb-c831b00c6692, SystemTracker:AmqpGatewayProvider, Timestamp:2019-08-12T17:42:38
   at Microsoft.Azure.ServiceBus.Core.MessageReceiver.<OnReceiveAsync>d__86.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.Azure.ServiceBus.Core.MessageReceiver.<>c__DisplayClass64_0.<<ReceiveAsync>b__0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.Azure.ServiceBus.RetryPolicy.<RunOperation>d__19.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at Microsoft.Azure.ServiceBus.RetryPolicy.<RunOperation>d__19.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.Azure.ServiceBus.Core.MessageReceiver.<ReceiveAsync>d__64.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.Azure.ServiceBus.Core.MessageReceiver.<ReceiveAsync>d__62.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.Azure.ServiceBus.MessageReceivePump.<MessagePumpTaskAsync>d__11.MoveNext().
Exception context for troubleshooting:
- Endpoint: rjpremium.servicebus.windows.net
- Entity Path: topic1/Subscriptions/sub1
- Executing Action: Receive
Received message: SequenceNumber:1 Body:Message 254
Received message: SequenceNumber:2 Body:Message 255
Received message: SequenceNumber:3 Body:Message 256
Received message: SequenceNumber:4 Body:Message 257
Received message: SequenceNumber:5 Body:Message 258
Received message: SequenceNumber:6 Body:Message 259
Received message: SequenceNumber:7 Body:Message 260

Сообщения между 247 и 254 отбрасываются. Хотя отправитель отправил все эти сообщения, получатель так и не получил этих сообщений. Если я включу Geo-Recovery, получатель также должен получать эти сообщения?


azure azureservicebus azure-servicebus-queues
person Thomas    schedule 12.08.2019    source источник
comment
При объединении вторичного пространства имен обновляли ли вы отправитель / получатель, чтобы использовать псевдоним, полученный после объединения пространств имен?   -  person Sean Feldman    schedule 12.08.2019

Ответы (2)


arrow_upward
1
arrow_downward

При использовании функции геоаварийного восстановления служебной шины Azure (Premium) сначала необходимо связать основное и дополнительное пространства имен. Когда это будет сделано, вы получите псевдоним, который будет использоваться с этого момента и далее. Псевдоним гарантирует, что приложения, подключенные к основному пространству имен, продолжат функционировать при отработке отказа. Убедитесь, что вы используете выданный псевдоним в приложениях отправителя и получателя. Подробнее см. В документации .

person Sean Feldman    schedule 12.08.2019
comment
да. Я использовал псевдоним для отправки и получения сообщений. - person Thomas; 12.08.2019
comment
И при повторном подключении к пространству имен с переключением при отказе это работает или вы получаете исключение? - person Sean Feldman; 12.08.2019
comment
Отправитель вообще не получал исключения ни разу во время отработки отказа. Однако получатель зарегистрировал исключения. И отправитель, и получатель являются приложениями Windows на C #. - person Thomas; 12.08.2019
comment
Я имею в виду, что если вы повторно подключаетесь к получателю, он работает или по-прежнему генерирует исключение при попытке получить сообщения? - person Sean Feldman; 12.08.2019
comment
Я не пробовал, но похоже, что это должно сработать. Я предполагаю это, потому что в моем тесте получатель был постоянно подключен путем регистрации обработчика сообщений (subscriptionClient.RegisterMessageHandler). Было отброшено всего 7 сообщений, что означает, что соединение будет восстановлено после нескольких секунд простоя. - person Thomas; 12.08.2019
comment
Geo-DR предназначен только для метаданных, а не для плана данных. Таким образом, вероятно, что отброшенные семь сообщений - это те, которые были отправлены во время переключения. Было бы лучше, если бы брокер выдал исключение, отличное от UnauthorizedException, чтобы указать, что выполняется аварийное переключение. Вы пытались проверить связь с командой обслуживания, чтобы убедиться, что это ожидаемое поведение или нет? ? - person Sean Feldman; 12.08.2019
comment
Я попробую это. Спасибо, что предложили это. - person Thomas; 12.08.2019

arrow_upward
1
arrow_downward

Во-первых, цитата из docs (и, как параллельно указывает Шон Фельдман)

«Geo-Disaster recovery в настоящее время гарантирует только то, что метаданные (очереди, темы, подписки, фильтры) копируются из основного пространства имен во вспомогательное пространство имен при объединении в пару».

Это означает, что сообщения (пока) не копируются.

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

person Clemens Vasters    schedule 14.08.2019