@stefano.menci asks:
Similar situation. I have fewer Apps, but more shared Databases per App: Dev, Test, and Public, each with its own source-code branch and run-time Environment.
1 Like
This is a good question, and there are two main approaches.
Which approach you should take depends on links between tables: If table A links to table B, but you only clone table A, you’ll end up with a new table A* linking to the old table B. If you then clone table B to create B*, the links in A* aren’t going to be magically redirected - the A* table still points to the old table B.
So, if you want to migrate linked tables, it’s best to do it all at once. If tables aren’t linked, you can migrate them piecemeal.
Option 1: One big migration
When you have multiple apps sharing tables with a nest of interrelated links, they should be cloned together. This goes as follows:
-
Identify the set of tables you want to migrate together - that’s anything that could possibly link to or be linked by anything else, across all your apps.
-
Create one big database (I recommend doing this in a new app), and add all your tables to it.
-
Clone this database. This will produce a new big database, with new versions of all your tables.
-
In each of the apps that use your tables, create a new Database. (This will, by default, create a bunch of empty tables. You’ll need to delete them carefully - don’t get the real ones by mistake!) Then add the tables your app needs from the new big database. Repeat this for each app.
-
Done! You now have new databases in your existing apps, referring to the new versions of each table!
Option 2: Piecemeal
If your tables don’t link to each other - as with @stefano.menci’s big “Logs” table - then you can go piecemeal. He could clone an individual DB or app into Faster Storage to create a new faster “Logs” table, then remove the old Logs table from each of his apps and add the new faster “Logs” table to each of them, without migrating any of his other tables.
The advantage here is gradual migration. The disadvantage is that if you break table links, you’ll have to reconstruct them by hand (or write a script), and it will be t-e-d-i-o-u-s. (And if you have mixed apps that write data into the wrong tables, you could have a real tangle on your hands.) Rolling this approach back is nearly impossible: Even if you have an Enterprise installation where you can do point-in-time rollback at any moment, the backup-restore machinery restores a database at a time, which doesn’t help you if your problem is cross-DB links. Plan carefully. Definitely the “experts take care” version.
If you’re not sure what to pick, choose Option 1.
Do a dry run first!
If you have production apps with production data, you will want to dry-run this migration! Fortunately, all of the actions here are non-destructive: They create new copies of your data in new tables. You can leave production pointed at your original tables while you move. This means you can practice your migration, test out the resulting apps and data, and verify everything looks good before cutting over and doing it for real. As long as you haven’t written any data into the new tables, rolling back is as simple as switching each app’s published environment back to the old database.
For more on environments and how this all works, check out the Deployment Environments section of our docs:
2 Likes
Meredydd, can you confirm that in step 5:
Done! You now have new databases in new apps, referring to the new versions of each table!
you actually meant new databases in the existing apps?
If these really were new apps, there would be quite a bit more migration work involved: custom URLs would need to be reassigned, Uplink keys recreated, Git remotes changed, scripts/configuration updated, etc.
Also, why do we need to create a new database in each app?
Is the main reason simply to keep the old database around so we can easily revert to the pre-Faster-Storage setup?
If so, couldn’t we skip that step if we’re willing to give up the easy rollback? In other words, keep the existing database and simply replace the old versions of the tables with the newly migrated Faster Storage versions.
We would then end up with the same database containing a mixture of old-style and Faster Storage tables, migrating only the tables we actually want to migrate.
Is there any technical reason that wouldn’t work?
1 Like
Yes, I did - typo now fixed above.
Exactly that. You could, of course, delete the existing tables from your existing databases and then add the new ones, but as you say you’re giving up the ability to roll back (or indeed to test your migration without affecting running apps).
If you’re comfortable “migrating only the tables we actually want to migrate”, then yes, you can mix and match like that. By that point I’d say you’re doing my “Option 2”, and you’re subject to all of its dangers (namely, that if you ever migrate a table with a link column separately from the table it’s linking to, you can easily create a pickle that would be quite difficult to recover from - especially if you’ve deleted the originals in the process!).
2 Likes