Read replicas in Azure Database for MySQL
The read replica feature allows you to replicate data from an Azure Database for MySQL server (master) to up to five read-only servers (replicas) within the same Azure region. Read-only replicas are asynchronously updated using the MySQL engine's native binary log (binlog) file position-based replication technology. To learn more about binlog replication, see the MySQL binlog replication overview.
Replicas created in the Azure Database for MySQL service are new servers that can be managed in the same way as normal/standalone MySQL servers. For each read replica, you are billed for the provisioned compute in vCores and provisioned storage in GB/month.
To learn more about MySQL replication features and issues, please see the MySQL replication documentation.
When to use read replicas
Applications and workloads that are read intensive can be served by the read-only replicas. Read replicas help increase the amount of read capacity available compared to if you were to just use a single server for both read and write. The read workloads can be isolated to the replicas, while write workloads can be directed to the master.
A common scenario is to have BI and analytical workloads use the read replica as the data source for reporting.
Considerations and limitations
Read replicas are currently only available in the General Purpose and Memory Optimized pricing tiers.
Master server restart
When you create a replica for a master that has no existing replicas, the master will first restart to prepare itself for replication. Please take this into consideration and perform these operations during an off-peak period.
You can choose to stop replication between a master and a replica server. Stopping replication removes the replication relationship between the master and replica server.
Once replication has been stopped, the replica server becomes a standalone server. The data in the standalone server is the data that was available on the replica at the time the "stop replication" command was initiated. The standalone server does not catch up with the master server. This server cannot be made into a replica again.
Replicas are new servers
Replicas are created as new Azure Database for MySQL servers. Existing servers cannot be made into replicas.
Replica server configuration
Replica servers are created using the same server configurations as the master, which includes the following configurations:
- Pricing tier
- Compute generation
- Backup retention period
- Backup redundancy option
- MySQL engine version
- Firewall rules
After a replica has been created, you can change the pricing tier (except to and from Basic), compute generation, vCores, storage, and backup retention independently from the master server.
Master server configuration
If a master's server configuration (ex. vCores or storage) is updated, the replicas' configuration should also be updated to equal or greater values. Without this, the replica server may not be able to keep up with changes made to the master and may crash as a result.
New firewall rules added to the master server after a replica server has been created are not replicated to the replica. The replica should be updated with this new firewall rule as well.
Deleting the master server
When a master server is deleted, replication is stopped to all read replicas. These replicas become standalone servers. The master server itself is deleted.
Users on the master server are replicated to the read replicas. You can only connect to a read replica using the user accounts available on the master server.
- Global transaction identifiers (GTID) are not supported.
- Creating a replica of a replica is not supported.
- In-memory tables may cause replicas to become out of sync. This is a limitation of the MySQL replication technology. Read more in the MySQL reference documentation for more information.
- Tuning the
innodb_file_per_tableparameter on a master server after creating a replica server may cause the replica to become out of sync. The replica server is not aware of the different tablespaces.
- Ensure the master server tables have primary keys. Lack of primary keys may result in replication latency between the master and replicas.
- Review the full list of MySQL replication limitations in the MySQL documentation
- Learn how to create and manage read replicas using the Azure portal
- Learn how to create and manage read replicas using the Azure CLI
We'd love to hear your thoughts. Choose the type you'd like to provide:
Our feedback system is built on GitHub Issues. Read more on our blog.