...

Am 20.12.2013 13:22, schrieb Frank Röhm:

...

day before yesterday I updated my MySQL Server 5.5.34 to MariaDB 5.5.34 on my Ubuntu 12.04 Server.

All went fine but next day, I noticed that the automatic backup script (automysqlbackup) had errors, I read:

mysqldump: Couldn't execute 'SELECT /*!40001 SQL_NO_CACHE */ * FROM `EVENTS`': Cannot proceed because system tables used by Event Scheduler were found damaged at server start (1577) mysqldump: Couldn't execute 'show events': Cannot proceed because system tables used by Event Scheduler were found damaged at server start (1577)

looks like you *did not* run "mysql_upgrade -u root -p" after the migration! you should do this after *any* mysql/mariadb update directly after the service was restarted to prevent from hidden *serious* problems like root not allowed to use several grant-commands because missing columns in the permission tables and such nasty things

You are right, I did the mysql_upgrade only the next day after I noticed this issue and after a research about it.

What can I do now? Can I play back the information_schema db or ist this not a solution?

And when I had done a mysql_upgrade command the next day, I got this: This installation of MySQL is already upgraded to 5.5.34-MariaDB, use --force if you still need to run mysql_upgrade I guess that means, that this command was already done by the installer (aptitude). Anyway I haven't read in any of the many MySQL to MariaDB Upgrade documentations that this command is needed. Could it be an incompatibility?

i would make a backup of the datadir, delete the database and use "mysql_upgrade --force" after that because this database don't contain any persistent data and should be automatically created

I cannot delete it, Access denied! I did on the commandline as root: MariaDB [(none)]> DROP DATABASE information_schema; ERROR 1044 (42000): Access denied for user 'root'@'localhost' to database 'information_schema' But a look into my permissions, I get all 'Y' for: SELECT * FROM mysql.`user` u where User = 'root' So I think I have a big problem now, havent I? All databases of my applications on this server might work at the moment, but I think it is a question of time, till I run into a severe problem, with this issue. I want to fix this.

before using that big hammer try "mysql_upgrade -u root -p --force" and restart the service after that, maybe that's enough

This was the first thing I had done, after mariadb told me, that I have to use --force, but without any change.

Am 20.12.2013 um 20:28 schrieb Reindl Harald:

i thought more about

* stop server * backup datadir * delete the db-folder from filesystem

There is no folder for information_schema. "They are actually views, not base tables, so there are no files associated with them... Also, there is no database directory with that name."

From http://dev.mysql.com/doc/refman/5.5/en/information-schema.html

before trying this try i "repair table" on any table in this meta-db! This still doesn't work because I still have no rights: Access denied for user 'root'@'localhost' to database 'information_schema'

the following command may do the same easier mysqlcheck -h localhost --check-upgrade --all-databases --auto-repair --user=root -p

No change.

what maybe interesting to post

* stop mysqld * make the mysqld-log empty * start mysqld * post the complete output of the mysqld-log

I didn't find the mysqld-log, the files /var/log/mysql.log and mysql.err are empty. So I set (uncommented) in my.cnf general_log_file = /var/log/mysql/mysql.log general_log = 1 and now I get here, when I start mysql: /usr/sbin/mysqld, Version: 5.5.34-MariaDB-1~precise-log (mariadb.org binary distribution). started with: Tcp port: 3306 Unix socket: /var/run/mysqld/mysqld.sock Time Id Command Argument Not very interesting. But I found in the syslog since yesterday noon every 2 minutes (!!!) these entries: Dec 19 12:02:12 myserver kernel: [1315576.363594] init: mysql main process (9025) terminated with status 1 Dec 19 12:02:12 myserver kernel: [1315576.363659] init: mysql main process ended, respawning Dec 19 12:02:12 myserver /etc/mysql/debian-start[10200]: Upgrading MySQL tables if necessary. Dec 19 12:02:12 myserver /etc/mysql/debian-start[10203]: /usr/bin/mysql_upgrade: the '--basedir' option is always ignored Dec 19 12:02:12 myserver /etc/mysql/debian-start[10203]: Looking for 'mysql' as: /usr/bin/mysql Dec 19 12:02:12 myserver /etc/mysql/debian-start[10203]: Looking for 'mysqlcheck' as: /usr/bin/mysqlcheck Dec 19 12:02:12 myserver /etc/mysql/debian-start[10203]: This installation of MySQL is already upgraded to 5.5.34-MariaDB, use --force if you still need to run mysql_upgrade Dec 19 12:02:12 myserver /etc/mysql/debian-start[10214]: Checking for insecure root accounts. Dec 19 12:02:12 myserver /etc/mysql/debian-start[10219]: Triggering myisam-recover for all MyISAM tables (I replaced my server's name with myserver) Do I understand this right, that every 2 minutes mysql server is crashing (terminated with status 1)??? I don't find a hint in the syslog what could crash mysql. And to restart mysql (service mysql restart) it takes about a minute! This seems unnormal too. I think I have a problem. This is my my.cnf: [client] port = 3306 socket = /var/run/mysqld/mysqld.sock [mysqld_safe] socket = /var/run/mysqld/mysqld.sock nice = 0 [mysqld] user = mysql pid-file = /var/run/mysqld/mysqld.pid socket = /var/run/mysqld/mysqld.sock port = 3306 basedir = /usr datadir = /var/lib/mysql tmpdir = /tmp lc-messages-dir = /usr/share/mysql skip-external-locking bind-address = 127.0.0.1 character-set-server=utf8 collation-server=utf8_general_ci key_buffer = 16M max_allowed_packet = 16M thread_stack = 192K thread_cache_size = 8 myisam-recover = BACKUP query_cache_limit = 1M query_cache_size = 16M expire_logs_days = 10 max_binlog_size = 100M innodb_file_per_table [mysqldump] quick quote-names max_allowed_packet = 16M events ignore-table=mysql.events [mysql] [isamchk] key_buffer = 16M !includedir /etc/mysql/conf.d/