Hi @Marostegui / DBA in general,
in T333885 we are planning to migrate the current Phabricator prod server to Phorge, a fork of Phabricator.
It's not a big difference so far and as far as we know and can see when glancing at it, the database scheme has not changed a lot.
But there is still an upgrade script that might change it and we don't want to risk this on the current Phabricator DB, or at least not without being sure we can easily revert if we have to.
So we have been thinking along these lines:
- Maybe we should ask DBA to make a copy of the existing prod DB (actually DBs.. you know how Phabricator uses a ton of them.. for better or worse), call the copies "phorge_*" instead of "phabricator_*", create new GRANTS/user for them
- Then we could schedule a maintenance window, point the server to the new databases, try things out without it ever touching the prod database, be sure it cant even by accident touch the prod database as long as we make sure the database user is changed
- If things work fine we just stay on these new databases and some time later you can delete the old ones
- If things don't work out we end the maintenance window, switch back to current databases and see where to go next
- OR.. maybe we should rather ask DBA/backup people how to revert a database to a previous state, in general, and what the actual process for that is, if it needs them be around or not at all
- OR.. maybe DBA has much better ideas how we should solve this as long as it is:
- reasonably safe we don't mess up the prod db or can restore it
- not too complex for everyone involved.. also given that there are so many databases and all the grants..
Finally, we are not even fully decided if we should do the upgrade "in place" on the current prod hardware, where IP would stay the same, or whether we should use a different host to test. Depending if the current GRANTs are limiting to IP we might or might not have to touch them.. but at the same time I think we would like to use a different mysql user to be sure.