While /etc/my.cnf is the main config file, /etc/my.cnf.d is a directory for additional MySQL config files.
With regards to this question:
“I am confused as to why it has .d as an extension, from computer science class I remember paths ending in .d being like header files, but dependencies instead for C++ programs.”
All the .d stands for is directory. That’s it.
It’s just a different way of organizing config files. Nothing really deep or technical. And if you ask me, it is not needed for a MySQL install but I’m not a MariaDB developer who decided to create this functionality. So… hey! Onto the core details.
“If I can use both, then is it correct to assume that any settings set in /etc/my.cnf will override other configurations placed inside the /etc/my.cnf.d directory?”
Nope. The exact opposite: /etc/my.cnf gets loaded first and the configs in /etc/my.cnf.d gets loaded afterwards. Details below.
While /etc/my.cnf is the main config file, /etc/my.cnf.d is a config directory. Meaning a directory that might contain multiple config files.
As the official MariaDB docs explain:
Including Option File Directories
It is also possible to include all option files in a directory from another option file. For example, to include all option files in /etc/my.cnf.d/, an option file could contain:
[mariadb]
...
!includedir /etc/my.cnf.d/
That !includedir config option will load config files from the /etc/my.cnf.d/ directory. Typically after the main config in /etc/my.cnf loaded.
The reality is you can just make all of the changes you want in the main /etc/my.cnf file but the /etc/my.cnf.d directory can contain config options you wish to manage separately.
Honestly, I have never understood the benefit for MySQL. But — for example — in Apache there is a similar directory called /etc/httpd/conf.d and that is where I would drop specific config files that change depending on server and location.
But for MySQL (or MariaDB) I just make all of my changes in the main /etc/my.cnf config file.
I mean, maybe you could break out all of the InnoDB config options and set them in a config file called /etc/my.cnf.d/innodb.cnf and load that as needed. But each time I think about the benefits of doing something like that, it still seems like an excessively fragmented method of config management.
In the end, you need to look at /etc/my.cnf.d/ as a convenience method of managing config files. If you don’t need it, don’t use it.
