php-fpm allows for a graceful restart of childs, usually with the reload keyword instead of restart on the init script, sending USR2 signal.
So by doing a graceful restart you should not loose any running transaction. The children are killed after the end of the current request management for each of them. This should be enough if you do not need a real restart. I made some tests and for example a reload is enough to :
- empty the APC cache
- alter log file path
- alter min/max/start child settings
So I did not find a case where a need a real restart yet. Except that a reload cannot start a stopped service.
If you want to ensure other pools will never be reloaded when you want to reload one of them you will have to manage several php-fpm daemons and one pool per daemon. This implies writing several init scripts and master configuration files.
Using the restart keyword is more dangerous, especially because the init script is maybe killing long running children in the stop step. And with several daemons managed with several PID and configuration files you could even get a start-stop-daemon command with --exec option (that’s the case in debian) and this would kill all the daemons running the same php-fpm executable (effectively sending a kill -9 to all the other parallel php-fpm daemons after stopping the right one with the right PID if you run several php-fpm processes, which is very bad).
So using the reload keyword (USR2 signal) is a must.