From your description in the blog, you re-used the old datadir remaining from 5.5, but didn't run mysql_upgrade after installing 10.0.3. If you check the error log, you're likely to see a number of errors caused by that. Please run mysql_upgrade and restart the server.

elenst I still think that SHOW VARIABLES as a whole should not fail, if there's a error reading a value of a specific variable, it should affect only that variable.

serg Right, and there is also a question why even after mysql_upgrade it requires restarting the server. So far I'm just trying to provide a workaround so John could proceed with his testing.

In regard to affecting only the "bad" variable, I'm not sure if we have the mechanism in place, do we? How would it look in show variables output?

Upd: maybe showing the variable value as NULL and throwing a warning on SHOW VARIABLES would do.

Hi Kristian,

So there are two questions / problems in here:

1) is it possible not to fail the whole "SHOW VARIABLES" query when gtid position cannot be read on whatever reason?

2) it seems wrong that SHOW VARIABLES keeps failing even after mysql_upgrade, until the server is restarted, is it possible to avoid that? Usually the server becomes functional right after mysql_upgrade, although there are cases when restart is needed (e.g. when event scheduler fails on startup). I hope GTID is not one of such cases.

Hello,
Valid point with mysql_upgrade I have no clue why I didn't do that.
The problem did still exist after just mysql_upgrade but gone after the restart after the mysql_upgrade..

[root@Fedora64 src]# /etc/init.d/mysql restart
Shutting down MySQL... SUCCESS!
Starting MySQL.... SUCCESS!
[root@Fedora64 src]# mysql
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 3
Server version: 10.0.3-MariaDB MariaDB Server

Copyright (c) 2000, 2013, Oracle, Monty Program Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> show variables;
ERROR 1946 (HY000): Failed to load replication slave GTID position from table mysql.gtid_slave_pos
MariaDB [(none)]> exit
Bye
[root@Fedora64 src]# mysql_upgrade
Phase 1/3: Fixing table and database names
Phase 2/3: Checking and upgrading tables
Processing databases
Start_Of_Demo
incremental_1
incremental_2
information_schema
mysql
mysql.columns_priv OK
mysql.db OK
mysql.event OK
mysql.func OK
mysql.help_category OK
mysql.help_keyword OK
mysql.help_relation OK
mysql.help_topic OK
mysql.host OK
mysql.ndb_binlog_index OK
mysql.plugin OK
mysql.proc OK
mysql.procs_priv OK
mysql.proxies_priv OK
mysql.servers OK
mysql.tables_priv OK
mysql.time_zone OK
mysql.time_zone_leap_second OK
mysql.time_zone_name OK
mysql.time_zone_transition OK
mysql.time_zone_transition_type OK
mysql.user OK
performance_schema
world
world.City OK
world.Country OK
world.CountryLanguage OK
Phase 3/3: Running 'mysql_fix_privilege_tables'...
OK
[root@Fedora64 src]# mysql
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 10
Server version: 10.0.3-MariaDB MariaDB Server

Copyright (c) 2000, 2013, Oracle, Monty Program Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> show variables;
ERROR 1946 (HY000): Failed to load replication slave GTID position from table mysql.gtid_slave_pos
MariaDB [(none)]>

MariaDB [(none)]> show variables;
....
469 rows in set (0.02 sec)

MariaDB [(none)]> show variables like 'g%';
----------------------------------+

----------------------------------+

----------------------------------+
9 rows in set (0.00 sec)

I have updated the blog and point your solution and my mistake out as well.

Pushed to 10.0-base.

Revision: revid:knielsen@knielsen-hq.org-20130826105109-fuzmdpnn6k93nf0k

When trying to set the variables, it will first try again to reload the table, and succeed if it had been restored with mysql_upgrade.

When trying to read the variable we cannot easily retry loading the table due to table locking issues if done from a SELECT eg. But I made such cases return the empty string (the value will be empty if the table is not there, and we've already complained about the table in the error log anyway).