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
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).
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?
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
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.
> 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?
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.
Moving to openstack, since IMHO there is nothing we can do in mariadb 5.5 which is in RHEL-7.
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 ?
Proposing this is currently a dupe of bz#1374296. *** This bug has been marked as a duplicate of bug 1374296 ***