← Back to team overview

maria-discuss team mailing list archive

Re: Bundle more relevant cnf files in MariaDB package


Hi Vladislav

thanks for your reply, excellent feedback!
comments below.

As promised, I've fixed up a 5.2 branch to get rid of the old
troublesome config files, and replaced them with the single baseline
sample config - also any references in the build environment and in-
tree documentation.

See https://code.launchpad.net/~arjen-lentz/maria/5.2- zapoldsamplecnfs
also proposed for merging.
The baseline example I've used comes from the MariaDB DEB (Debian/
Ubuntu) packaging, and we can adjust it further.

If this should be used more than just on Linux or Debian/Ubuntu, we need to
adjust it further .
The sample is not usable in this form on Windows (and neither on tar.gz
distributions), mainly due to hardcoded paths
+pid-file	= /var/run/mysqld/mysqld.pid
+basedir		= /usr
+tmpdir		= /tmp
+language	= /usr/share/mysql/english
+!includedir /etc/mysql/conf.d/
Yet, it is used on Windows as my-example.ini, and in tar.gz as
my-example.cnf. My question is : why hardcoding paths, you can influence them anyway with compile-time settings. Also, tmpdir has already a sane
default, or has not it?

I think so.

To clarify, the origin of this baseline config is Open Query's daily work. We took to explicitly defining all these aspects, to unbreak things regardless of the build source (binary tarball, RPM, DEB) as they all do things slightly differently (see below) and some distro- builds (e.g. those by RedHat themselves, etc) are different again.

For example, one particular aspect we ran in to was that the relay log files in a very indirect way derive their path from the configured socket directory setting, this made them end up on /var/run/mysqld on Ubuntu. The consequence was that on reboot, a replication slave would break as /var/run is a tmpfs. This was a bug (yuo can find it in the MySQL bug system and in Open Query's blog and quite a few other places), and the most effective way for resolving this was specifying all the paths explicitly, to not rely on an underlying code being fixed. Again, it's possible to fix this in the MariaDB code base, but it's not entirely trivial because of the indirectness when you look at the code. We'd need to ensure that all paths would indeed end up correct on all platforms we build for. That's entirely doable and I suppose we could have mysql-test cases that check the output of these aspects of SHOW GLOBAL VARIABLES.

This won't do it either on Windows:
+innodb_flush_method	= O_DIRECT

Also, lot of unixism is in the comments
+# Error logging goes to syslog due to
+# InnoDB is enabled by default with a 10MB datafile in /var/lib/ mysql/.
+#   The files must end with '.cnf', otherwise they'll be ignored.
+# Read the manual, too, if you want chroot!
+# Remember to edit /etc/mysql/debian.cnf when changing the socket location.

true since it was derived from that environment.
It's a vast improvement over what was there before, but I won't pretend for a minute that it's perfect. The above is just comment text and thus harmless - naturally further improvements would be great!

Is there a need to repeat  compiled-in defaults?
+socket		= @MYSQL_UNIX_ADDR@
+port		= @MYSQL_TCP_PORT@

Not as such. I did the above based on the earlier examples.
My socket was hardcoded to the Debian/Ubuntu layout, which unfortunately is different from the RPM layout which is different from the binary tarball layout. And guess what, the source build is different again ;-) Socket you may find in /var/run/mysqld/ or /var/lib/mysql or /tmp, and elsewhere.

Indeed if the compiled-in default is correct, it'll work ok.
Unfortunately, in the past we've had the situation where the defaults in the RPMs from mysql.com and Red Hat themselves did not match up with each other and the expected config on Red Hat environments, so a config file was essential to not break things in case of an upgrade in any direction.

And a merely provocative question : if those parameters(mainly numbers) are the sane universally useful baseline values, why not have them compiled into mysqld instead of current defaults? Than we won't need a config file at all.

I can agree with that logic, and since MariaDB does its own packaging now that could be an excellent solution that also resolves many if not all of the other issues you raised with the baseline config.

So, Vlad, I'm all for what you suggest! excellent stuff.
But here's the thing. What you suggest requires quite a bit more work by various people, and that'll take time.
So I'm suggesting a multi-step process.
The old my-*.cnf files are nasty and cause a lot of hassle, so I believe it's very important to get rid of them.

We can certainly strip or comment out items in the new my-example.cnf to make sure it works on all platforms, or find a way to have a single source file from which *different* platform specific examples are generated. I was actually quite surprised to find that a .sh shell script is still used for preparing the Windows build environment!

Of course, in the stock mysql.com you have the config wizard that takes care of creating a baseline config. I'm not sure what the current setup is for MariaDB and its Windows installer... but perhaps somewhere along there we can resolve that separately. Since Windows is not a *nix, all the paths are different. All other platforms are *nix based. Right?

Arjen Lentz, Exec.Director @ Open Query (http://openquery.com)
Remote expertise & maintenance for MySQL/MariaDB server environments.

Follow us at http://openquery.com/blog/ & http://twitter.com/openquery

Follow ups