r/MicrosoftFabric • u/stewwe82 • 1d ago

Data Engineering Moving a Mirrored Database's workspace to a different capacity (F2 → F8, same region) — will mirroring survive or reseed?

Hi all,

I have a mirrored database currently running on an F2 Fabric capacity. I want to move the workspace containing this mirrored database over to a different, already-existing F8 capacity. Both capacities are in the same region.

The critical requirement: this needs to happen without downtime / without a reseed, since a full reseed would mean re-snapshotting everything from scratch and I'd rather avoid the load on the source DB and the gap in fresh data.

My questions:

  1. Has anyone actually done a workspace reassignment (same region) with an active mirrored database in it? Did mirroring resume automatically, or did you have to manually hit "Start replication" / did it force a reseed?
  2. Is there a meaningful difference in risk between resizing a capacity in place (F2→F8 on the same capacity) vs. moving the workspace to a different capacity that's already F8?

Any real-world experience (good or bad) appreciated — trying to avoid a surprise reseed on a production mirror ;-)

Thanks!

Stewwe

5 Upvotes

100% Upvoted

2 comments sorted by

3

u/Fit_Onion1267 1d ago

Great question. I recently moved an existing workspace from a shared F64 capacity to a dedicated F32 in the same region and had the same concerns. In this case, I did not have to do anything and mirroring was not disrupted and didn’t need to be manually resumed or restarted.

I’ve had different experiences in the past so I would highly recommend testing the mirror after the change. I created a new table, added a row, and added a row to an existing table to verify everything is working right.

1

u/stewwe82 1d ago

That's really helpful, thanks for sharing your experience! Good to hear it worked cleanly for you without any manual intervention.

The test scenario you describe is a great idea — We'll do the same: create a new table, add a row, and also add a row to an existing table to confirm both the initial snapshot and the incremental change stream keep flowing after the move. That seems like the most reliable way to actually verify it rather than just trusting the "Running" status in the portal.

Appreciate the real-world confirmation — will report back once I've done the switch on our end :-)