Description of problem:
mysqlcheck: [ERROR] unknown variable 'process-views=YES' on attempt to perform mysql_upgrade
Version-Release number of selected component (if applicable):
# rpm -qva|grep mariadb
Steps to Reproduce:
1. mysql_upgrade -u root -p
# mysql_upgrade -u root -p
Phase 1/7: Checking and upgrading mysql database
# Connecting to localhost...
# Disconnecting from localhost...
Phase 2/7: Installing used storage engines... Skipped
Phase 3/7: Fixing views
mysqlcheck: [ERROR] unknown variable 'process-views=YES'
FATAL ERROR: Upgrade failed
mysql_upgrade should fix problem that appears to have resulted from upgrading from a previous version.
Sep 14 10:54:11 bwimail01 mysqld: 2018-09-14 10:54:11 140264890173184 [Warning] InnoDB: Table mysql/innodb_table_stats has length mismatch in the column name table_name. Please run mysql_upgrade
# rpm -qf /usr/bin/mysqlcheck
# mysqlcheck --version
mysqlcheck Ver 2.5.1 Distrib 5.7.22, for Linux (x86_64)
Is it possible mysqlcheck-5.7.22 is incompatible with mariadb-10.2.17?
Oh, I see there's an update to community-mysql-5.7.23-1.fc28.x86_64 but it also fails.
It looks like this was the result of some weird dependency that left community-mysql installed and not the top-level mariadb package.
# rpm -e --nodeps community-mysql
# dnf install mariadb
This was perhaps an artifact from a previous upgrade from fc27 or older.
As far as I understand, the issue was in "mysqlcheck" binary, which probably isn't applicable from MariaDB to MySQL and vice versa.
After some package cleanup you managed to get it working as expected.
I will take a brief look at the "mysqlcheck".
A check of version could be implemented in the "mysqlcheck" at the start, to warn user about such issue.
Fedora is - as far as I know - the only place where can be MariaDB and MySQL mixed (nor RHEL, CentOS, Debian, Ubuntu, nor MariaDB nor Oracle upstream packages).
So if you don't feel like contributing a fix to the MariaDB, I think no one will ever take found this as a issue.
If you don't have anything more to this issue, I'll close it as a WONTFIX.
I don't have anything to add other than I'm curious how community-mysql survived through the dependency checks...
(In reply to Alex Regan from comment #5)
> I don't have anything to add other than I'm curious how community-mysql
> survived through the dependency checks...
As I said, in Fedora, I'm trying to keep MariaDB & MySQL cross installable (and cross usable). That means you can use on of those servers with the other client.
The goal is to let user develop and test his application with any combination on the same machine. In the internet the client ussually don't know or care to which release of the server they are connecting, as long as it works - thanks to the same API.
In the package, there are number of utilities, for server and client. While in the client remained mostly utils that are able to connect to the remote host.
mysqlcheck is one of them.
It should be pretty clear now, that this can happen pretty easily.
A fix for this issue could be moving mysqlcheck to the server part.
However since nobody does that (MariaDB or MySQL upstream, Fedora, RHEL, CentOS, Debian, Ubuntu ...) I don't see that as a smart move.
And since Fedora is the only place that can hit this problem - by maintaining unsupported configuration - none of the upstreams would care, I believe.
I added a warning and a link to this bugzilla to the wiki page:
Didn't knew this page? :)