具有负载均衡和冗余的RavenDb拓扑结构

Question

我们正在尝试推出适当的RavenDb拓扑结构，以便我们平衡负载并实现容错。 似乎更好的负载平衡方法是使用本地分片，我们可能会转而使用它，但由于领域的特殊性，在这一点上它不是微不足道的。 为了具有冗余性，我们只需在每个组中设置2个ravendb节点，并在两者之间进行主/副本复制，因此如果发生故障，RavenDb客户端将自动切换到另一个节点。 我们有索引“组件”，这是唯一一个将写入数据库的组件，因此它将写入一个节点，并且我们预计这些更改最终会分发。我们将在两组ravendb节点之间设置主/主复制，因此如果索引组件最终会回退到组1，则应该将更改复制到第二组。

The schema

因此，似乎有其矛盾，因为我们只有一个球员谁（在一分钟内与束，一次）写入数据库的低风险。

1. 它是典型的RavenDb有这么多的主/从 复制：关于这个设置的几个问题？
2. 这个问题可以用更简单的方式解决吗？
3. 如何配置客户端的回退约定，这样每个Web节点将首先在其组中的另一个节点失败后再失败 另一个组的RavenDb节点？
4. 如果我们为每个网络节点上的读取嵌入简单的循环赛逻辑（Web节点1将从 读取：RavenDb1_01和RavenDb1_02），您是否看到任何潜在问题？它会使标准RavenDb 后备行为变得疯狂吗？

Answer 1

1）在这样的群集中有很多节点是很常见的，是的。请注意，您需要设置复制以便在此类拓扑中进行更改和复制。

2）它是通常更容易有一个完全连接的拓扑结构，而不是层层你在这里..

3）故障转移总是基于目的地的客户端的主节点顺序。换句话说，如果节点2具有目的地（节点1，节点3）并且节点1具有目的地（节点3，节点2）。 最初连接到节点2的客户端将在故障转移时转到节点1，然后转到节点3 ，并且最初连接到节点1的客户端将转到节点3，然后在故障转移时转到2。

4）循环和故障转移分开进行。