| Bug #98674 | Upgrade from version 5.5.17 on a Mac, but old Mac versions unavailable | ||
|---|---|---|---|
| Submitted: | 19 Feb 2020 18:56 | Modified: | 20 Feb 2020 4:14 |
| Reporter: | Renee Revis | Email Updates: | |
| Status: | Unsupported | Impact on me: | |
| Category: | MySQL Server: Installing | Severity: | S3 (Non-critical) |
| Version: | OS: | MacOS | |
| Assigned to: | MySQL Verification Team | CPU Architecture: | Any |
[19 Feb 2020 18:56]
Renee Revis
[20 Feb 2020 2:57]
MySQL Verification Team
Hi, > The problem is that I can't find downloads for Mac OS X for either 5.5.62 or 5.6.46. Yes, unfortunately, our archives don't keep those. > this might be considered a bug It might but not much can be done about releases that are that old and out of support cycle, hence setting this to "unsupported". > I can try using the Linux-Generic version tarball, but I wanted to check first to see if there is a better way. I doubt Linux-generic will help you much on MACOS > Is it possible to get the native OS X installer for these two versions? Is there any other better way I can upgrade? Native OSX installer from us, no. OSX binaries - you can download the source code and compile yourself. Better way to upgrade, well, depends on what you have. If you have that 5.5.17 running on your system you can do a mysqldump of your database, install a new and shiny 8.0.xx and restore that dump. If you only have datadir from an old 5.5.17 installation and nothing else you can install 5.5.62 on Linux running in the virtualbox or some spare computer, load the datadir there, run mysql_upgrade and follow the procedure (either dump and then restore in to 8.0 or upgrade to 5.7 and then to 8.0). I hope this helps at least a bit. kind regards Bogdan
[20 Feb 2020 3:10]
Renee Revis
I realize my version is way old, so I understand that it isn't officially supported, but thanks for the info. I thought something I read said that if I did a mysqldump and restored from that, I would still have to run the upgrade command (can't remember the specifics), so I thought I would still have to go through the process of moving from one version to the next. That's fantastic if I can go straight to 8.0 though. I do still have 5.5.17 running so can generate the dump. I'll try that approach. Thanks so much for your help!
[20 Feb 2020 3:28]
MySQL Verification Team
Hi, > I thought something I read said that if I did a mysqldump I didn't go into specifics (as this is neither the support portal nor the public forum) but just gave you a general instructions on how to try to solve the problem. If you dump "everything" it will not work on the 8.0 for sure as the structure of the system tables (namely the whole mysql database, sys database..) is very different. Dumping only your data into an operating 8.0 and manually creating users, permissions etc. should work. The upgrade path you talk about that require 5.5->5.6->5.7->8.0 is when you are upgrading datadir directly. This require gradual upgrade procedure. Also if you dump/restore system tables they will be "wrong" and mysql_upgrade could solve that (will not always, especially not going trough many versions). My assumption is that you don't need your old users & permissions, you need your data to resurrect the project so you will have to recreate users anyhow. If not, again, way faster to dump the users & permissions and manually add them to the new system than to "upgrade" them trough all those steps. Of course, do not kill your "source of info" (original binaries and datadir) until you successfully have it running on 8.0 on second machine. Before you start, read this: https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html The important section is: If you import databases from a dump file created in MySQL 5.7 (or earlier) using mysqldump into a MySQL 8.0 server, you must make sure that any statements creating partitioned tables do not also specify an unsupported storage engine, either by removing any references to partitioning, or by specifying the storage engine as InnoDB or allowing it to be set as InnoDB by default. So check if you have partitioned data on that original system and check if that partitioning is also supported in 8.0. You might want to alter the dump file (use text editor) to fix if not. And one important piece of advice. Do 2 dumps, one dump with --no-data so you dump only the metadata (table structure) and one dump with --no-create-info so you get only the insert statements in that dump. You restore first the first one to create all the databases and tables on the new system. If something fails it is easy and fast to edit a small txt file containing only creates, if something fails it will fail "quickly" as all creates take no time to execute so it's easy to drop everything and create everything in minutes. When you successfully restore the metadata (created all databases and tables you want) then let the second dump run so you insert all the data. kind regards Bogdan
[20 Feb 2020 3:45]
Renee Revis
This is so helpful! Thank you! Thankfully the data is fairly simple. No partitioned tables and it only uses InnoDB. Also, you're right about not needing the users or permissions. Just need to get the basic data over. I'll take your advice about doing the two different dumps as well. I really appreciate this additional info!
[20 Feb 2020 3:48]
MySQL Verification Team
Great so straight forward move to 8.0. Just be sure not to dump all databases but only those for your project as mysql, sys etc.. will not be liked on the 8.0 system :D glad I could be of help Bogdan
[20 Feb 2020 4:14]
Renee Revis
Yes, I can see how that would be a problem ;-)!
