From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/2012-January/011030.html | 277 ++++++++++++++++++++++++++++ 1 file changed, 277 insertions(+) create mode 100644 zarb-ml/mageia-dev/2012-January/011030.html (limited to 'zarb-ml/mageia-dev/2012-January/011030.html') diff --git a/zarb-ml/mageia-dev/2012-January/011030.html b/zarb-ml/mageia-dev/2012-January/011030.html new file mode 100644 index 000000000..78289e7de --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011030.html @@ -0,0 +1,277 @@ + + + + [Mageia-dev] Numerous mariadb issues today. + + + + + + + + + +

[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
+ -- cgit v1.2.1