I recently had notice from my VPS provider that my site was using a compromised version of PHP that contained the php2shell vulnerability, so reported on by the media lately.
Being the responsible website owner that I am, I immediately set about to upgrade my server from Ubuntu 20.04 (Focal Fossa) to the next LTS version 22.04 (Jammy Jellyfish). Arguably I could have gone further, but as Jammy is still under long term support, and because the upgrade process is rarely smooth, I opted to only go up one version. The necessary patch for PHP 8.1 is provided by Canonical for this version, so it'll do.

And that's where the fun started. I did all the usual prep for a version upgrade, including bringing existing packages up to the latest available version within the installed Ubuntu release, and then I set the upgrade command going. It got most of the way before falling over on MySql server - the database that underpins my blog posts.
This stopped the upgrade process in its tracks, and was caused by a lack of available RAM. Sadly, my server is still surviving on just 512MB of RAM. The solution suggested by Claude (yuck...) was to use a ramdisk to overcome this shortfall. This worked. Sort of. It overcame the RAM problem, but the aborted installation from earlier left MySQL in an unupgradable position, from which I was likely to lose data.

The position I found myself in was that I still had access to the innodb files that contain the blog data but no means to access them. At this point I decided that if MySQL was going to be a resource hog on my overstretched (virtual) machine, then I'd have to do without it.

The solution I settled on was to migrate everything over to SQLite. Still a relational database and a syntax I'm familiar with, but much less resource hungry and perfect for a tiny blog with infrequent updates, only one contributor, and hardly any visitors. The question was how to extract the data from the MySQL database without running up an instance of MySQL server. The answer, not suggested by Claude, is an excellent little Python program called ibd2sql which can extract both the DDL (the code that creates the tables) and the data as a series of INSERT statements and output them as a file in MySQL syntax.

Thankfully the site only comprises a small handful of tables, as the website and database are hand-rolled rather than relying on third party software like WordPress, so a quick bash script to loop through the ibd files and create SQL output did the job, and ChatGPT (again, yuck...) converted them from MySQL syntax to SQLite syntax. The differences aren't important. This allowed me to import all my existing blog posts back into my new SQLite database. Hooray! The next step was to modify the PHP to use the new database instead of the old. There were a few data retrieval functions (mostly fetch_object()) not available, but it wasn't hard to convert these to fetchArray() to get everything up and running again.

The result is that I can now remove MySQL from the server entirely, and have a smaller resource footprint going forward.

I'm also no longer vulnerable to the php2shell bug. Imagine the damage an attacker could wreak if they access this server! :D

ibd2sql is available from here and is an invaluable piece of software if you find yourself in the same situation as me.