Systems using systemd (CentOS >=7) will have the reboot, shutdown and halt commands symlinked to systemctl to handle the reboot. The systemctl program will detect the use of the symlink and run the systemctl command with the correstponing arguments. For the difference between the commands see the manpage for systemctl (man systemctl) for it is quite nicely documented.
For CentOS 6, there is no better way to restart your server by using anything else than any those commands stated in the original question:
- shutdown is the most common way to stop your system. Adding the argument
-rand a specific time (or ‘now‘) will reboot your system instead of halting it after the shutdown sequence. - reboot is a wrapper round shutdown which does some harddisk maintenance (syncing and/or putting in standby mode and not really relevant).
- New versions of
reboot(>2.74) will initiateshutdownif not in runlevel 0 or 6. - Most init scripts call halt to make a log in utmp.
Modern distributions will have all tasks covered regardless of the command you are using. Basically they all initiate the shutdown run-time of your SysV (CentOS <7) or systemd (CentOS >=7) scripts (I will call them init scripts for ease of reading).
Shutting down using init scripts step by step stop all your services registered under usually runlevel ‘S’. Individual init scripts can have a timeout, like the MySQL init script in CentOS. When the stop argument is given and the daemon will not be shutdown in a fair amount of time, the script will stop and exit giving a failure. The shutdown process will continue as if nothing was wrong, only taking a bit longer and probably print a warning. At the end, when all init scripts are executed, the inevitable will happen: all processes still running will get a SIGTERM signal and, after a few seconds (2 or 5), a SIGKILL. This will clean up the rest before an ACPI call is done to really reboot or shutdown your system.
One exception is using the reboot command with the -f option, this will skip executing init scripts and will reboot the system directly.
You will be better off fixing the root-cause of your worries: MySQL not shutting down properly.
Often this is due to the massive load of work that needs to be done before the daemon can be exited safely. I once had a MySQL instance with +300.000 tables that took over an hour to exit. Similar issues can be found with systems using huge buffers and sparse I/O availability.