'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/
