SQL Server 的多数据中心设计

Question

我不是 DBA，也许我无法正确解释自己。我正在寻找一些关于如何以及我需要部署什么的新想法，以获得跨大洲可用的完整 SQL Server 数据库，例如在您的私有“云”上构建 SaaS。

假设您在 LATAM、EMEA、EAST 和 EEUU 有多个办事处。每个地区的每个办公室都有自己的带有本地数据库的 SQL Server，您已经厌倦了管理数百台服务器。

解决此问题的最简单方法是将所有小型数据库融合为一个大型数据库，并将其放入数据中心。作为第一种方法，我认为基于单个区域的单个数据中心足以满足我们的要求，但由于延迟，它不会。我的意思是一个地区的本地用户不能使用位于不同地区的数据库。

下一步是什么？简单的事情。在您想要的每个区域部署一个数据中心，每个数据库都将包含具有读/写和 HA 功能的相同信息。在这一点上，我猜带有 AlwaysOn 群集的 SQL Server 将满足 HA，但是读/写呢？我是否必须对每个数据库服务使用任何类型的副本？它会起作用吗？

更进一步，假设一个地区的一个国家需要拥有自己的数据库。如何为此设置复制？如果我必须更改数据库架构怎么办？

任何帮助或澄清将不胜感激。

---

我们的目标是设计一个基于通过 Citrix XenApp 发布的 .net WCF 的 3 层应用程序。由于某些要求，如果客户端因延迟（WCF 与本地设备一起工作）而尝试连接到远程数据中心（即拉丁美洲到欧盟），则此应用程序将无法工作。继续这部分，我们需要在每个大洲建立 2 个 DC，以提供具有适当容错和 HA 的可靠应用层。我们的主要问题是知道我们可以在数据层做什么......

我的第一个想法是在主数据中心部署一个 SQL AlwaysOn 集群作为中心节点，N SQL Std 从这个主节点双向复制。是的，我是双向说的，因为我工作中的一些人对这种情况完全有信心，但我仍然试图了解它在 SQL Server 中的工作方式（即使可能）。我对 MySQL 和 Galera 有更多的经验并且它可以工作，但是我的 SQL Server 知识有限。

我知道你会问我，为什么不直接从应用层连接到这个中央数据库？也许这是最好的选择，因为这个 SQL 服务不会非常详尽（每天 100.000 个事务），但我们必须确保服务和应用程序功能在 99,99999。

Answer 1

在这一点上，我猜带有 AlwaysOn 群集的 SQL Server 将满足 HA，但是读/写呢？

我认为此时您可以很好地阅读这份SQL Server 2012 白皮书，以了解 AlwaysOn 品牌名称下的两个不同功能（可用性组和故障转移群集实例）的可能性。

在您想要的每个区域部署一个数据中心，每个数据库都将包含具有读/写和 HA 功能的相同信息

您询问读/写功能，我认为这是您会感到失望的地方。即使将本地 FCI 与跨站点 AG 结合使用，也只能有一个节点作为 PRIMARY（可写）节点。其他节点可以充当只读节点，以允许您卸载读取和备份。

根据我构建此类系统的经验，您确实希望使事情尽可能简单。出于这个原因，我不建议尝试将 AlwaysOn FCI + AG 扩展到 2 个以上的站点。我也会远离双向跨国复制，因为这有打破的趋势。

如果没有更多信息，很难为您推荐解决方案。需要考虑的一些非常普遍的主题是；每个站点的应用程序中的缓存层，以帮助解决延迟或 SQL Server Azure 部署。

问题更新后：

我真的不建议您以这种方式使用 SQL Server。2 个节点之间的双向复制已经够糟糕的了。>2 个节点加上所有 SQL Server 企业版的成本听起来是个坏主意。也许看看 Azure 提供了什么。