The Googles are failing for my specific concern. Has anyone moved a database (DBaaS) and the associated parent resource which is part of a SQL Data Sync Group to a new resource group within Azure? I've found that moving the database is supposed to be transparent to applications using it, but can't find specifics on whether the move will also be transparent to the Data Sync. Permissions between the resource groups are identical and the resource groups are within the same tenant and subscription.
1 Answers
1
votes
Looks like I've answered my own question so posting here to help others. With the help of my Azure Admin, we created a test SQLDB (with corresponding new DB server) in the same Resource Group as the DB I need to move. I then populated the new DB with test data and setup the Data Sync to a local DB on the same local instance. The initial sync tested fine. We then moved the new test server and DB (have to move both) over to the new resource group, again within the same subscription/tenant. Once completed (after about 5 minutes) we were able to see that while the application relying on the DB did in fact still work fine as expected, and the Data Sync Group showed up, the Data Sync Agent was a no-show. Trying to do a manual sync from the Sync Group did result in an error. So it appears moving DBs across resource groups will break the SQL Data Sync and to fix you'll need to rebuild the sync from scratch. I haven't gone through all those steps on the test DB, but will update this answer if additional issues arise after the actual production move tomorrow night.
Next night: Turns out the actual move was a non-issue. The database didn't show up immediately, even after logging out and back in, but the application never went down and after 5-10 minutes and navigating to Home, then SQL Databases within the portal, voila, the database showed up in the correct resource group AND both the Sync Group and Sync Agent also showed up after selecting "Sync to other databases". Not sure if it was timing or navigating to Home first. Regardless, a manual sync worked as expected. So not sure why our test case didn't work, but it would appear moving a SQLDB to a new resource group within the same tenant and subscription has a good chance of retaining its Data Sync to a local instance. As always though, your mileage may vary.
