2

I'm upgrading a Debian installation which has been running the dotdeb package for MySQL 5.6. Since dotdeb isn't supporting MySQL anymore, I'd like to migrate to the repo hosted directly by Oracle.

Removing dotdeb is easy: just remove the repo from /etc/apt/sources.list. Likewise, adding the Oracle repo is easy: edit the same file to add it.

But, I'd like to make sure that I:

  1. Don't delete anything important -- such as config files, data, etc.
  2. Don't leave any old, outdated packages or files around
  3. Don't get any errors from apt going forward

I suspect I just want to do this:

  1. apt-get remove mysql-server (and any associated packages)
  2. Remove dotdeb repo from /etc/apt/sources.list, add Oracle's repo
  3. apt-get install mysql-server (and any associated prerequisites)

I will make sure to back-up everything, but I'd rather do it right the first time and not require any restoration if possible.

Christopher Schultz
  • 1,056
  • 1
  • 11
  • 20
  • Everyone (including the original MySQL developers) has switched to MariaDB, and MariaDB has its own apt repos for every current version of Debian and MariaDB. There's not really much of anything for dotdeb to do here. If you go to Oracle MySQL you may have occasional trouble getting support from anyone but Oracle. And of course Oracle may just kill MySQL. – Michael Hampton Nov 02 '18 at 22:10
  • @MichaelHampton I'm not asking dotdeb to do anything. I'm asking what the best way is to switch repos for a package; the mysql-server package in particular. I could have easily asked "how can I switch from the dotdeb repo to the MariaDB-hosted repo" instead of Oracle. The answer should basically be the same. – Christopher Schultz Nov 02 '18 at 22:29

2 Answers2

3

It seems unnecessarily dangerous to try to do this on an existing machine.

Build a new server.

Configure it as desired.

Dump and load the data, configuring the new system as a live MySQL native replica of the existing system.

Verify that it is live and replicating and that all your data is intact.

Shutdown the original server, disconnect the replication to promote the new machine to primary, and switch your application to use the new server.

As a long-time MySQL DBA, I never, ever allow package managers to touch my database installations. This is admittedly a matter of opinion, but as a DBA, it's not the servers I'm ultimately responsible for -- it's the information they store... the actual database. The integrity of that data is far more important than any imagined benefit or convenience from package management. I decide when updates and upgrades occur, and I'm fully in control of the process, isolated from assumptions package management developers seem to make, some of which can be quite ridiculous. Oracle also provides binary tarballs that are far more straightforward and not prone to package management surprises.

Michael - sqlbot
  • 21,988
  • 1
  • 57
  • 81
0

Ultimately, I opted to simply uninstall the dotdeb package (which leaves configuration files in-place) and install the MariaDB from the Debian package manager.

This worked for me without any problems whatsoever.

The MariaDB package is rigged to read all the old configuration files from /etc/mysql/ and /etc/mysql/conf.d/ so it came right back up without any problem at all. Of course, we tries this on two other systems before upgrading in production, and all was well.

While configuring a completely new server as a replication-slave would have been a 100% bulletproof solution, it was not necessary in my case.

Christopher Schultz
  • 1,056
  • 1
  • 11
  • 20