##Custom MySQL configs
If you need to customize the MySQL configuration, we provide methods to do this as outlined in our docs. Often, if people are making these changes with custom recipes, they usually follow up with a restart of MySQL via an execute call to /etc/init.d/mysql restart, or via a 'service' resource call with the 'restart' action. Often, this is done by people not realizing that Chef’s service notification methods can be used to conditionally restart MySQL, only if the custom configuration file has actually changed. The following snippet added into your custom recipe would make sure that MySQL is only restarted if your custom config template actually changed since the last run. It also allows for you to separate out your customizations based on whether they are dynamic or not (see our main MySQL configuration doc for an explanation of the differences.
service "mysql" do
supports :restart => true
action :enable
end
if ['solo', 'db_master', 'db_slave'].include? node[:instance_role]
# Non-dynamic config changes require a MySQL restart
template "/etc/mysql.d/custom-non-dynamic.cnf" do
owner 'root'
group 'root'
source 'custom-non-dynamic.cnf.erb'
notifies :restart, resources(:service => 'mysql')
end
# Dynamic changes do not require MySQL to be restarted.
# Changes to this template will never restart MySQL, so you
# should run the relevant SET commands against the server.
template "/etc/mysql.d/custom-dynamic.cnf" do
owner 'root'
group 'root'
source 'customm-dynamic.cnf.erb'
end
endAs mentioned in the comments of the above code snippet, dynamic configurations that go into the custom-dynamic.cnf file will not be applied to the MySQL server during a Chef run. They go into that file so that they will be applied on future restarts of the MySQL daemon. If you add changes to that file and are not restarting the service for other changes, then you should run the relevant SET commands against the MySQL server to apply your changes.
Setting up custom MySQL configurations in this way avoids restarting MySQL more than is necessary, as this can be harmful to some setups, while caches have to warm up again after a restart.