maria-discuss team mailing list archive
Mailing list archive
Re: Bundle more relevant cnf files in MariaDB package
thanks for your reply, excellent feedback!
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-
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
adjust it further .
The sample is not usable in this form on Windows (and neither on
distributions), mainly due to hardcoded paths
+pid-file = /var/run/mysqld/mysqld.pid
+basedir = /usr
+tmpdir = /tmp
+language = /usr/share/mysql/english
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
them anyway with compile-time settings. Also, tmpdir has already a
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
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
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/
+# 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
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
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
And a merely provocative question : if those parameters(mainly
the sane universally useful baseline values, why not have them
mysqld instead of current defaults? Than we won't need a config file
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
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
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