It's understandablehow this could be desirable in different use cases.
My concern is that this could catch quite a few people with an
unexpected config change. In my case, the problem was very obvious, as
remote connection no longer worked. However, it's possible that some
people might be using it to override common MySQL settings on a
per-server basis (such as settings related to memory usage, temp table
sizes, buffer sizes, etc). In those cases, the server would probably
continue running as if nothing was wrong, but they could experience a
sudden performance hit when the daemon is suddenly not utilizing as much
memory for caching and the like.
Just to confirm, the implied behavior in MySQL 5.5 was that options set
within conf.d/ would override the global defaults under
/etc/mysql/my.cnf (since the conf.d/ directory was included at the end
of my.cnf). Now the default behavior in MySQL 5.6 is that the global
config file (now in /etc/mysql/mysql.conf.d/mysqld.cnf) overrides the
settings withing conf.d/ files. This is the main gotcha that concerned
me, since it wasn't something I was expecting. I didn't really see
anything in the Debian changelog that would warn of this, aside from
"Switch to new /etc/mysql/my.cnf management scheme" for 5.6.25-2.
As far as a way to solve it for both needs, I'm not sure what would be
the best way. It does seem like the upgrade from 5.5 to 5.6 would be the
best time to hammer it out though, since someone will be consciously
performing this upgrade. Maybe it's better to move any existing custom
files under conf.d/ into the mysql.conf.d/ directory (is that even
tracked)? They could be named in a way to ensure they are included after
the other mysql*.cnf files. I'm not familiar with all of the upgrade
paths people might be following (for me it was just a "routine" MySQL
server upgrade), so I don't know how feasible this is. I would think at
least at a minimum some sort of warning that this is happening so it
wouldn't catch people completely off-guard.
Thanks.
Justin Pasher
