When MySQL starts, it looks for configuration files in a specific order. On Ubuntu systems, the loading sequence is:

/etc/my.cnf
/etc/mysql/my.cnf
~/.my.cnf

The presence of !includedir /etc/mysql/conf.d/ in your my.cnf indicates MySQL will also read configuration files from this directory. To verify which files are actually being loaded, run:

mysql --help | grep "Default options"

The mysqld --print-defaults output shows duplicate parameters, which suggests possible configuration file conflicts. To see exactly which settings are active in your running MySQL instance:

mysql -e "SHOW VARIABLES;"

The key issue appears to be that MySQL isn't properly restarting. Here's the correct sequence:

sudo service mysql stop
# Verify process termination
sudo ps aux | grep mysqld
# If processes remain, force kill
sudo kill -9 [process_id]
sudo service mysql start

To test if your my.cnf is valid and being read:

mysqld --verbose --help | grep -A 1 "Default options"

For a dry-run of your configuration:

mysqld --defaults-file=/etc/mysql/my.cnf --validate-config

Ubuntu's MySQL package often includes:

/etc/mysql/conf.d/mysqld_safe_syslog.cnf
/etc/mysql/conf.d/mysqld.cnf

These may override your main my.cnf settings. Check them for conflicts.

If the main my.cnf continues to be ignored, you can:

# Create a new override file
sudo nano /etc/mysql/conf.d/override.cnf
# Add your custom settings there
[mysqld]
innodb_buffer_pool_size=500M
# Then restart
sudo service mysql restart

To verify changes took effect:

mysql -e "SHOW VARIABLES LIKE 'innodb_buffer%';"

For a full configuration audit:

mysql -e "SHOW VARIABLES;" > current_config.txt
diff original_config.txt current_config.txt

When dealing with production servers:

1. Always backup your databases before configuration changes
2. Test changes in staging first
3. Consider using MySQL's dynamic variables where possible:

   mysql -e "SET GLOBAL innodb_buffer_pool_size=536870912;"

4. Document all changes and their effects

---

When modifying MySQL configuration in my.cnf, the changes should be reflected after a service restart. However, in some cases like yours, the server appears to ignore the updated configuration. Let's break down what's happening:

# Checking active MySQL processes
$ top -b | grep mysql
27652 root      20   0  4096  424  420 S    0  0.0   0:00.01 mysqld_safe
27769 mysql     20   0  392m  57m 7236 S    0  1.5 119116,08 mysqld

The --print-defaults output shows MySQL is actually reading your my.cnf file (notice the duplicate innodb_buffer_pool_size entries), but the service restart isn't properly reloading the configuration.

1. Multiple Configuration Files

Even though you found only one my.cnf, MySQL may be loading additional configurations:

# Check all loaded configuration files
$ mysql --help | grep "Default options"
Default options are read from the following files in the given order:
/etc/my.cnf /etc/mysql/my.cnf /usr/etc/my.cnf ~/.my.cnf 

2. Service Management Issues

On Ubuntu systems, the service script might not properly stop MySQL:

# Proper way to ensure MySQL is stopped
$ sudo killall mysqld
$ sudo service mysql start

3. Configuration File Permissions

Check if MySQL can read the file:

$ ls -la /etc/mysql/my.cnf
-rw-r--r-- 1 root root 1234 Feb 15 10:00 /etc/mysql/my.cnf

To verify exactly which configuration MySQL is using:

# Connect to MySQL and check variables
mysql> SHOW VARIABLES LIKE 'innodb_buffer_pool_size';
+-------------------------+-----------+
| Variable_name           | Value     |
+-------------------------+-----------+
| innodb_buffer_pool_size | 134217728 |
+-------------------------+-----------+

If the value doesn't match your my.cnf, try forcing a configuration reload:

# Alternative restart method
$ sudo /etc/init.d/mysql stop
$ sudo /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf &

For production environments, always:

• Take a full backup before making configuration changes
• Test changes in a staging environment first
• Consider using SET GLOBAL for temporary changes

# Temporary change without restart
mysql> SET GLOBAL innodb_buffer_pool_size=536870912;

After making changes, verify the running configuration:

# Check current configuration source
$ ps aux | grep mysql
mysql    27769 ... /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql ...

If you still see old values, the service might be reading from a different configuration file or the changes require a full restart rather than a reload.