我的目标是实现Azure Traffic Manager以便我们的网站及其数据库进行故障转移.
为实现这一目标,我在不同的数据中心部署了两个相同的Sql Azure数据库.
该数据库展示了450个表,4000列,约800万条记录,3GB大小并经常写入.
我最初的关注除了效率和成本之外,无论是双向还是单向,都是设置Sql Data Sync所需的时间,架构发展时的维护开销以及同步失败时调试复杂架构.还有一个问题是Sql Data Sync仍处于预览状态.
我关注的是脱离了由Traffic Manager管理的全自动故障转移解决方案.
pur*_*uri 11
我已经得出结论,对于我的MAWS和Sql Azure故障转移策略,Sql Data Sync并不理想.
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 Data Sync已预览了2年多,最后一次更新是2012年12月
Sql Data Sync具有应对大型模式的固有问题.这是我的数据库架构的第一手经验.
强调第一点,跨数据中心的双向复制是棘手的,一般不推荐在没有数据和数据库模式的直觉知识的情况下.最终可能会创建同步循环.
最佳实践规定:仅在同步组中包含根据您的业务需求所需的表格; 包括不必要的表可能会影响总体成本以及同步效率.
http://www.mssqltips.com/sqlservertip/3062/understanding-sql-data-sync-for-sql-server/
关于在Azure SQL数据库中使用Active Geo-Replication,在故障转移时,只需终止活动辅助节点上的连续复制关系,使其成为读写.
来自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
| 归档时间： |
|
| 查看次数： |
2044 次 |
| 最近记录： |