Yeah, I would not have done the "extend the root partition" approach. It would work but it is suboptimal.
It would be better to create a new partition for the mysql data and move it off the root partition. I try to keep as much user data, dumps and backups off the root partition as I can, generally speaking.
You might still consider doing this, as you are still have your main apps data directory on your root partition.
My suggestion to you, after you got mysqld running again on the (temp) /home partition, was to ask you to create a new partition for your db data. Normally I call this, not surprisingly:
To conclude check /etc/fstab for the mentioned mountpoint.
On first glance, a server was rebooted and came up without the mountpoint.
It happily worked until root filesystem is full, since same contains the service in question - mysql database.
At least, separate database filesystem as a logical volume, or even better a new disk partition with volume group.
A wise choice would be to separate /var inside root volume group, not now but for future projects
With seperate /var and mysql, you are very likely to survive full / partition without downtime.
In your case, only backup would not work, instead of making system almost unusable.
Under Linux there are SELinux and AppArmor around. They take care that services have only read/write/execute permissions which they need(predefined via config).
I do not know if they are armed at CentOS.
But if they are, file permissions are restricted to the configured mysql data location and one will get permission errors if moving the data directory without changing SELinux/AppArmor configuration as well.
---
What's regarding partition separation: I prefer all on the root-partition - as opposed to many recommendations especially from traditional unix administration point of view. My reason: It is simpler. I'm monitoring filespace, so it won't go undetected if the machines run low on space. I have a lot not so big machines. In another environment I might prefer seperated partitions.
What I recommend is to always use LVM. It's very flexible and you can move around filesystems to different disks online and can increase fs size online.
But to see the fact partition separation would have saved you in this case.
The main problem with putting all the data on the same root partition when running a production database is that if the database directory gets very large and fills up the root partition, it is possible the system will not boot and / or critical root partition log files will not log.
When running databases like we do with very large binary transactions logs, the database directory gets very large very fast.
However, when on a separate partition and full, not on root, the system will boot and continue to log (syslog, etc).
That is a big plus for most system admins knowing that a full data partition will not crash the boot partition.
For me, it's nothing to do with "traditional unix".. I do it because I do not want a full db partition to effect the boot partition and since I have seen this problem many times, it's better to have the db crash than the entire system / server crash.. I can log into a crash due to a full db partition, but I cannot login to a system which will not boot due to a full root / boot partition.
So, for me, all my data for a big database is off the root / boot partition, always (for production). Same is true for my backup directory of mysql dumps.
