sql-server - 用于流量管理器故障转移的 Sql Azure 数据库镜像

Question

我的目标是实现 Azure 流量管理器来对我们的网站及其数据库进行故障转移。

为了实现这一目标，我在不同的数据中心部署了两个相同的 Sql Azure 数据库。

该数据库包含 450 个表、4000 个列、约 800 万条记录、大小为 3GB，并且写入频繁。

1. Sql Data Sync 是实现镜像或 Sql Azure 术语中的双向同步的可行选项吗？

除了效率和成本之外，无论是双向还是单向，我首先关心的是设置 Sql Data Sync 所需的时间、架构演变时的维护开销以及同步失败时调试复杂架构的时间。还有一个 Sql Data Sync 仍处于预览状态的附加问题。

也许单向异地复制是更好的选择，并且在故障转移时，可以手动恢复要同步的原始数据库 - 我想知道数据库管理员通常会采取这样的做法吗？

我在这里担心的是偏离流量管理器管理的全自动故障转移解决方案。

Answer 1

我得出的结论是，Sql Data Sync 并不适合我的 MAWS 和 Sql Azure 故障转移策略。

Azure SQL 数据库的主动异地复制被证明是更好的选择。

以下是我针对 Sql Data Sync 考虑的一些要点。

1. 我的数据库有 450 个表和超过 800 万条记录，足够大，足以带来额外的复杂性和成本设置、执行和维护双向或单向 Sql 数据同步。

2. Sql Data Sync 的设计似乎并没有太强烈地围绕大型数据库的跨数据中心镜像的理念。有限制，例如每个 Azure 同步组有 100 个表。

3. 为我的数据库正确设置 Sql Data Sync 需要时间 因为它涉及将 450 张 table 分布在多个较小且 可管理的同步组，具有经过精心调整的同步频率和每个同步组 经过测试以确保同步发生而不会发生冲突。一个深 需要对数据库进行分析，以便对正确的表进行分组 一起避免目标数据库中的外键冲突:

   http://www.mssqltips.com/sqlservertip/3062/understanding-sql-data-sync-for-sql-server/

4. 看来 Sql Data Sync 不是事务同步模型:

SQL Azure failover / backup strategy for web app

SQL Data Sync 预览版已经有 2 年多了，最后一次更新是 2012 年 12 月

Sql Data Sync 在处理大型架构时存在固有问题。这是我在数据库模式中亲身经历的。

http://social.msdn.microsoft.com/forums/azure/en-US/9c679a74-9a7c-48e7-b4c9-95f6f7cfafd9/sql-azure-data-sync-refresh-schema-not-working

强调第一点，跨数据中心的双向复制很棘手，如果没有对数据和数据库架构的直观了解，通常不建议这样做。最终可能会创建同步循环。

最佳实践指出:仅在同步组中包含根据您的业务需求所需的表；包含不必要的表可能会影响总体成本以及同步效率。

http://www.mssqltips.com/sqlservertip/3062/understanding-sql-data-sync-for-sql-server/

Sql Data Sync 在表上加倍，创建了一个更大的架构，添加到我的 450 个表中。

关于使用Azure SQL 数据库的主动异地复制，在故障转移时，只需终止主动辅助数据库上的连续复制关系，使其变为读写关系。

来自http://msdn.microsoft.com/en-us/library/azure/dn741331.aspx

In the case of a widespread failure in the primary region, you might need to fail over your application to a secondary region. First, force terminate the continuous copy relationship on the active secondary. After the termination, replication will stop and all transactions that were not yet replicated from the primary database will never be copied to the active secondary. The former active secondary will become a standalone database. At this point, the application can failover to the former active secondary and resume its function. If the primary database was set to read-write, after termination, the active secondary is also set to read-write.

就我的数据库 SLA 而言，我涵盖了以下场景

1. 从意外数据损坏或删除中恢复:Sql Azure Premium 提供开箱即用的免费自动时间点还原，因此无需设置夜间备份到 Blob 存储。 http://azure.microsoft.com/blog/2014/10/01/azure-sql-database-point-in-time-restore/

2. 监控法规遵从性、了解数据库事件并洞察差异和异常:Sql Azure 提供多方面的数据库审核 http://azure.microsoft.com/en-us/documentation/articles/sql-database-auditing-get-started/

3. 跨区域冗余，用于从自然灾害、灾难性人为错误或恶意行为造成的数据中心永久丢失中恢复:Sql Azure 提供主动异地复制 http://msdn.microsoft.com/en-us/library/azure/dn741339.aspx