我的目标是实现Azure Traffic Manager以便我们的网站及其数据库进行故障转移 .
为实现这一目标，我在不同的数据中心部署了两个相同的Sql Azure数据库 .
该数据库展示了450个表，4000列，约800万条记录，3GB大小并经常写入 .
- Sql Data Sync是实现镜像的可行选项还是在Sql Azure术语中，它们之间的双向同步？
我最初的关注除了效率和成本之外，无论是双向还是单向，都是设置Sql Data Sync所需的时间，架构发展时的维护开销以及同步失败时调试复杂架构 . 还有一个问题是Sql Data Sync仍处于预览状态 .
- 也许单向地理复制是更好的选择，在故障转移时，人们会手动恢复原始数据库以进行同步 - 我想知道这样的行动方案是否通常是数据库管理员的后续行动？
我关注的是脱离了由Traffic Manager管理的全自动故障转移解决方案 .
1 回答
我得出结论 Sql Data Sync 不适合我的MAWS和Sql Azure故障转移策略 .
Active Geo-Replication for Azure SQL Database 证明了更好的选择 .
以下是我对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 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/
关于使用 Active Geo-Replication for Azure SQL Database ，在故障转移时，只需终止活动辅助节点上的连续复制关系，使其成为读写 .
来自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提供Active Geo-Replication http://msdn.microsoft.com/en-us/library/azure/dn741339.aspx