Read replicas are now generally available to all Azure Database for MySQL users. They are specially designed to make it easy to horizontally scale out beyond a single database server. This may be useful in applications that have more read operations than write ones such as BI reporting applications.

This feature enables continuous asynchronous replication of data from the master Azure Database for MySQL server to up to five replica servers in the same region. Replica servers are read-only and allow only writes replicated from data changes on the master.

Management of the read replicas

Azure allows management of the replica servers either from Azure portal or Azure CLI. Stopping replication to any replica server makes it a standalone read-write server.

Manage replicas using the Azure portal:

Replica management via Azure portal

 

Azure Monitor allows tracking replication via the replication lag in seconds metric.

 

Azure monitor

Manage replicas using the Azure CLI:

Management via Azure CLI

 

Pro Tip: Get deep and immediate insight into the stability of all of your Azure resources.

Replicas for scaling workloads application pattern samples

BI reporting

Master server loads data processed every few minutes. The master server has to be configured for processing loads and must not be directly involved in exposing data to BI users to ensure predictable performance. The read workload, reporting in our case, is scaled across several replicas to manage high user concurrency with low latency.

BI reporting graph

Microservices

This pattern breaks the application into several microservices whereas data modification API connects to the master server while reporting APIs connect to the read replicas. The load balancer is used to route the traffic based on the API prefix.

 

Microservices graph

Get started