my.cnf not symlinked to /etc/mysql/percona-xtradb-cluster.cnf after upgrading to bionic

Bug #1900178 reported by Andrea Ieri
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Percona Cluster Charm
New
Undecided
Unassigned

Bug Description

I have upgraded a percona 3-node cluster from trusty to xenial and from xenial to bionic.

The first upgrade appeared to complete successfully, while the one to bionic failed completely.

These are the symptoms I have observed:

* the post-series-upgrade hook hit bug 1838041. I worked around it by simply commenting out the subprocess call to mysql_upgrade:

441 # Execute the upgrade process
442 log("Running mysql_upgrade")
443 cmd = ['mysql_upgrade']
444 if _release == "xenial":
445 cmd.append('-p{}'.format(root_password()))
446 #subprocess.check_call(cmd)

* the update-alternatives entry for my.cnf was making /etc/mysql/my.cnf point to /etc/mysql/my.cnf.migrated, and not to /etc/mysql/percona-xtradb-cluster.cnf. As a consequence, config-changed hooks were rendering configurations that were never being picked up by mysqld

The update-alternatives setup is performed in the post-series-upgrade hook when upgrading to xenial:

458 if _release == "xenial":
459 # Point at the correct my.cnf
460 cmd = ["update-alternatives", "--set", "my.cnf",
461 "/etc/mysql/percona-xtradb-cluster.cnf"]
462 subprocess.check_call(cmd)

I do not know if this wasn't run when I transitioned from trusty to xenial, or if it got undone when upgrading to bionic, but it surely made the upgrade process very difficult to debug.

Charm version used: 291

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.