1
votes

I have an application that, for performance reasons, will have completely independent standalone instances in several Azure data centers. The stack of Azure IaaS and PaaS components at each data center will be exactly the same. Primarily, there will be a front end application and a database.

So let's say I have the application hosted in 4 data centers. I would like to have the data coming into each Azure SQL database replicate it's data asynchronously to all of the other 3 databases, in an eventually consistent manner. Each of these databases needs to be updatable.

Does anyone know if Active Geo-Replication can handle this scenario? I know I can do this using a VM and IaaS, but would prefer to use SQL Azure.

Thanks...

1
Active Geo-Replication will only allow you to have one primary writable database with many one to many readable secondaries. If I am to understand your scenario correctly, you are looking for multiple writable databases that can be replicated to asynchronously. That scenario is not supported with Active Geo-Replication. You can learn more about Active Geo-Replication here.elfisher
You may want to user ServiceBus + SQL Azure to replicate the stuff by wrapping over the update as a message. The other possible options are by enabling change tracking / trigger with copy table on the azure databases and a machine in IaaS to read those and replicate using linked server feature.Sirisha Chamarthi

1 Answers

1
votes

Peer-to-peer tranasaction replication supports what you're asking for, to some extent - I'm assuming that's what you're referring to when you mention setting it up in IaaS, but it seems like it would be self defeating if you're looking to it for a boost in write performance (and against their recommendations):

From https://msdn.microsoft.com/en-us/library/ms151196.aspx

Although peer-to-peer replication enables scaling out of read operations, write performance for the topology is like that for a single node. This is because ultimately all inserts, updates, and deletes are propagated to all nodes. Replication recognizes when a change has been applied to a given node and prevents changes from cycling through the nodes more than one time. We strongly recommend that write operations for each row be performed at only node, for the following reasons:

  • If a row is modified at more than one node, it can cause a conflict or even a lost update when the row is propagated to other nodes.
  • There is always some latency involved when changes are replicated. For applications that require the latest change to be seen immediately, dynamically load balancing the application across multiple nodes can be problematic.

This makes me think that you'd be better off using Active Geo Replication - you get the benefit of PaaS and not having to manage your own VMs, not having to manage TR, which gets messy, and if the application is built to deal with "eventual consistency" in the UI, you might be able to get away with slight delays in the secondaries being up to date.