Eoi*_*ell 10 sql sql-server azure geo-replication azure-sql-database
我只是在研究如何在Azure上构建一个大规模,全局可访问的应用程序.
那里已经有很多技术可以让你的应用程序尽可能贴近消费者.
我有点困惑的是数据库.如果您使用的是SQL Azure,则必须指定一个区域来放置它.如果我的SQL Azure实例位于西欧(阿姆斯特丹),但我的客户位于澳大利亚,并通过澳大利亚(NSW)的实例访问该应用程序,应用程序与数据库通信之间会有一些延迟.
我见过的有关Geo Replication的所有参考资料似乎都在主从冗余设置的上下文中.但是我想知道是否可以使用Master-Master设置,其中每个应用程序实例在同一个Geo-Region中与它自己的SQL Azure主实例进行对话,然后sql azure会处理它们之间的双向复制.
Active Geo-Replication功能实现了一种机制,可在同一Microsoft Azure区域或不同区域(地理冗余)中提供数据库冗余.Active Geo-Replication将提交的事务从数据库异步复制到不同服务器上的最多四个数据库副本.原始数据库成为连续副本的主数据库.每个连续副本称为活动辅助数据库.主数据库将提交的事务异步复制到每个活动的辅助数据库.在任何给定点,活动辅助数据可能稍微落后于主数据库,活动辅助数据保证始终与提交到主数据库的更改在事务上一致.Active Geo-Replication最多支持四个活动辅助服务器,或最多三个活动辅助服务器和一个脱机辅助服务器.
Active Geo-Replication的主要优点之一是它提供了数据库级灾难恢复解决方案.使用Active Geo-Replication,您可以在Premium服务层中配置用户数据库,以将事务复制到相同或不同区域内的不同Microsoft Azure SQL数据库服务器上的数据库.跨区域冗余使应用程序能够从自然灾害,灾难性人为错误或恶意行为导致的数据中心永久性丢失中恢复.
另一个主要好处是活动的辅助数据库是可读的.因此,活动辅助节点可以充当读取工作负载(如报告)的负载平衡器.虽然您可以在其他区域中创建活动辅助节点以进行灾难恢复,但您也可以在其他服务器上的同一区域中拥有活动辅助节点.两个活动的辅助数据库都可用于平衡为多个区域分布的客户端提供的只读工作负载.
请注意,没有提到master-master.副本是可读的,永远不可写.所以这个问题真的没什么问题,因为SQL Azure根本不支持你想要的东西.
另一种方法是应用程序层分片,并让每个租户连接到一个邻近数据库,但这假设数据是不相交的(澳大利亚客户不看南美项目).在这里看到这个答案.
你也可以研究像Cassandra这样的东西,它确实支持你想要的东西但是是一个主要的范例转换,你需要托管它并管理它.
但您还必须要问:是否需要master-master DB才能实现低延迟？写入是否经常发生在您的应用中？可以轻松改善读取延迟,这就是您拥有缓存和CDN的原因.想想所有阅读这个问题的澳大利亚用户.从地理复制数据库提供灾难恢复服务,而不是来自主 - 主数据库.请参阅StackOverflow如何扩展SQL Server.