Bug 1341968 - When upgrading galera from mariadb-5.5.47-1.el7_2.x86_64 to mariadb-10.1.12-4.el7.x86_64.rpm rpm scriptlet hangs
Summary: When upgrading galera from mariadb-5.5.47-1.el7_2.x86_64 to mariadb-10.1.12-...
Keywords:
Status: CLOSED DUPLICATE of bug 1374296
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: mariadb-galera
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: 5.0 (RHEL 7)
Assignee: Damien Ciabrini
QA Contact: Udi Shkalim
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-06-02 07:38 UTC by Michele Baldessari
Modified: 2016-11-07 20:00 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-11-07 20:00:38 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Michele Baldessari 2016-06-02 07:38:53 UTC
Description of problem:
As discussed with dciabrin, am filing it here

While testing liberty -> mitaka upgrades we upgrade mariadb on the undercloud
from 5.5.47-1 to 10.1.12-4. The yum upgrade -y command ends up being stuck
in systemctl try-restart mariadb

root       880  0.0  0.0 128404  1232 pts/1    S+   03:34   0:00  |                       \_ systemctl try-restart mariadb.service
stack     1286  0.0  0.0 112648   944 pts/2    S+   03:35   0:00              \_ grep --color=auto -E mysql|maria|systemctl
mysql    12766  0.0  0.0 113252  1536 ?        Ss   02:53   0:00 /bin/sh /usr/bin/mysqld_safe --basedir=/usr
mysql    13293  3.6  3.3 1582380 332824 ?      Sl   02:53   1:32  \_ /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --log-error=/var/log/mariadb/mariadb.log --open-files-limit=-1 --pid-file=/var/run/mariadb/mariadb.pid --socket=/var/lib/mysql/mysql.sock --port=3306

Comment 2 Honza Horak 2016-06-02 09:23:19 UTC
Which builds are you using for mariadb-10.1.12-4? The only supported version of mariadb is the build from RHSCL -- rh-mariadb101-mariadb-10.1.14-2.el7 (released two days back).

Comment 3 Michele Baldessari 2016-06-02 09:49:55 UTC
Hi Honza,

yes it might be that it makes sense to move this to some centos tracker or something. I had chatted with dciabrin and we thought of starting here merely
for tracking purposes (I wasn't entirely sure where to track this tbh).
The builds came from centos/rdo (http://buildlogs.centos.org/centos/7/cloud/x86_64/openstack-mitaka/).

I assume that we won't hit this unless we upgrade the very same mariadb
package from 5.x to 10.x. I can try reproducing with the RHSCL package,
but I guess that we won't trigger the rpm scriptlet that gets stuck in systemctl
try-restart.

If we never ever plan to update mariadb to 10.x in rhel, I guess it makes sense
to close this down and maybe track it somewhere else. centos tracker?
If we do sometime plan to upgrade mariadb, I think it is worth keeping around,
as I would expect we will hit this issue one way or the other.

Makes sense? Damien, thoughts here?

Comment 4 Damien Ciabrini 2016-06-02 10:02:08 UTC
Honza, when discussing with Michele, it was unclear to us which product to assign this bug, so I'll add a bit of context below.

We're upgrading OpenStack version from liberty to mitaka, and these releases depend on two different major versions of mariadb: 5.5 and 10.1.

The upgrade which is taking place essentially calls "yum upgrade" while mysql is running, and ends up stuck in "systemctl try-restart mariadb.service" when mariadb package is upgraded.

The build of mariadb being used is not rh-mariadb101-mariadb-10.1.14-2.el7, it comes from centos 7 cloud rpms [1], and was built following the specfile from Fedora 24 [2].

Michele, I'll open a ticket in centos to track that upgrade issue.

Honza, I'll try to reproduce the upgrade issue with the package you mentioned, let's see it it triggers the same condition. Meanwhile, do you think we should reassign this bz to another product e.g. Fedora?

[1] http://mirror.centos.org/centos/7/cloud/x86_64/openstack-mitaka/
[2] http://pkgs.fedoraproject.org/cgit/rpms/mariadb.git/commit/?h=f24&id=3699d693bec3fb11273fbc86bc7ccf78a1d92689

Comment 5 Honza Horak 2016-06-02 11:22:49 UTC
If you're using centos builds, it does not make sense to report to Fedora, unless there is the same issue with Fedora builds. You might want to re-assign this bug to OpenStack product instead.

Also, please mind, that the only supported way of upgrading from 5.5 to 10.1 is going through 10.0 as a middle step.

Comment 6 Michael Bayer 2016-06-02 13:41:36 UTC
> Also, please mind, that the only supported way of upgrading from 5.5 to 10.1 is going through 10.0 as a middle step.

Hi Honza -

that's not an option for us.  Do you have any background information on this?  I note from the MariaDB website they don't document running mysql_upgrade for 5.5->10.1, only 5.5->10.0->10.1.  However lots of blogs seem to refer to running mysql_upgrade on a 5.5 database straight to 10.1.

We basically have to decide between a. install 10.1 totally clean and restore from a dumpfile or b. get mysql_upgrade to work on a 5.5 -> 10.1 move.    Do you have any further thoughts on this?

Comment 7 Honza Horak 2016-06-02 14:19:17 UTC
IMO, getting mysql_upgrade to work generally on a 5.5 -> 10.1 might be only a hope -- if upstream could ensure it will work, it would be supported. But maybe, in case of OpenStack, if the data structures were well-known and won't differ between deployments, then it might work (but would require proper testing). Dump/restore seems to be safer.

Comment 8 Honza Horak 2016-06-15 10:53:39 UTC
Moving to openstack, since IMHO there is nothing we can do in mariadb 5.5 which is in RHEL-7.

Comment 9 Michael Bayer 2016-10-07 18:29:12 UTC
was this originally tested in rhel7.3 ?   systemctl shouldn't be used for galera, was the actual symtom here the same thing as bz#1375184 ?

Comment 10 Michael Bayer 2016-11-07 20:00:38 UTC
Proposing this is currently a dupe of bz#1374296.

*** This bug has been marked as a duplicate of bug 1374296 ***


Note You need to log in before you can comment on or make changes to this bug.