← Back to team overview

maria-discuss team mailing list archive

Re: Suggested sample my.cnf for MariaDB package


Hi Monty,

> The problem is that a too simple my.cnf will please very few (mainly
> desktop users) and leave the a bit more advanced user to search on
> the net and get 'anything' that looks remotely right.

I respectfully disagree. I think the sample my.cnf is targeted for
desktop users, medium-sized company users, and small business owners
whose expertise is low and frustration level can run high. A generic,
simple, and short my.cnf file serves that constituents well, gains
their confidence, and is conducive in building up their comfort and
skill level gradually, that they would seek information themselves on
the web and/or ask expert for help as the need for
performance/scalability rises. But that is AFTER they are comfortable
enough with the ease, power, and simplicity of MariaDB.

In other words, my view is that its target audience is not big size
social network sites, Facebook, Google, and other money-rich financial
companies. Those guys probably don't need the built-in sample anyway.
Personally, I feel a minimalistic file works the best.

This is not a debate of enterprise-worthiness of
MariaDB/Percona/MySQL. It is. It's just that I think the sample's
target is small scale users, relatively speaking.

> I prefer the other approach taken by most unix programs (like postfix)
> have taken where you have most important options in the config file,
> but the not common ones are commented, with a good explanation of when
> to enable the option.  This is makes it much faster to get good
> options without having to go trough a lot of manuals and web sites...

This will make it long, which tends to cause confusion. A typical
user/developer will be overwhelmed by the slew of jargons, which is a
turn-off, IMHO. Given the importance of key_buffer_cache, however,
perhaps that should be mentioned as a comment.

> I also personally like the original approach with small, medium, large and
> huge default config files, but now with many storage engines these are
> also not as valid as they originally where. (And I agree with Arjen
> that many of the values needs to be updates).

I actually went ahead with that assumption as well initially, but
after some thinking, I feel that contradict with the simplicity rule,
so I stopped. But the idea is still good, in my mind. So perhaps we
can put my-1gb.cnf, my-4gb.cnf, my-32gb.cnf on the knowledgebase?

> What should (at least) be done is to create new sections to the my.cnf
> files that one can easily enable if one uses different storage
> engines.  I would also like to see more options and better comments in
> the defaults file.

I agree, but I think we should NOT put in samples for every storage
engine under the sun. Once again, simplicity rules in my mind, so we
need only cover 2: MyISAM (Aria when Aria is mature enough to phase
out MyISAM) and InnoDB. I do realize that in the sample I sent out, I
didn't put any for InnoDB, which is probably not a good idea.

> I have this week actually added to MariaDB 5.2 some new startup
> options and groups to be able to make the option files smaller.
> For example, now in 5.2 both the server and clients are reading the
> 'client-server' group, so one doesn't have to specify the socket and
> port twice.
> I also added and --log-basedir so that one can specify the name for
> all log files with one command (instead of having to use 8+ different
> options) and new groups [mariadb] and [client-mariadb] so that one can
> use the same config file for MySQL and MariaDB running on the same
> computer.

That's fantastic!

In summary, it appears that we disagree quite a bit on this. And the
main point of contention, I think, is who is the target audience.
There is definitely a need to replace/update the current ones, though.

What about we package a minimalist sample my.cnf, and put a line in it
pointing to a web page on KnowledgeBase that has more samples
available with better explanation. Better yet, it is a wiki so the
knowledge can be crowd-sourced.