[Mageia-dev] Numerous mariadb issues today.

[Maarten Vanraes]

Op vrijdag 06 januari 2012 11:21:44 schreef Colin Guthrie:
> Hi,
> 
> There are several problems today with mariadb, some more serious than
> others:
> 
> Firstly, (a minor problem) the log file:
> Jan  3 14:04:34 jimmy mysqld_safe[10642]: 120103 14:04:34 mysqld_safe
> Logging to '/var/log/mysqld/mysqld.log'.
> Jan  3 14:04:34 jimmy mysqld_safe[10642]: 120103 14:04:34 mysqld_safe
> Starting mysqld daemon with databases from /var/lib/mysql
> Jan  3 14:05:53 jimmy mysqld-prepare-db-dir[11245]: touch: cannot touch
> `/var/log/mysqld.log': Permission denied
> Jan  3 14:05:53 jimmy mysqld-prepare-db-dir[11245]: chown: cannot access
> `/var/log/mysqld.log': No such file or directory
> Jan  3 14:05:53 jimmy mysqld-prepare-db-dir[11245]: chmod: cannot access
> `/var/log/mysqld.log': No such file or directory
> 
> As the script is run as the mysql user, it cannot touch the
> (non-existant) log file as the directory is owned by root. Better to do
> this in a %post script to ensure the file is all present and properly
> owned to avoid this error.

that is strange, this was an error that also mysql has had since ages; and i 
fixed for both mysql and mariadb in cauldron, are you using an older my.cnf?
this error was there before and is non-fatal iirc. however, newer my.cnf files 
should have the correct path
 
> Secondly, several plugins were moved to mariadb-obsolete. I have most of
> my databases stored in innodb format and this was one of the plugins
> moved over. Even when I did install the -obsolete package to get
> ha_innodb back, I couldn't use it:
> 
> 120106 10:15:02 Percona XtraDB (http://www.percona.com) 1.1.8-20.1
> started; log sequence number 52870027141
> 120106 10:15:02 [ERROR] Function 'InnoDB' already exists
> 120106 10:15:02 [ERROR] Couldn't load plugin named 'InnoDB' with soname
> 'ha_innodb.so'.
> 
> Now I believe this is due to XtraDB duplicating the features of InnoDB
> and thus effectively obsoleting it... does this mean I simply shouldn't
> load InnoDB plugin now? Does it mean all the tweaks I made in my.cnf for
> innodb pool sizes etc. now no longer work? What is the fallout from this
> change?

indeed you shouldn't use the -obsolete ones, the xtradb should nicely use your 
innodb database, xtradb is a innodb with extra patches, so any innodb tuning 
is still valid for xtradb.

otoh, loading the ha_innodb.so should overwrite the internal xtradb code, so 
i'll have to see why this isn't working.


> Thirdly, federated was changed to fedaratedx, but federated was still
> shipped in the mariadb-obsolete package... Sadly however the default
> my.cnf still tries to load the ha_federated.so by default and activate
> via a "federated" option in default my.cnf. So not only is a plugin
> activated that is not installed, even when you do install
> mariadb-obsolete, the "federated" option seems to no longer work anyway:
> 
> 120106 10:14:16 [ERROR] /usr/sbin/mysqld: unknown option '--federated'
> 
> So the "federated" option and the plugin load itself in my.cnf needs to
> be updated somehow, both in the default my.cnf but also some attempt
> should be made to update existing my.cnf too (with a backup).

only the load plugin should be changed into federatedx.so instead of 
federated.so ; the "federated" option is still valid for federatedx

getting this error, means that you don't have any of them both loaded.

sadly, my.cnf is a config file, i can provide a newer my.cnf all i want, it's 
not like i can modify the my.cnf file for existing upgrades?


my thoughts on plugins is: "xtradb is internal, because innodb was internal; 
federatedx was external, because federated was external"

can you recheck that a new my.cnf file at the very least works out of the box? 
and is this x86_64 or i586?

i'm not sure yet as how to do the upgrade to newer my.cnf other than maybe add 
this to errata and maybe README.install.urpmi

but, if you install using rpmdrake, didn't you get a popup box with the my.cnf 
differences?