/var/lib/mysql + symlink + SSD + Idera + MySQL restore = FAIL
We have a decent sized server with a pair of SAS drives (Raid 1) and a single SSD... When the server was configured, a symlink was setup from /var/lib/mysql to the SSD for all the databases:
We backup files and the mySQL databases via the Idera (R1Soft) backup and database agents. Everything works fine with backups and file restores... BUT the databases cannot be restored due the symlinked mysql directory... Apparently the symlinking of the /var/lib/mysql to somewhere else is the cpanel supported option but is not supported by Idera. Now since the server is in one datacenter and the backups in another, now we get the blame game going. Backup provider says server is not configured correctly, server support says backup agent is not configured correctly and Idera says go ask your backup provider. Only one left to open a ticket with is cPanel, but I'll post here first since they really do read these things. A few options left are: 1. Drop the whole SSD DB thing or go all SSD 2. Drop the symlink and map the datadir in the my.cnf 3. Drop the symlink and use mount to bind new path:
We can't be the only ones who ran into this... Ideas?
ln -s /ssd/mysql /var/lib/mysqlWe backup files and the mySQL databases via the Idera (R1Soft) backup and database agents. Everything works fine with backups and file restores... BUT the databases cannot be restored due the symlinked mysql directory... Apparently the symlinking of the /var/lib/mysql to somewhere else is the cpanel supported option but is not supported by Idera. Now since the server is in one datacenter and the backups in another, now we get the blame game going. Backup provider says server is not configured correctly, server support says backup agent is not configured correctly and Idera says go ask your backup provider. Only one left to open a ticket with is cPanel, but I'll post here first since they really do read these things. A few options left are: 1. Drop the whole SSD DB thing or go all SSD 2. Drop the symlink and map the datadir in the my.cnf 3. Drop the symlink and use mount to bind new path:
mount -o bind /ssd/mysql /var/lib/mysqlWe can't be the only ones who ran into this... Ideas?
-
I've dealt with Idera before. Use a bind mount, and it should work fine. 0 -
Thanks! I was leaning towards that one but wanted a better vote of confidence than a few random search results. 0 -
I'v submitted ticket # 4738539 to see if this would be "officially supported" vs the symlink in this scenario... Added to fstab: /ssd/mysql /var/lib/mysql none bind0 -
Hello :) I believe a bind mount would work out better compared to a symbolic link in this scenario. One alternative mentioned in the support ticket was to mount the partition directly to /var/lib/mysql to avoid using a symlink or bind mount at all. Thank you. 0 -
We proposed that when the SSD drive was added, but the DC the built out the server proposed the symlink. While we are backing up mySQL we can't restore in this condition, but this looks pretty "safe"... We will do a full dump of the databases first then drop the link and create the bind mount. And everything "should" be good. Now to find the time to do this... 0
Please sign in to leave a comment.
Comments
5 comments