I'm currently running a system with a 5.6 MySQL database and I'm considering upgrading it to 5.7.

  1. Do you think that upgrading it will be a good step? I do want to keep my software as up to date as possible, but why fix what isn't broken?

  2. Let's say I do upgrade eventually, what would be the best way to do it? I have a replication active.

  • 3
    I suggest you wait until 5.7 comes out of beta and a stable version is released, until you upgrade in a production system. The latest (5.7.8) version is still an RC (release candidate). You can of course try to use it (and upgrade) in a test environment. – ypercubeᵀᴹ Sep 16 '15 at 11:11
  • Do the Slave(s) first. – Rick James Sep 16 '15 at 12:55
  • 1
    5.7 is a memory hog, so check the settings. – Rick James Sep 16 '15 at 12:55

As mentioned in the comments, it is not recommended to install any MySQL version (or anything else) that is not 'Generally Available (GA)' in production.

But whether you end up upgrading when it is GA depends on your product and your environment. At the current time, there is this summary of features and improvements introduced in 5.7. In general, if your product is running fine and is relatively static to the point of never needing those features, then you will likely never need to upgrade.

To address the question of how you would upgrade a replication topology from 5.6 to 5.7, there are two main documents to review and familiarize yourself with:

The content of these links will undoubtedly change before 5.7 is GA, but they are extremely important for understanding the incompatible changes and known issues of upgrading so you can avoid them.

I will highlight specifically a change in the way various SHOW commands are handled. The underlying tables for SHOW [GLOBAL|SESSION|LOCAL] STATUS, SHOW [GLOBAL|SESSION|LOCAL] VARIABLES, SHOW SLAVE STATUS are moving from information_schema to performance_schema.

In the current release candidate (5.7.8-rc), access to these performance_schema tables is not enabled by default, and would show an error such as this:

mysql> show global variables like 'hostname';
ERROR 1142 (42000): SELECT command denied to user 'normal_user'@'my_host' for table 'global_variables'

The workaround is to grant SELECT to performance_schema tables for your user. You can read more about the problem and the workaround in this blogpost from Shlomi Noach. This is fixed in 5.7.9, which is not out yet.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.