Configuring MariaDB - Getting Started with MariaDB - page 18

We will only have one of them and regardless of which one we have, they function
the same. The basic idea is to allow the package manager (APT or YUM) to be able to
install packages for MariaDB, which include additions to the MariaDB configuration
file without needing to edit or change the main my.cnf file. It's easy to imagine the
harm that would be caused if we installed a new plugin package and it overwrote
a carefully crafted and tuned configuration file. With these special directories, the
package manager can simply add a file to the appropriate directory and be done.
The MariaDB server, or any client or utility included with MariaDB, will read both
the main my.cnf file and any files in the my.cnf.d or conf.d directories that have
the extension .cnf when it starts.
For example, MariaDB includes a plugin called feedback whose sole purpose is to
send back anonymous statistical information to the MariaDB developers. They use
the information to help guide future development efforts. It is disabled by default
but can easily be enabled by adding feedback=on to the [mysqld] group of the
MariaDB configuration file (we'll talk about configuration groups in the following
section). Instead of adding this to the main configuration file, we can instead create a
file called feedback.cnf with the following contents:
[mysqld]
feedback=on
Place this file in the my.cnf.d or conf.d directory and when we start or restart the
server the feedback.cnf file will be read and the plugin will be turned on. Doing
this for a single plugin on a solitary MariaDB server may seem like too much work,
but suppose we have 100 servers, and further assume that since the servers are
different, each of them has a slightly different my.cnf configuration file. Without
using these directories to turn on the feedback plugin on all of them, we would have
to connect to each server in turn and manually add feedback=on to the [mysqld]
group of the file. This would get tiresome and there is also a chance that we might
make a mistake with one, or several of the files we edit, even if we try to automate
the editing in some way. Copying a single file to each server that only does one thing
(turn on the feedback plugin in our example) is much faster, and much safer. And, if
we have an automated deployment system in place, copying the file to every server
can be almost instant.
One thing to be aware of is that since the configuration settings in the my.cnf.d or
conf.d directories are loaded after the settings in the my.cnf file, they override the
settings in the main my.cnf file. This can be a good thing if that is what we want and
expect. Conversely, it can be a bad thing if we are not expecting that behavior. So
keep it in mind.