maria-discuss team mailing list archive

[Arjen Lentz <arjen@xxxxxxxxxxxxx>]

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
> /etc/mysql/conf.d/mysqld_safe_syslog.cnf.
> +# 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?


Regards,
Arjen.
--
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