服务总线灾难交换异常类型以及如何进行钻取 [英] Service Bus Disaster swap exception type and how to do a drill

问题描述

你好

我们正在将灾难恢复集成到基于服务总线的解决方案中.遵循此仓库中实现的主动-被动模式: https://github.com/Azure/azure-service-bus/blob/master/samples/DotNet/Microsoft.ServiceBus.Messaging/GeoReplication/SenderPassiveReplication/Program.cs#L59

We are integrating disaster recovery to our solution based on service bus. Following the Active-Passive pattern as implemented in this repo: https://github.com/Azure/azure-service-bus/blob/master/samples/DotNet/Microsoft.ServiceBus.Messaging/GeoReplication/SenderPassiveReplication/Program.cs#L59

我们的问题是，执行交换的条件应该是哪种类型的异常?

Our question is, what type of exception should be the condition to perform the swap?

有没有一种方法可以模拟中断来测试解决方案?

Is there a way that we can simulate the outage to test the solution?

谢谢.

Jaroslav

推荐答案

虽然您所指的模式是有效的，但您可能还需要检查

While the pattern you are referring to is valid, you might also want to check this updated doc which explains how you may setup a namespace alias in front of your primary and secondary namespaces. This removes the need to managing multiple clients and connection strings.

此外， Service Bus的可用区域具有 普遍可用，进一步简化了事情.

Also, Availability Zones for Service Bus has recently been made Generally Available further simplifying things.

---

话虽如此，您可能要检查记录在 这里.听起来像是服务器问题的任何异常都应该由我来解决-超时，MessagingCommunication和MessagingEntityNotFound.

That being said, you might want to check the list of exceptions documented here. Any exception which sounds like a server problem should do I suppose - Timeout, MessagingCommunication & MessagingEntityNotFound.

对于模拟，我相信您可以尝试阻止对名称空间之一的请求，并查看它是否按预期进行故障转移.

As for the simulation, I believe you could just try to block requests to one of the namespace and see if it fail overs as expected.

这篇关于服务总线灾难交换异常类型以及如何进行钻取的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！