Config files are loaded in an order that hinders automation

[Jonathan Cutting]

On a fresh install of percona-server-server-5.7, the following tree is created in /etc/mysql:

├── conf.d
│   ├── mysql.cnf
│   └── mysqldump.cnf
├── my.cnf
├── my.cnf.fallback
├── my.cnf.old
├── percona-server.cnf
└── percona-server.conf.d
    ├── mysqld.cnf
    └── mysqld_safe.cnf

When using ansible for provisioning, it's useful to be able to drop in a file with settings that can override the defaults. However, due to the order in which the files are included in my.cnf:

!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/percona-server.conf.d/

it would seem the only way to do this would be to add a file in /etc/mysql/percona-server.conf.d/ which started with a letter after 'm' (and here I'm assuming mysql loads config files in alphabetical order).

A simpler solution might be to reverse the order of the includes like this:

!includedir /etc/mysql/percona-server.conf.d/
!includedir /etc/mysql/conf.d/

in order that the standard Percona settings are loaded first, and any file dropped into the /etc/mysql/conf.d/ directory can override these settings.

[Sveta Smirnova (svetasmirnova)]

Thank you for the report.

I assume you are using ansible for provisioning not only Percona Servers, but also upstream MySQL Servers? In this case this request makes sense. But at the other time it may break existing installations where users relied on current behavior.

I will mark this report "Confirmed", but do not get it as promise it will be eventually fixed. We should care about backward incompatibility very seriously. I personally would vote against fixing this.

[Jonathan Cutting (jcutting)]

@svetasmirnova thanks for your response and I understand your reservations. Perhaps provision for an additional directory such as /etc/mysql/local.d/ that is included last in the main my.cnf? i.e.:

!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/percona-server.conf.d/
!includedir /etc/mysql/local.d/

- Jon

[Shahriyar Rzayev (rzayev-sehriyar)]

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PS-3758