[debian-mysql] my.cnf problems

[Stewart Smith]

Kristian Nielsen <knielsen at knielsen-hq.org> writes:
> I think this discussion is missing the point here.
>
> The my.cnf is a config file, it is owned by the user. We should not change it
> in most cases. In MariaDB .deb packaging we have seen many times that users
> would during upgrade install the new config to replace their old one, breaking
> their setup. Those users then have no clue what went wrong or how to change
> it.

Yep.

> The two typical ways that changing my.cnf breaks are:
>
>  - Changes related to data directory (eg. the path to it, the innodb log size,
>    etc). Then mysqld cannot start because the config and the data directory
>    are not matched.
>
>  - Changes related to other applications (eg. changing the default sql mode to
>    be more strict, breaking wordpress).
>
> (Note that _any_ change in package my.cnf can cause this; users may have
> changed the critical setting locally, and then upgrade will ask to replace
> their (correct) config with the new (incorrect) config. We have seen many
> times that users mess up and select to replace the config).

Yep, and it just gets to be a bigger problem when switching between
MySQL variants, where the "no, don't change my config" can in fact now
break things.

> So the problem is not my.cnf compatibility between MySQL, MariaDB, and Percona
> Server. The problem is compatibility with the users data directory and with
> installed applications.
>
> The solution is to not change /etc/mysql/my.cnf. If needed, we can drop
> distro-specific options into /etc/mysql/conf.d/. Eg. in the 3rd-party MariaDB
> packages we have /etc/mysql/conf.d/mariadb.cnf in package mariadb-common,
> which is included by the my.cnf in upstream package mysql-common (however
> mariadb.cnf is actually empty, we do not have any default MariaDB specific
> options enabled, nor should we, I think).

It'd be a good place to have some example things of what you could
enable (commented out).

> Note that _if_ we were to use separate my.cnf configuration files for MySQL,
> MariaDB, and Percona Server, we would also need to separate the data
> directories. So that installing eg. Percona Server would no longer
> automatically take over the data directory of a previous installed MySQL
> server. Because in general the data directory cannot be correctly/safely used
> without the corresponding my.cnf. However, this is not how things have been
> done traditionally. Eg. packages mysql-server-5.1 and mysql-server-5.5 have
> shared configuration and data directory, and the situation with MariaDB /
> Percona Server is no different from the 5.1/5.5 distinction.

and I think we want to do that into the future too, otherwise migrations
just become really, really messy.

-- 
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/30f303d8/attachment.sig>