Well, that’s the thing. This won’t really upgrade MySQL at all. The OpenEMR container is separate from the databases it uses. Nobody currently using a MySQL server will switch over to a MariaDB server. So we’ll have (and excuse the made-up versions, please)…
Version 7 + MySQL/XtraBackup (guy who sets up AWS packages today)
Version 7 + MariaDB (guy who sets up container today with their own choice of DB server)
And then we’ll have…
Version 8 + MariaDB/MariaBackup (guy who sets up new AWS packages with new tech)
Version 8 + MariaDB (guy who sets up container under their own terms)
Version 8 + MySQL (this guy just doesn’t like MariaDB and that’s okay I guess)
All five of those circumstances are fine. But let’s talk about that first guy again. If he upgrades to the new OpenEMR, if he pulls in a new container image but leaves the rest of his system alone, which is allowable, he’ll be on “Version 8 + MySQL/Xtrabackup”. And that’s fine as long as I allow for it, as long as I make sure all the scripts keep working (so I guess I’d probably make new backup and recovery scripts with new names for MariaDB and change how they’re installed on the host systems).
Again, all fine as long as I understand I have to step around it.
But one thing that does make me mad is that we break the expectations of export and recovery – there is no ingestion path from the upgraded instance (that uses MySQL/XtraBackup tables and export files) into a fresh instance that uses MariaDB/Mariabackup. You’d have to either rely on the OpenEMR import process, hack something very particular together from my raw deployment objects, or just freehand it with mysqldump.
Worse yet, if I pursue this further and we choose to standardize on MariaDB instead of insist on compatibility, we’ll close the upgrade path to everybody currently using MySQL unless they solve exactly the problem I just discussed, upgrading their database engine right under the application and without the usual level of assistance I prefer to offer.