有趣的是，有没有解决方案可以拥有两台物理机器，Microsoft SQL Server 2012 在同一数据库上工作。 像集群这样的东西只是与 bothe 节点处于活动状态...知道吗？
Microsoft SQL Server不支持开箱即用的"真正的"负载平衡方案。AFAIK，这在SQL Server 2012中仍然适用。（如果我错了，有人会开导我。无论我们谈论的是数据库镜像还是 AlwaysOn 还是集群，这都没有关系。
（为了强调这一点，MS最近似乎将SQL Server集群称为"SQL Server故障转移集群"。迂腐学。
如果要对数据库进行负载平衡，则必须自己完成某种分片，联合或复制的艰苦工作。（请注意，联合（按视图）自 SQL Server 2000 以来一直在产品中，只是不是很受欢迎。当然，这意味着修改您的数据库或应用程序本身，这几乎总是工作量太大或违反您的供应商协议。有了 150 个数据库，就更加难以逾越了。
您可以拥有一个主动-主动集群，但问题是您必须小心地将数据库分布在节点上以分配负载。对于 150 个数据库，这可能比只有 5 个数据库更精细，但如果有一个数据库负载很大，而 149 个数据库是轻量级或很少使用的，您可能仍然会发现一台机器陷入困境，而另一台则没有。而且，一些数据库有时很忙，而在其他时间几乎不忙。这意味着当用户决定运行一些繁重的进程时，一切都可能归结为。
当然，无论出于何种原因，在故障转移时，您必须能够在单个节点上支持所有这些负载，即使它是像修补 Windows 这样平凡的事情。如果您只在已知的慢流量时段进行修补，那就太好了。如果您没有慢周期，或者如果故障转移是因为硬件实际出现故障而发生的，则其他节点可能不会承担负载，并且您的用户将不走运。如果你这样想，让第二台机器"什么都不做"并不是那么令人恼火。至少您知道它将占用主数据库通常执行的所有流量。
是的，您可以两个数据库主动共享相同的信息并来回复制它。这称为"合并复制"。在此配置中，两个节点都可以接受读取和写入事务。
合并复制的工作原理