[debian-mysql] my.cnf problems

[Stewart Smith]

"Norvald H. Ryeng" <norvald.ryeng at oracle.com> writes:
> On Sat, 07 Dec 2013 00:58:43 +0100, Stewart Smith  
> <stewart.smith at percona.com> wrote:
>
>> Bjoern Boschman <bjoern at boschman.de> writes:
>>> I've seen some blockers due to the fact that everybody (mysql, maria,
>>> percona) includes my.cnf from mysql-common.
>>>
>>> my 2 cent:
>>>
>>> maria: /etc/mariadb/my.cnf
>>> mysql: /etc/mysql/my.cnf
>>> percona: /etc/percona/my.cnf
>>>
>>> From my point of view it's a dream that cannot be fullfilled that all
>>> forks can share the same configuration file.
>
> I agree. They are mostly similar, but some day someone will add an option  
> that we want to use, but the other flavors don't support it.

Yep... and I suspect this will be more likely as MariaDB 10.0 and beyond
deviates further from MySQL and Percona Server.

Perhaps we really do need to switch to minimal my.cnf and
variant-specific config files.... but that makes migration still an
interesting thing.

I can say for certain that anything that would make drop-in-replacement
not work for MySQL->Percona Server (or vice versa if no PS specific
options used) would be considered a S1 bug that absolutely must be
fixed.

Personally, I'd like to see MySQL move more towards configuration stored
in the datadir rather than in a config file - then the server gets to
dictate things like "this is dynamically updateable, and we can in fact
rewrite the 'config' file" rather than the current situation of my.cnf
can get really out of whack with what current reality is.


>>> your comments?
>>
>> The idea of Percona Server is to be a complete drop-in replacement with
>> zero or near-zero effort going to/from MySQL... so having a different
>> configuration file would mean that switching to Percona Server would
>> suddenly use a different configuration, potentially even preventing the
>> server from starting (as the datadir is the same).
>>
>> I'm not sure what the best idea is here....
>
> I see your point. The main problem with a common my.cnf is that it's  
> impossible to separate between the servers. MySQL and Percona is probably  
> similar enough that this won't be much of a problem in practice, but  
> MariaDB doesn't follow MySQL that closely. With separate my.cnfs, we can  
> add flavor specific options to those and add common options in a common  
> file/directory (e.g., /etc/my.cnf.d/) that is included by all. Wouldn't  
> that work?

I think in the "short" term what I'll do is create a completely commented
out percona server example config that adds PS specific options with a
brief description (in fantasy land this would be pulled straight from
the docs).

If the InnoDB team moved away from config file options and towards the
CREATE/ALTER TABLESPACE SQL commands that have been there forever for
NDB that'd solve a lot of the problems, then it's just the rest of the
replication options.

After that, the core set of options neede to be compatible is probably
only about which sockets to listen on.

-- 
Stewart Smith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/attachments/20131210/88cc5e87/attachment.sig>