[Mageia-dev] Numerous mariadb issues today.

Colin Guthrie mageia at colin.guthr.ie
Fri Jan 6 14:29:29 CET 2012


'Twas brillig, and Maarten Vanraes at 06/01/12 12:32 did gyre and gimble:
> 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

Ahh yes my my.cnf file didn't have the:

[mysqld_safe]
log-error=/var/log/mysqld/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

bits.

If the default my.cnf file ships with that path (don't know if it does
or if it's patched in our packages) then perhaps the
mysqld-prepare-db-dir script should also be updated to use that as the
default?

>> 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.

OK, cool. As long as it still reads e.g. innodb_* from my.conf then all
will be well I think :)

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

Cool, I'll leave that with you :D

>> 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.

Hmm, I thought I had tried all combinations, but I obviously didn't try
the ha_federatedx.so + federated option... gah, sorry about that. Still
the plugin name in the conf does still need updating, so at least I'm
not completely daft :D

> 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?

There are various things you can do with sed/awk on upgrades... I'd at
very least suggest a "sed -i 's/ha_federated\.so/ha_federatedx\.so/g'
/etc/my.cnf" to fix up that issue (which would prevent mysql starting...
looking back, that was probably the fundamental issue I had.

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

Hmm? innodb was not internal before was it? I thought it was a plugin
since a very long time (I pretty sure I remember panicking when Oden
enabled it for the first time a year or two back). Perhaps I'm wrong tho'.


If you do make xtradb a plugin, then I'd suggest doing a "sed -i
's/ha_innodb\.so/ha_xtradb\.so/g' m/etc/my.cnf" in the %post also.


> 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?

It doesn't. It mentions ha_federated.so as mentioned above rather than
ha_federatedx.so, so this needs to be fixed. This is on x86_64 but I
guess that doesn't matter here.

> 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?

I did get the popup, but of course as the ha_federated.so thing was the
same, this is probably why I ran into trouble.

Cheers

Col

-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/


More information about the Mageia-dev mailing list