6 years ago, while visiting family who are volunteer doctors working through an NGO in rural South America, I set up an instance of openemr 5.0.2 running on a Windows laptop with WAMP to assist them in their work of primary health care. It has worked well. They have come home for a visit and brought the old laptop which needs an update. I have managed to successfully build a Raspberry Pi5 with an NVMe drive to run openemr 7.0.3 in a docker container using the docker-compose.yml from the openemr dockerhub site. This is working very well.
My problem now is how to get the hundreds of data records from the old laptop (version 5.0.2) to the new setup on the new hardware (version 7.0.3). I have the mysql database extracted using myqldump, but clearly have to do quite a bit more than just replact the database contents. Some on this forum have suggested using “sql_upgrade.php” which sounds great, but this file does not appear to be in the docker image.
Do I really need to install and upgrade the 6 versions (Upgrade 7.0.2 to 7.0.3 Upgrade 7.0.1 to 7.0.2 Upgrade 7.0.0 to 7.0.1 Upgrade 6.1.0 to 7.0.0 Upgrade 6.0.0 to 6.1.0 Upgrade 5.0.2 to 6.0.0)? Or is there some way to do this in a more ef
ficient way?
I would be gratful for any suggestions so that I can give them a working Pi5 with their patient data on it to take back with them next month.
5.0.2? That’s… Alright, here’s the deal. I can’t solve this for you – but I can give you a quick overview of all the moving parts, and hopefully put you in a position to decide if you can pull it off or not in the time you’ve got.
5.0.2 was the first docker we put in our devops repo. It’s not the first container we built but every version that followed we got better at understanding what we’re doing. Could you get your installation from 5.0.2 WAMP into 5.0.2 containerized? Maybe. Should you? Maybe. However, it happens that our first Raspberry ARM8 build was 6.0.0, so you absolutely won’t be able to go directly into your Pi in that state.
So I think you’ll upgrade WAMP in place to 6 or 7 before importing it. Once it’s in the right container, the containers handle upgrades very sensibly. So don’t import a 6 or something into a 7 container, import it into a 6 container and then upgrade the container and re-up the docker-compose. The higher the version number you upgrade your WAMP to, the smarter the container you’re upgrading to is.
Of course, how you should get your WAMP into a Docker is a good question, since it’s not just the database but the patient records, the documents, all that, right? That’s where were we need to talk about my ingestion script. openemr-devops/packages/lightsail/ingestion.sh at master · openemr/openemr-devops · GitHub was my first crack at trying to build a tool to take OpenEMR’s backup tarball (not your mysqldump but the backup/export you make from inside the OpenEMR application menus) and slurp it into a container. I didn’t write it to work on containers that old, and I never get much feedback about the thing so I don’t know if it works well or if anybody uses it, but it is at the very least an example of the kinds of things you want to be thinking about if you want to containerize an existing installation.
That’s basically how I think this is going to go for you.
- Create some form of in-place backup, since this process could be destructive.
- Stepwise upgrade your existing installation from 5.x to as high as seems sensible.
- Export your installation with the internal backup tool and import it with (or by following along) the ingestion tool into a container of the correct version.
- Launch the new container and verify stability and correctness.
- Stop the cluster, set the final version of OpenEMR in the compose file, and re-up the application.
It’s entirely possible, thinking this through, that you might have to perform two export and import pairs. One export from the WAMP system to a 5.0.2 backup, and from there into your personal workstation into a 5.0.2 Intel container, then perform containerized upgrades, then export from the 7.0.3 Intel to a 7.0.3 backup, then import that into a 7.0.3 ARM container. This process, while unwieldy, is safer than trying for an upgrade to 6 on the master copy of production when I don’t know how often your backup regimen has been tested.
Hope this helps.
Thank you very much @jesdynf for such a comprehensive reply. I will attempt what you suggest (I’m not an IT expert, but a retired engineer and IT hack). I will post how it goes.
@jesdynf is much wiser than I on the containers, so I’m not even going to try to make any suggestions there.
However, I might have an idea or 2 about the version upgrade part, and I have actually done quite a few version upgrades from version 5 to version 7, and actually even some from version 4 to version 7.
I’d like to hear @jesdynf thoughts on this, but since the existing data is already running in 5.0.2 WAMP, would it make more sense to pull that data into a 7.0.3 environment, on WAMP/XAMPP, run the software upgrade there (just to take the container variable out of the upgrade equation), and then migrate everything from WAMP/XAMPP into a 7.0.3 container, knowing that the version upgrade is done and the application/database are healthy and happy ? That would mean you only have to export & import once, although it would add the extra overhead of building a newer WAMP/XAMPP stack to do the heavy lifting on the version upgrade(s), but you have to do that anyway? Having been through a fair amount of these, some of which take 30+ hours of data processing just to bring the database up to the new version, my biggest concern in this situation would be having something ambiguous go wrong, and then be left trying to isolate if the source of the problem was the version upgrade, or the container setup. We don’t know the data volume, maybe it’s small enough to make everything easier, when you’re dealing with some of these databases that have 100K patients, half a million encounters, and millions of documents, it extends the cycle time for every experimental run as you’re testing a phase of the overall version upgrade process. So in this case, to simplify, it’s on WAMP now, keep it there until it’s current, and that way the last step is to bring everything online in the newest/smartest version of the Docker container structure that’s available.
I could be way off, in which case I deserve a virtual head smack for my logical failure!
Well, you’re right – if the upgrade goes right. I don’t know if it will or not, and I don’t know what state local backups are in, or the prospects of recovery from them.
The reason I put the protocol together the way I did is because it’s guaranteed non-destructive. The 5.0.2 backup is the source of all the work that follows, and any failure of process never touches production. Stepwise upgrading production to 7 in-place skips a lot of steps, but it skips a safeguard too.