Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Strategy for upgrading MySQL 5.7 to 8.0? #330

Open
ocdtrekkie opened this issue Jul 14, 2022 · 3 comments
Open

Strategy for upgrading MySQL 5.7 to 8.0? #330

ocdtrekkie opened this issue Jul 14, 2022 · 3 comments

Comments

@ocdtrekkie
Copy link
Collaborator

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
Copy link
Collaborator Author

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
Copy link
Collaborator

zenhack commented Jul 14, 2022

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
Copy link
Collaborator Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants