Hi Team,

I am little confused. in azure we pay for traffic inbound and outbound public & within Azure. So, Suppose we deploy Azure Website and for the High Availability we deploy that in multiple region. we use traffic manager to create a unique link (with performance based routing rule in traffic manager)

Based on this configuration front-end azure website will serve the request based on the shortest nearest data centre it deployed. But If we have SQL Azure in connection & that may be far away from that then?

Take an example. I have

Azure Website deployed at: East US, West US & Southest Asia.

SQL Azure deployed at: East US (Geo-Replication may be at Southest Asia Read only)

So, My Questions:

1) when request come from Southest Asia, Southest Asia Datacentre will serve that request but for SQL transaction, it will travel to East US Datacentre correct?

because Geo-Replication will work only in case of failover till that primary data server will only be the point of contact.

2) if we deploy SQL Azure on multiple region with SQL Sync Group option, is it only possible solution? (which still have many issues see here...  ) If we have changes in new deployment along with some sql script, will this sync works real time?

http://azure.microsoft.com/blog/2014/07/12/spotlight-on-sql-database-active-geo-replication/

this link can help.

Hi Horochan,

I read that article. But that is about Geo-Replication for Failover scenario. Not about HA much. sure there is some point about that but not those on which, I have questions.

see, My question here is If our Azure Website is located to East US, obviously our SQL Azure we will create in the same region (with same affinity group) in East US.

But because of HA of Azure Website, we create MAWS (Microsoft Azure Websites) in multiple region & through Traffic Manager we expose one single unique URL.

But related to that we should have SQL Azure deployed on respected region correct? otherwise we might have MAWS deployed on East US, West US but our Database might be only at East US.

So, when West US People will request the site, front end will response from East, but for Database it will travel to West.

Moreover Geo-Replication will work only in case of Failover. Here my concern about Happy Condition.

I don't think what you are trying to achieve is currently available in any automated fashion, ie you would need to replicate the data between the two regions databases manually.

Active Geo-Replication is about 80% of the way to solving this, I wish they would take it to 100%.

Hi Brij,

If your website mostly does read queries against the database, you can look into a setup with Active Geo-Replication which allows up to 4 readable secondary databases. This is supported in out Premium service tiers. Write operations would still have to go against the single primary database. Writeable secondaries are not supported.

Again in the case with a lot of reads you can reduce the round-tips to the DB using a cache layer that is collocated with the web-server and hence reduce page loading times.

If your application requires a lot of write, you could explore the option of sharding based on customer location and position the shards in the regions. This however is a more difficult approach. 

Lastly, if you are mainly looking into a scenario US West vs US East have you looked into what the experience actually is with a single database? The latencies might be acceptable and you can again look into a caching to reduce roundtrips.

Hi Brij,

If your website mostly does read queries against the database, you can look into a setup with Active Geo-Replication which allows up to 4 readable secondary databases. This is supported in out Premium service tiers. Write operations would still have to go against the single primary database. Writeable secondaries are not supported.

Again in the case with a lot of reads you can reduce the round-tips to the DB using a cache layer that is collocated with the web-server and hence reduce page loading times.

If your application requires a lot of write, you could explore the option of sharding based on customer location and position the shards in the regions. This however is a more difficult approach. 

Lastly, if you are mainly looking into a scenario US West vs US East have you looked into what the experience actually is with a single database? The latencies might be acceptable and you can again look into a caching to reduce roundtrips.

• Proposed as answer by pehkeongteh 15 hours 8 minutes ago

Hi Brij,

If your website mostly does read queries against the database, you can look into a setup with Active Geo-Replication which allows up to 4 readable secondary databases. This is supported in out Premium service tiers. Write operations would still have to go against the single primary database. Writeable secondaries are not supported.

Again in the case with a lot of reads you can reduce the round-tips to the DB using a cache layer that is collocated with the web-server and hence reduce page loading times.

If your application requires a lot of write, you could explore the option of sharding based on customer location and position the shards in the regions. This however is a more difficult approach. 

Lastly, if you are mainly looking into a scenario US West vs US East have you looked into what the experience actually is with a single database? The latencies might be acceptable and you can again look into a caching to reduce roundtrips.

• Proposed as answer by pehkeongteh Friday, March 13, 2015 3:58 PM

Hi Brij,

If your website mostly does read queries against the database, you can look into a setup with Active Geo-Replication which allows up to 4 readable secondary databases. This is supported in out Premium service tiers. Write operations would still have to go against the single primary database. Writeable secondaries are not supported.

Again in the case with a lot of reads you can reduce the round-tips to the DB using a cache layer that is collocated with the web-server and hence reduce page loading times.

If your application requires a lot of write, you could explore the option of sharding based on customer location and position the shards in the regions. This however is a more difficult approach. 

Lastly, if you are mainly looking into a scenario US West vs US East have you looked into what the experience actually is with a single database? The latencies might be acceptable and you can again look into a caching to reduce roundtrips.

• Proposed as answer by pehkeongteh Friday, March 13, 2015 3:58 PM
• Marked as answer by Brij Shah 2 hours 15 minutes ago

Hi Brij,

If your website mostly does read queries against the database, you can look into a setup with Active Geo-Replication which allows up to 4 readable secondary databases. This is supported in out Premium service tiers. Write operations would still have to go against the single primary database. Writeable secondaries are not supported.

Again in the case with a lot of reads you can reduce the round-tips to the DB using a cache layer that is collocated with the web-server and hence reduce page loading times.

If your application requires a lot of write, you could explore the option of sharding based on customer location and position the shards in the regions. This however is a more difficult approach. 

Lastly, if you are mainly looking into a scenario US West vs US East have you looked into what the experience actually is with a single database? The latencies might be acceptable and you can again look into a caching to reduce roundtrips.

• Proposed as answer by pehkeongteh Friday, March 13, 2015 3:58 PM
• Marked as answer by Brij Shah Monday, March 16, 2015 4:50 AM

Hi Brij,

If your website mostly does read queries against the database, you can look into a setup with Active Geo-Replication which allows up to 4 readable secondary databases. This is supported in out Premium service tiers. Write operations would still have to go against the single primary database. Writeable secondaries are not supported.

Again in the case with a lot of reads you can reduce the round-tips to the DB using a cache layer that is collocated with the web-server and hence reduce page loading times.

If your application requires a lot of write, you could explore the option of sharding based on customer location and position the shards in the regions. This however is a more difficult approach. 

Lastly, if you are mainly looking into a scenario US West vs US East have you looked into what the experience actually is with a single database? The latencies might be acceptable and you can again look into a caching to reduce roundtrips.

• Proposed as answer by pehkeongteh Friday, March 13, 2015 3:58 PM
• Marked as answer by Brij Shah Monday, March 16, 2015 4:50 AM

Hi Brij,

If your website mostly does read queries against the database, you can look into a setup with Active Geo-Replication which allows up to 4 readable secondary databases. This is supported in out Premium service tiers. Write operations would still have to go against the single primary database. Writeable secondaries are not supported.

Again in the case with a lot of reads you can reduce the round-tips to the DB using a cache layer that is collocated with the web-server and hence reduce page loading times.

If your application requires a lot of write, you could explore the option of sharding based on customer location and position the shards in the regions. This however is a more difficult approach. 

Lastly, if you are mainly looking into a scenario US West vs US East have you looked into what the experience actually is with a single database? The latencies might be acceptable and you can again look into a caching to reduce roundtrips.

• Proposed as answer by pehkeongteh Friday, March 13, 2015 3:58 PM
• Marked as answer by Brij Shah Monday, March 16, 2015 4:50 AM