locked
Geo-Replication RRS feed

  • Question

  • Hi

    Can you advise if we were to implement GeoRepl for our Europe site to Hong Kong both sites would be live and that users in Asia would access the Hong Kong site and users in Europe the EU site with the sites replicating the azure sql db's between both? Thanks Karl

    Friday, March 24, 2017 11:27 AM

Answers

  • Geo-Replication is not bi-directional. Applications update the primary database and changes are replicated to read-only secondary databases that may exist in different regions. The secondaries can be used to offload read-only workloads such as reporting but, since committed transactions are replicated asynchronously, the secondaries may be slightly behind the primary.

    See https://docs.microsoft.com/en-us/azure/sql-database/sql-database-geo-replication-overview.


    Dan Guzman, Data Platform MVP, http://www.dbdelta.com

    • Marked as answer by Dan Rediske Friday, March 24, 2017 3:53 PM
    Friday, March 24, 2017 11:56 AM
  • I thought if we had a geo repl site hosted in Hong Kong then users in China access this?  Am I way off track?

    Geo Replication can be used to mitigate your performance issue as long as you can distinguish between read-only and update requests in the application. The details depend much on the nature of the data needed. A simple example is an e-commerce application that's mostly read-only so it would be optimal to service data that doesn't need to be transactionally consistent (e.g. product catalog) from nearby databases and/or cache in an app layer or tier.  The primary would be used for order placement.

    I like to think about Geo Replcation as primarily a DR solution with the added benefit of possibly servicing read-only needs too.


    Dan Guzman, Data Platform MVP, http://www.dbdelta.com

    • Marked as answer by KarlMS Friday, March 24, 2017 4:07 PM
    Friday, March 24, 2017 12:34 PM

All replies

  • Geo-Replication is not bi-directional. Applications update the primary database and changes are replicated to read-only secondary databases that may exist in different regions. The secondaries can be used to offload read-only workloads such as reporting but, since committed transactions are replicated asynchronously, the secondaries may be slightly behind the primary.

    See https://docs.microsoft.com/en-us/azure/sql-database/sql-database-geo-replication-overview.


    Dan Guzman, Data Platform MVP, http://www.dbdelta.com

    • Marked as answer by Dan Rediske Friday, March 24, 2017 3:53 PM
    Friday, March 24, 2017 11:56 AM
  • Hi Dan

    Thanks for the info, I note that these are now readable secondaries.  I'll briefly advise our issue.

    We are a UK company with a site in MS Azure Europe, Chinese clients advise that this is slow to access use from within China.  We looked at CDN and whilst this slightly improved thecache static content, but not the dynamic pages containing data from the sqldb

    I thought if we had a geo repl site hosted in Hong Kong then users in China access this?  Am I way off track?

    Sorry Dan, I am running out of ideas.

    Thanks

    Karl

    Friday, March 24, 2017 12:11 PM
  • I thought if we had a geo repl site hosted in Hong Kong then users in China access this?  Am I way off track?

    Geo Replication can be used to mitigate your performance issue as long as you can distinguish between read-only and update requests in the application. The details depend much on the nature of the data needed. A simple example is an e-commerce application that's mostly read-only so it would be optimal to service data that doesn't need to be transactionally consistent (e.g. product catalog) from nearby databases and/or cache in an app layer or tier.  The primary would be used for order placement.

    I like to think about Geo Replcation as primarily a DR solution with the added benefit of possibly servicing read-only needs too.


    Dan Guzman, Data Platform MVP, http://www.dbdelta.com

    • Marked as answer by KarlMS Friday, March 24, 2017 4:07 PM
    Friday, March 24, 2017 12:34 PM
  • Thanks Dan
    Friday, March 24, 2017 4:08 PM