我的目标是实现Azure流量管理器，以便对我们的网站及其数据库进行故障转移。
为实现这一目标，我在不同的数据中心部署了两个相同的Sql Azure数据库。
该数据库展示了450个表，4000列，约800万条记录，3GB大小并经常写入。
除了效率和成本之外我最初的关注点，无论是双向还是单向，都是设置Sql Data Sync所需的时间，架构发展时的维护开销以及同步失败时调试复杂架构。还有一个问题是Sql Data Sync仍处于预览状态。
我担心的是脱离了由Traffic Manager管理的全自动故障转移解决方案。
答案 0 :(得分：11)
我已经得出结论 Sql Data Sync 不适合我的MAWS和Sql Azure故障转移策略。
Azure SQL数据库的活动地理复制证明了更好的选择。
以下是我对Sql Data Sync考虑的一些观点。
有450个表和超过800万条记录，我的数据库足够大，可以带来额外的复杂性和成本设置，执行和维护双向或单向Sql数据同步。
对于大型数据库的跨数据中心镜像的想法，Sql Data Sync似乎没有设计得太强。有限制，例如每个Azure Sync Group有100个表。
为我的数据库正确设置Sql Data Sync需要时间 因为它涉及将450个表分布在多个较小的和 可管理的同步组，具有良好调整的同步频率和每个 测试以确保同步发生而没有冲突。一个深刻的 需要对数据库进行分析，以便对正确的表进行分组 一起避免目标数据库中的外键冲突：
http://www.mssqltips.com/sqlservertip/3062/understanding-sql-data-sync-for-sql-server/
Sql Data Sync似乎不是事务同步模型：
SQL Azure failover / backup strategy for web app
SQL Data Sync已预览超过2年，上次更新时间为2012年12月
Sql Data Sync在处理大型架构时存在固有问题。这是我的数据库架构的第一手经验。
强调第一点，跨数据中心的双向复制非常棘手，如果不了解数据和数据库架构，通常不建议这样做。最终可能会创建同步循环。
最佳做法指出：仅在同步组中包含根据您的业务需求所需的表格;包括不必要的表可能会影响整体成本以及同步效率。
http://www.mssqltips.com/sqlservertip/3062/understanding-sql-data-sync-for-sql-server/
关于使用 Azure SQL数据库的活动地理复制，在故障转移时，只需终止活动辅助服务器上的连续复制关系，使其成为读写。
来自http://msdn.microsoft.com/en-us/library/azure/dn741331.aspx
如果主要区域出现广泛故障，您可能需要将应用程序故障转移到辅助区域。首先，强制终止活动辅助节点上的连续复制关系。终止后，复制将停止，并且尚未从主数据库复制的所有事务将永远不会复制到活动的辅助节点。以前的活动辅助将成为独立的数据库。此时，应用程序可以故障转移到以前的活动辅助节点并恢复其功能。如果主数据库设置为读写，则在终止后，活动的辅助数据库也设置为读写。
就我的数据库SLA而言，我有以下方案
从意外数据损坏或删除中恢复：Sql Azure Premium提供开箱即用的免费和自动时间点恢复，因此无需将夜间备份设置为blob存储。 http://azure.microsoft.com/blog/2014/10/01/azure-sql-database-point-in-time-restore/
监控合规性，了解数据库活动以及对差异和异常的洞察：Sql Azure提供了许多方面的数据库审计 http://azure.microsoft.com/en-us/documentation/articles/sql-database-auditing-get-started/
从自然灾害，灾难性人为错误或恶意行为导致的数据中心永久性丢失中恢复的跨区域冗余：Sql Azure提供活动地理复制http://msdn.microsoft.com/en-us/library/azure/dn741339.aspx