[MDEV-11032] mysql_upgrade fails after upgrade to 10.1.18-1 Created: 2016-10-11  Updated: 2016-10-12  Resolved: 2016-10-12

Status: Closed
Project: MariaDB Server
Component/s: Scripts & Clients
Affects Version/s: 10.1.18
Fix Version/s: N/A

Type: Bug Priority: Minor
Reporter: Elliot Johnson Assignee: Unassigned
Resolution: Not a Bug Votes: 0
Labels: upgrade
Environment:

CentOS 7
3.10.0-327.28.3.el7.x86_64

MariaDB: 10.1.18-MariaDB MariaDB Server



 Description   

Hello,

I have just upgraded our MariaDB server 10.1.17 to 10.1.18 and routinely ran the mysql_upgrade script. I am receiving the following:

"
[root@svr-h000239 databases]# mysql_upgrade -u root -p
Enter password:
Phase 1/6: Checking and upgrading mysql database
Processing databases
mysql
mysql.column_stats OK
mysql.columns_priv OK
mysql.db OK
mysql.event OK
mysql.func OK
mysql.gtid_slave_pos OK
mysql.help_category OK
mysql.help_keyword OK
mysql.help_relation OK
mysql.help_topic OK
mysql.host OK
mysql.index_stats OK
mysql.innodb_index_stats OK
mysql.innodb_table_stats OK
mysql.plugin OK
mysql.proc OK
mysql.procs_priv OK
mysql.proxies_priv OK
mysql.roles_mapping OK
mysql.servers OK
mysql.table_stats 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
Phase 2/6: Fixing views
Phase 3/6: Running 'mysql_fix_privilege_tables'
ERROR 13 (HY000) at line 286: Can't get stat of './mysql/general_log.CSV' (Errcode: 2 "No such file or directory")
ERROR 13 (HY000) at line 297: Can't get stat of './mysql/slow_log.CSV' (Errcode: 2 "No such file or directory")
ERROR 13 (HY000) at line 299: Can't get stat of './mysql/slow_log.CSV' (Errcode: 2 "No such file or directory")
ERROR 13 (HY000) at line 301: Can't get stat of './mysql/slow_log.CSV' (Errcode: 2 "No such file or directory")
FATAL ERROR: Upgrade failed
[root@svr-h000239 databases]#
"

I have tried:

  • Running the mysql_upgrade script from the parent directory of my /mysql/ folder.
  • Creating the slow_log.CSV and general_log.CSV files (they didn't exist before) and setting appropriate privileges for mysql user.
  • Restarting MariaDB service.

Regardless of these actions, I still get a failed upgrade result.

Can't say I've ever seen this before following previous MariaDB upgrades.



 Comments   
Comment by Elena Stepanova [ 2016-10-11 ]

This is very strange that general_log.CSV and slow_log.CSV did not exist, do you know how it happened? Did somebody remove them manually?
Did general_log.frm and slow_log.frm files exist?
The most likely reason for the problem is that due to the disappearance of CSV files, the tables were left in an inconsistent state.
You can try to do the following:

# Make sure there are no remains of the table
- rm ./mysql/general_log.* ./mysql/slow_log.*
# connect to the server and run
[MariaDB]> FLUSH TABLES;
# Then re-run 
mysql_upgrade -uroot -p --force 

It should work unless somebody previously tried to convert general_log and slow_log tables into InnoDB, in this case things can be a bit more complicated.

Comment by Elliot Johnson [ 2016-10-12 ]

Hi,

Thanks for the response.

There's only myself who manages the MariaDB service on this server (or who even has root access), so I don't suspect any one else has been messing around - i.e.: trying to convert to InnoDB.

My MariaDB configuration has slow_query_log and general_log disabled, so should these files even exist anyway? We would only enable them for troubleshooting (this is a Magento production server).

I will try and move the files you mentioned to /tmp/ and observe the outcome.

Regards,

Elliot

Comment by Elliot Johnson [ 2016-10-12 ]

Hello again,

I moved the following files to /tmp/:
general_log.CSM
general_log.frm
slow_log.CSM
slow_log.frm

and flushed the tables as per your suggestion and the mysql_upgrade went through fine. Yipee!

Obviously this doesn't look like a bug then, but more to do with something weird at my end regarding the existence of the *.CSV files.

Thank you very much for your time and assistance.

Best Regards,

Elliot

Comment by Elliot Johnson [ 2016-10-12 ]

Heh, feeling like a bit of an idiot, but how do I close this ticket/issue now?

Thank you!

Elliot

Comment by Elena Stepanova [ 2016-10-12 ]

Closing is our duty, don't worry about that.
There can still be a problem if the files disappeared on their own – answering your previous question, yes, the files should exist even if you don't use the logging tables. They would be empty, but they should be there. They must be there now again, after the successful run of mysql_upgrade.

So, if you notice that the files disappeared again without your doing anything for it, please feel free to comment on this issue (it will be possible even after closing) or to create a new one.

Comment by Elliot Johnson [ 2016-10-12 ]

Okay, cool.

Well I can confirm that the three general_log.* and slow_log.* files now exist on my system, so I will keep an eye on them.

Thank you.

Best Regards,

Elliot

Generated at Thu Feb 08 07:46:47 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.