用于异地复制的 SQL Server 复制

Question

我们内部拥有主 SQL Server（目前有 15 个主服务器（总共约 500 个数据库），大多数服务器具有十六进制核心处理器）。

这些被镜像到附近建筑物中的其他备份服务器（通过专用的 0ms 光纤链路）。

我们想要做的是在数英里外的异地数据中心维护我们数据的实时副本（作为更大的 DR 项目的一部分 - 即如果我们所在地区存在通信问题）。

目前我们使用 SQL Server 2008 R2 - 标准版。

显然，使用 SQL Server 2008 R2 的“标准版”将我们限制为同步镜像，因为异步是“企业版”功能。

我们已经完成了异地同步镜像的测试，但延迟使它成为不可能。

我很想升级到 SQL Server 2012 Enterprise 并实施 AlwaysOn 可用性组，但该公司不愿意花费 100,000 英镑以上来升级 SQL 许可（2012 年的每核许可 + 我们的六核处理器 = 史诗般的失败）-他们甚至不愿意花钱升级到 2008 Enterprise，所以这也是窗口之外的异步镜像。

因此，由于这些财务限制，我的手被束缚在 2008 R2 标准版上。

留给我的唯一选择是日志传送和复制（如果我遗漏了什么，请纠正我）——日志传送很粗糙——但是如果管理得当是可行的——所以我们现在把它放在次要位置。

我的问题：

1. SQL Server 2008 R2 Standard 是否具有我们进行异地复制所需的所有复制功能？
2. 在不以任何方式影响主服务器性能的情况下，将内部服务器复制到异地数据中心（20-30 毫秒延迟）是否可行（我们是否可以在“原则”服务器上设置复制分发服务器）？
3. 鉴于复制不是实例级复制解决方案 - 这是否会超过 1 个 DBA 可以处理的管理？（鉴于我已经在管理 15 台 Principle 服务器及其镜像服务器 - 诚然有很多自动化）
4. 是否可以在不影响现有镜像配置的情况下从我们的主复制 - 我的理解是最佳实践是镜像订阅服务器而不是发布服务器 - 这是正确的吗？
5. 复制处女忘记了还有什么需要引起我注意的吗？

Answer 1

根据您所描述的内容，日志传送将是要走的路。原木运输是老派，久经考验。

复制非常脆弱，为失败提供了大量空间，尤其是在添加新表并将这些表放入复制拓扑时。

至于 2012 年的升级成本，它们可能没有你想象的那么糟糕。如果您有软件保证和企业协议，这将为您节省大量的许可费用。