Forum Discussion
Mirroring, DTAP workspaces and branches
We have 3 workspaces for our development, test and production environments and each environment has it's own branch. We created a mirroring item in development to sync data from a SQL server to Fabric. The mirroring item supports syncing with a git repo.
We are using Azure DevOps to deploy code to another environment branch and use the Update from Git API to update the target workspace.
When updating the workspace using the API, we get the error:
Updating Fabric workspace update from git has failed: {'errorCode': 'GitSyncFailed', 'moreDetails': [{'errorCode': 'Git_InvalidResponseFromWorkload', 'message': 'An error occurred while processing the operation', 'relatedResource': {'resourceId': 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx', 'resourceType': 'MountedRelationalDatabase'}}], 'message': 'Failed to sync between Git and the workspace'}.
Updating from Git works when we do it manually by clicking the Update All button in the workspace. But when we look at the mirroring item, we see the error message:
Code: SqlChangeFeedError, Type: UserError, Message: This SQL Database can only be mirrored once across Fabric workspaces
So, using mirroring does not really work in a DTAP environment. Anyone has any advise?
Hi nielsvdc
Why Manual Update Works but API Fails is Manual "Update All" might skip re-provisioning the mirroring item if it already exists, whereas the API could be reapplying the full Git state, attempting to recreate the mirroring item and triggering the error.
The error occurs because Fabric allows a SQL database to be mirrored only once across all workspaces. When deploying via the API, the mirroring configuration is likely recreated in each environment workspace, violating this constraint. Here's a structured solution:
Create a central workspace solely for mirroring the SQL database. This workspace is not part of your DTAP branches, ensuring no other workspace mirrors the same database.
Use Fabric's data sharing features (e.g., shortcuts, data products, or shared datasets) to reference the mirrored data in your dev/test/prod workspaces, and avoid re-mirroring in each environment; instead, reference the central mirrored dataset.Remove mirroring configurations from environment-specific branches. The Git repo should only include code that doesn’t trigger re-mirroring. Use environment-specific parameters(e.g., connection strings) to point to the shared mirrored data or their own databases.
Use Separate SQL Databases for Each Environment:If strict environment isolation is required, provision dedicated SQL databases for dev, test, and prod.
Mirror each database in its respective workspace. This avoids conflicts since each is a unique database.
Leverage Fabric Deployment Pipelines:
Instead of Git sync, use Fabric’s deployment pipelines to promote content (including mirrored data) from dev → test → prod.
Deployment pipelines handle dependencies like mirrored items without re-mirroring.Modify API Deployment Logic:
Before invoking the Update from Git API, ensure the target workspace does not include mirroring items.
Use the API to sync only non-mirroring components (e.g., reports, datasets) and reference the shared mirrored data.Best Regards
Zhengdong Xu
If this post helps, then please consider Accept it as the solution to help the other members find it more quickly.
2 Replies
Hi nielsvdc
Why Manual Update Works but API Fails is Manual "Update All" might skip re-provisioning the mirroring item if it already exists, whereas the API could be reapplying the full Git state, attempting to recreate the mirroring item and triggering the error.
The error occurs because Fabric allows a SQL database to be mirrored only once across all workspaces. When deploying via the API, the mirroring configuration is likely recreated in each environment workspace, violating this constraint. Here's a structured solution:
Create a central workspace solely for mirroring the SQL database. This workspace is not part of your DTAP branches, ensuring no other workspace mirrors the same database.
Use Fabric's data sharing features (e.g., shortcuts, data products, or shared datasets) to reference the mirrored data in your dev/test/prod workspaces, and avoid re-mirroring in each environment; instead, reference the central mirrored dataset.Remove mirroring configurations from environment-specific branches. The Git repo should only include code that doesn’t trigger re-mirroring. Use environment-specific parameters(e.g., connection strings) to point to the shared mirrored data or their own databases.
Use Separate SQL Databases for Each Environment:If strict environment isolation is required, provision dedicated SQL databases for dev, test, and prod.
Mirror each database in its respective workspace. This avoids conflicts since each is a unique database.
Leverage Fabric Deployment Pipelines:
Instead of Git sync, use Fabric’s deployment pipelines to promote content (including mirrored data) from dev → test → prod.
Deployment pipelines handle dependencies like mirrored items without re-mirroring.Modify API Deployment Logic:
Before invoking the Update from Git API, ensure the target workspace does not include mirroring items.
Use the API to sync only non-mirroring components (e.g., reports, datasets) and reference the shared mirrored data.Best Regards
Zhengdong Xu
If this post helps, then please consider Accept it as the solution to help the other members find it more quickly.Before posting ther question I was thinking the same thing. Unfortunately there is only one source production database that we can work with. What we are going to do is create the mirrored database in a separate workspace without a repository attached. Then in each environment workspace we create a landing Lakehouse and create shortcuts to the tables in the mirrored database. I think shortcuts are currently in preview for git integration, so these should be deployed automatically to each environment.
