Re: Running out of disk space

From: Gordon Burditt <gordonb.772ch_at_burditt.org>
Date: Sat, 22 Oct 2016 22:27:55 -0500
Message-ID: <Vt2dndXFlr2ms5HFnZ2dnUU7-W3NnZ2d_at_posted.internetamerica>


>> If my server hard disk becomes full, is there a way to stretch out the MySQL DB over multiple hard drives? What needs to be done?

>
> Sure, there are different ways, not all of them are good.
>
> 1. Partitioning http://dev.mysql.com/doc/refman/5.5/en/partitioning.html
>
> 2. Move databases to different location and symlink the database to the
> default place

[Quoted] Does symlinking pieces of tables actually work? It seems to me that, for MyISAM databases at least, if you make symlinks for JohnnyTables.MYI, JohnnyTables.MYD, and JohnnyTables.frm, each pointing to its own (multi-terabyte) disk, it might work for a [Quoted] while, but for some operations like ALTER TABLE (the uses that require building or re-building indexes or data records) and REPAIR TABLE, it generates a new table (at least the *.MYI and *.MYD files) under a temporary name and renames them back, thus destroying the symlinks and putting all the data back on the disk for the data directory. For a large database, these commands run slowly enough that you can watch the files grow while praying that you won't run out of disk space. Or is there an option to prevent that? The [Quoted] presumption here is that JohnnyTables.MYI and JohnyTables.MYD can't fit together on the largest disk partition, RAID partition, or logical volume you can make.

Of course, InnoDB tables are stored in a completely different way.

If you can reasonably fit the whole database (*.MYI + *.MYD + *.frm for all tables combined) on the same disk, with enough free space for growth and an extra copy of the largest of the *.MYI and *.MYD (so you can do an ALTER TABLE without running out of space), then symlinking directories seems more likely to work.

> 3. Move the whole mysql directory to the new device and update
> configuration so it uses the new location.
>
>
> Up to you to pick what you want to use, I would at least avoid #2 unless
> there is no other way.
Received on Sun Oct 23 2016 - 05:27:55 CEST

Original text of this message