Mirroring, DTAP workspaces and branches

[nielsvdc]

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?

[v-zhengdxu-msft]

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.