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/011029.html | 217 ++++++++++++++++++++++++++++ 1 file changed, 217 insertions(+) create mode 100644 zarb-ml/mageia-dev/2012-January/011029.html (limited to 'zarb-ml/mageia-dev/2012-January/011029.html') diff --git a/zarb-ml/mageia-dev/2012-January/011029.html b/zarb-ml/mageia-dev/2012-January/011029.html new file mode 100644 index 000000000..72f6dc456 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011029.html @@ -0,0 +1,217 @@ + + + + [Mageia-dev] Numerous mariadb issues today. + + + + + + + + + +

[Mageia-dev] Numerous mariadb issues today.

+ Maarten Vanraes + alien at rmail.be +
+ Fri Jan 6 13:32:29 CET 2012 +

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

+ +
+More information about the Mageia-dev +mailing list
+ -- cgit v1.2.1