do-release-upgrade from Ubuntu 14.04 to 16.04.1 performs unsupported upgrade from MySQL 5.5 to 5.7

Bug #1725222 reported by Marco Marsala
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ubuntu Server Guide
Invalid
Undecided
Unassigned
mysql-5.7 (Ubuntu)
Invalid
High
Unassigned
ubuntu-release-upgrader (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Updating from Ubuntu 14.04 to Ubuntu 16.04.1 using do-release-upgrade will cause troubles because MySQL is upgraded from 5.5 to 5.7, that is an unsupported update path, as per MySQL official documentation.

Your script should do these pre-checks and prevent upgrade, or automatically solve the issue before applying upgrade.

PS: the solution is to upgrade MySQL in two steps, first from 5.5 to 5.6 then from 5.6 to 5.7.

Tags: mysql
Revision history for this message
Doug Smythies (dsmythies) wrote :

Thanks for taking the time to join launchpad and submitting a bug report.
However, I don't think this is a serverguide problem. I don't know what is should be set to.

Changed in serverguide:
status: New → Incomplete
Revision history for this message
Marco Marsala (marcomarsala) wrote :

Sorry, I didn't fully understand your reply. Many users are facing the same issue.

Ubuntu 14.04 is shipped with MySQL 5.5.
Running do-release-upgrade on such installation will break the system, because the script upgrades to MySQL 5.7, that is an unsupported upgrade, as per official MySQL documentation.

You should fix the script or point out this in the documentation.

Revision history for this message
Doug Smythies (dsmythies) wrote :

Well, according to this:
https://wiki.ubuntu.com/Bugs/FindRightPackage#When_upgrading_Ubuntu_.28or_derivatives.29
the related package is: ubuntu-release-upgrader
so adding it.

We will not add a special note about this in the serverguide.

Changed in serverguide:
status: Incomplete → Invalid
Revision history for this message
Gunnar Hjalmarsson (gunnarhj) wrote :

Possibly this is related:

https://wiki.ubuntu.com/XenialXerus/ReleaseNotes#MySQL_5.7

My belief is that ubuntu-release-upgrader can't handle this kind of issue in a specific application. One way might be some kind of maintainer script in the mysql-5.7 package.

Revision history for this message
Marco Marsala (marcomarsala) wrote :

Such maintainer script should perform the upgrade as recommended by MySQL developers, so stepping one version a time; so, upgrading for example, from Ubuntu 14 to 16, it should upgrade MySQL 5.5 to 5.6, then 5.6 to 5.7.

Revision history for this message
Marco Marsala (marcomarsala) wrote :
Revision history for this message
Gunnar Hjalmarsson (gunnarhj) wrote :

I see that bug #1577712 is marked "Fix Released". @Marco, did you actually encounter problems when upgrading from 14.04 to 16.04? If so, can you please elaborate on the nature of the problems?

Revision history for this message
Marco Marsala (marcomarsala) wrote : Re: [Bug 1725222] Re: do-release-upgrade from Ubuntu 14.04 to 16.04.1 performs unsupported upgrade from MySQL 5.5 to 5.7

Yes I still experience the issue.

The problem described in #1577712 is not the only problem I experienced. Upgrading from 14.04 to 16.04.1 with do-release-upgrade break MySQL, we reproduced the same issue every time on many clean 14.04 installations. do-release-upgrade hangs on the post installation script for MySQL.

It seems the issue is upgrading directly from 5.5 to 5.7 is not supported, doing that (even manually) will hang on mysql_upgrade in many cases. Official MySQL documentation says: “Upgrade that skips versions is not supported. For example, upgrading directly from MySQL 5.5 to 5.7 is not supported.” - https://dev.mysql.com/doc/refman/5.7/en/upgrading.html#upgrade-paths
It may *seems* to work if you have only empty databases, but when we used it on production databases, with many data, it hung when it encountered features removed in 5.7, and you will have corrupted data (for example DATETIME fields with 0 default value, or the default SYS schema is missing version information).

MM

_____________________________
From: Gunnar Hjalmarsson <<email address hidden><mailto:<email address hidden>>>
Sent: martedì, ottobre 24, 2017 1:51 PM
Subject: [Bug 1725222] Re: do-release-upgrade from Ubuntu 14.04 to 16.04.1 performs unsupported upgrade from MySQL 5.5 to 5.7
To: <<email address hidden><mailto:<email address hidden>>>

I see that bug #1577712 is marked "Fix Released". @Marco, did you
actually encounter problems when upgrading from 14.04 to 16.04? If so,
can you please elaborate on the nature of the problems?

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/1725222

Title:
do-release-upgrade from Ubuntu 14.04 to 16.04.1 performs unsupported
upgrade from MySQL 5.5 to 5.7

Status in Ubuntu Server Guide:
Invalid
Status in mysql-5.7 package in Ubuntu:
New
Status in ubuntu-release-upgrader package in Ubuntu:
New

Bug description:
Updating from Ubuntu 14.04 to Ubuntu 16.04.1 using do-release-upgrade
will cause troubles because MySQL is upgraded from 5.5 to 5.7, that is
an unsupported update path, as per MySQL official documentation.

Your script should do these pre-checks and prevent upgrade, or
automatically solve the issue before applying upgrade.

PS: the solution is to upgrade MySQL in two steps, first from 5.5 to
5.6 then from 5.6 to 5.7.

To manage notifications about this bug go to:
https://bugs.launchpad.net/serverguide/+bug/1725222/+subscriptions

Revision history for this message
Gunnar Hjalmarsson (gunnarhj) wrote :

Thanks Marco.

@Robie: Since you worked with bug #1577712, I subscribed you to this one. Can you please take a look.

Changed in mysql-5.7 (Ubuntu):
importance: Undecided → High
Revision history for this message
Robie Basak (racb) wrote :

I believe this was discussed at the time with MySQL upstream. Although the 5.5 to 5.7 upgrade isn't an officially supported upgrade path by upstream, I think when we discussed it we concluded that it would be fine for moving a default installation of MySQL 5.5 as packaged in 14.04 on to 16.04.

I don't think we can treat this as a bug unless you can demonstrate a specific case that doesn't work. If you can provide a broken case, we can consider what needs doing about it then. Until then, I don't think we can expect to make any progress on a hypothetical problem.

Changed in mysql-5.7 (Ubuntu):
status: New → Incomplete
Changed in ubuntu-release-upgrader (Ubuntu):
status: New → Incomplete
Revision history for this message
Marco Marsala (marcomarsala) wrote :

@racb I really had many failed mysql upgrades and the title of my report hypothesizes the root cause of the issue, but I may be wrong, in fact seems bug #1577712 is back, @gunnarhj @racb see the last comment.

Revision history for this message
Marco Marsala (marcomarsala) wrote :

Other issues I faced are:

- issues with DATETIME fields with '0000-00-00 00:00:00' default value;
- Event scheduler disabled after the upgrade.

Revision history for this message
Marco Marsala (marcomarsala) wrote :

Seems they identified the issue causing the upgrade to fail: https://support.plesk.com/hc/en-us/articles/115003430813#_=_

Revision history for this message
Gunnar Hjalmarsson (gunnarhj) wrote :

On 2017-11-09 18:51, Marco Marsala wrote:
> Seems they identified the issue causing the upgrade to fail:
> https://support.plesk.com/hc/en-us/articles/115003430813#_=_

If that simple fix prevents the problem, maybe a patch would be motivated?

Revision history for this message
Marco Marsala (marcomarsala) wrote :

Yes because no one know that. Without such patch, system upgrades cannot be automated and will be relegated to experienced users.

Revision history for this message
Gunnar Hjalmarsson (gunnarhj) wrote :

Sufficient input, Robie?

Changed in mysql-5.7 (Ubuntu):
status: Incomplete → New
Changed in ubuntu-release-upgrader (Ubuntu):
status: Incomplete → New
Revision history for this message
Robie Basak (racb) wrote :

> Seems they identified the issue causing the upgrade to fail: https://support.plesk.com/hc/en-us/articles/115003430813#_=_

So it looks like the configuration option innodb_additional_mem_pool_size was valid in MySQL 5.5 but is no longer valid in MySQL 5.7? AFAICT, that configuration option was not shipped in any packaging previously. Is the problem that for users who have customised their system configurations with this option (or for example some third party tool has done it), a subsequent release upgrade to 5.7 will fail?

See bug 1571865. Upstream does not provide a script which can automatically convert every single possible configuration customisation in MySQL 5.5 with an updated equivalent version in MySQL 5.7. So distributions cannot reasonably be expected to be able to provide such an automated upgrade path either. This is standard behaviour across all distributions I believe. Distributions allow you (or a third party working on your behalf) to customise your installations to the extreme. However, there is no practical automatic upgrade path that works in all cases and can be provided when upstream semantics change in a release upgrade.

So I cannot consider this to really be a bug in MySQL packaging.

If, separately, you want to provide a smoother upgrade path in a maintainer script for a specific customisation, then we'll happily accept that patch. Providing that the patch can be shown to likely not make anything worse in any possible use case. If you want to do this, then please file a specific bug for the specific customisation (or set of customisations) upgrade path you want to fix. Please don't use a generic "it doesn't work" bug like this one has become as that just results in confusion with all of the "me too" people involved in this bug who may be affected by the general issue but not your particular and specific customisation.

Changed in mysql-5.7 (Ubuntu):
status: New → Invalid
Changed in ubuntu-release-upgrader (Ubuntu):
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.