用于灾难恢复的镜像与 HA 数据复制

我正在研究 ActiveMQ Artemis 中的选项，以便在我们丢失整个数据中心时进行数据恢复。我们有两个数据中心，一个在东海岸，一个在西海岸。

从文档和论坛中，我找到了四个选项：

基于磁盘的方法：

基于块的站点间数据目录复制，在一个站点上运行 Artemis（使用 Ciphy 或 DRBD 和协议 A）。如果发生灾难（或故障转移测试），请在死站点上停止 Artemis，然后在活动站点上启动它。
同样的事情，但两个 Artemis 服务器都处于活动状态，使用 ha-policy 来指示使用 shared store 的主服务器和从服务器。

网络复制：

我们的 IT 团队使用/熟悉用于其他服务的 MySQL 复制、NFS 和 rsync。我们目前正在使用通过 MySQL 复制的 JBoss 4 服务器处理 JMS。

我阅读文档后的反应是高可用性数据复制是可行的方法，但是否存在我没有看到的权衡。唯一提到DR和跨站点的是镜像代理连接，但从表面上看，它似乎是一个更难管理的版本？

我们的限制是我们需要实时集群的高性能（大约每秒 10 万条消息，全部很小）我们可以承受在紧急故障转移中丢失消息（最好尽可能少）。我们不应在受控故障转移中丢失消息。

我们不希望站点 A 中的客户端连接到站点 B 中的 Artemis - 我们将在发生故障转移时启用站点 B 上的客户端。

首先要注意的是，通过 ha-policy 配置的高可用性功能（共享存储和复制 - 选项 #2 和 #3）旨在用于本地具有高速、低延迟网络连接的数据中心。它不是为灾难恢复而设计的。

基于网络的数据复制的特别问题是复制是同步，这意味着它很有可能会对性能产生负面影响，因为每个持久消息都必须在全国范围内发送从一个数据中心到另一个数据中心。此外，如果复制代理失败，客户端将自动故障转移到另一个数据中心的备份。

使用基于块存储的解决方案（例如 Ceph 或 DRDB）是可行的，但它实际上是不受 ActiveMQ Artemis 控制的独立事物。

mirror broker connection 的设计考虑了灾难恢复用例。它是异步，因此它几乎不会对复制的性能产生影响，并且如果镜像代理失败，客户端将不会自动故障转移到镜像。