Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Important
This feature is in preview.
Mirroring in Fabric provides an easy experience to avoid complex ETL (Extract Transform Load) and integrate your existing Azure Database for MySQL estate with the rest of your data in Microsoft Fabric. You can continuously replicate your existing Azure Database for MySQL directly into Fabric's OneLake, whether your servers are publicly accessible, network-isolated through virtual networks or private endpoints, or configured for high availability. Inside Fabric, you can unlock powerful business intelligence, artificial intelligence, data engineering, data science, and data sharing scenarios.
For a tutorial on configuring your Azure Database for MySQL Mirroring in Fabric, see Tutorial: Create a mirrored database from Azure Database for MySQL in Microsoft Fabric (preview).
Why use Mirroring in Fabric?
By using Mirroring in Fabric, you don't need to piece together different services from multiple vendors. Instead, use a highly integrated, end-to-end, and easy-to-use product that simplifies your analytics needs. It's built for openness and collaboration between Microsoft, Azure Database for MySQL, and the thousands of technology solutions that can read the open-source Delta Lake table format.
What analytics experiences are built in?
Mirrored databases are an item in Fabric Data Warehousing distinct from the Warehouse and SQL analytics endpoint.
Mirroring creates these items in your Fabric workspace:
- The mirrored database item. Mirroring manages the replication of data into OneLake and conversion to Parquet, in an analytics-ready format. This process enables downstream scenarios like data engineering, data science, and more.
- A SQL analytics endpoint
Each mirrored database in Azure Database for MySQL has an autogenerated SQL analytics endpoint that provides a rich analytical experience on top of the Delta Tables created by the mirroring process. Users have access to familiar T-SQL commands that can define and query data objects but can't manipulate the data from the SQL analytics endpoint, as it's a read-only copy. You can perform the following actions in the SQL analytics endpoint:
- Explore the tables that reference data in your Delta Lake tables from Azure Database for MySQL.
- Create no code queries and views and explore data visually without writing a line of code.
- Develop SQL views, inline TVFs (Table-valued Functions), and stored procedures to encapsulate your semantics and business logic in T-SQL.
- Manage permissions on the objects.
- Query data in other Warehouses and Lakehouses in the same workspace.
In addition to the SQL query editor, there's a broad ecosystem of tooling that can query the SQL analytics endpoint, including SQL Server Management Studio (SSMS), the mssql extension with Visual Studio Code, and even GitHub Copilot.
Mirrored databases also offer one-click integration with Microsoft Power BI within Fabric, enabling rapid report creation directly from the mirrored data or SQL analytics endpoint.
Network requirements
Mirroring supports both publicly accessible servers and network-isolated configurations, including servers hosted in virtual networks. If your server isn't publicly accessible and doesn't allow public access to connect to it, you can create a virtual network data gateway or set up on-premises data gateway to mirror the data. Make sure the Azure Virtual Network or the gateway machine's network can connect to the Azure Database for MySQL and is allowed by the firewall rule.
Active transactions, workloads, and replicator engine behaviors
Active or long-running transactions can delay binary log (binlog) purging until the transaction commits and any downstream replication or migration process catches up. This delay can cause binlog storage to grow unexpectedly, so monitor storage utilization on the source server to avoid space exhaustion.
During the initial snapshot or data load, higher CPU and IOPS usage is normal as data is read and copied. Workloads with frequent UPDATE or DELETE operations might generate extra redo and binlog activity, which further increases IO and storage consumption.
Monitor storage, IOPS, and long-running transactions to ensure sufficient capacity throughout the process.
Compute tier support
The source Azure Database for MySQL can use either a General Purpose or Memory Optimized compute tier. Burstable compute tier is not supported as a source for mirroring.
For more information about compute tiers available in Azure Database for MySQL, see service tiers.