search

sandstorm-io / vagrant-spk

Packaging tool for Sandstorm, a self-hosting platform for web apps!
Apache License 2.0
55 stars 29 forks source link

Strategy for upgrading MySQL 5.7 to 8.0? #330

Open ocdtrekkie opened 1 year ago

ocdtrekkie commented 1 year ago

So, I am looking at upgrading to bullseye64. I know it works for the lemp stack because I'm building an app with it, but the issue is upgrade-friendliness. Oracle offered 5.7 for Jessie, Stretch, and Buster, however, they are only offering MySQL 8.0 for Bullseye.

https://dev.mysql.com/blog-archive/inplace-upgrade-from-mysql-5-7-to-mysql-8-0/ says you can just start MySQL 8.0 on a 5.7 data directory, but I believe that is "assuming everything is healthy", which is not a good assumption for Sandstorm grains which we arbitrarily kill. (I am half-tempted to just PR updating everything, but I thought about it, and realized @zenhack would rightfully call me out on this one on review.)

The lemp and uwsgi stacks would both need a solution for this before we upgrade to Bullseye by default, and I am wondering if we can/should use the Nix solution used for TTRSS in general. I hate putting a TON of excess into stacks that may be used for greenfield projects, but maybe we could leave instructions to comment it out for new packages? (Or leave it commented out, and suggest people using upgradevm uncomment it?)

ocdtrekkie commented 1 year ago

I guess this is also #276, but mysql5.5 to mysql5.7 was a long time ago, and mysql5.5 to mysql8.0 is now.

While thinking about this, I think the correct answer is to not use the upgrade code by default, since we want vagrant-spk to work out of the box for new packaging, and be efficient at doing that, but also we should probably include it, commented out, with a note to uncomment it if upgrading from an older version.

zenhack commented 1 year ago

I think it's ok to upgrade this in the base boxes without adding upgrade logic, since upgradevm is a manual step anyway. Though we should maybe add a link to #276 in a comment as a warning. (We should separately come up with an upgrade strategy, but I don't think it needs to block the update for greenfield projects).

ocdtrekkie commented 1 year ago

I am not sure where we would add a comment likely to be seen... Maybe when implementing something like #258?

I feel like your TTRSS upgrade logic would work for the actual upgrade strategy, but it probably needs to be relatively bundled up into: "uncomment these lines in setup and launcher if you previously released a version of this package using mysql5.5, and uncomment these ones if you previously released a package using mysql5.7".

But if you're comfortable not blocking on it, I will do some formal testing with the Python and PHP test apps and then mark the PR ready for review.