UNIX for Beginners Questions & Answers

Great news and glad to hear you got it all sorted out.

Congrats and well done.

Well done Peasant and MIG - hitting the nail on the head. Boom!

Dear DannyBoyCentOS,

My apologies, could you please repost your solution.

I made a mistake on mobile and accidentally edited your posts (and lost your info) instead of replying and quoting.

Was on mobile and made a mistake, my bad. Sorry.

Aw, shucks!

Peasant and MadeInGermany - thank you again, your solution worked.

Code:

umount /mnt/backup

cd /mnt/backup/
du -h
39G     ./servers-unix-hq/sugar.gnsa.local
39G     ./servers-unix-hq
4.5G    ./db-mysql-hq/sugar.gnsa.local
4.5G    ./db-mysql-hq
44G

Just like Peasant said, /mnt/backup was mounted on top of local directory with the same name. Once unmounted, the directory showed its true size.

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.

Regards
Peasant.

An additional note:

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.

(As Peasant says as well in his analysis ...)

What you wrote is part of what I meant: There are good reasons to do so. Yours and maybe others.... Just wanted to make it short for me.