Are you running out of temp space?
Tim Brody wrote:
>binary MySQL 4.0.20-standard on Redhat 7.2/Linux
>Dual-proc, 4Gb ram, raid
>
>I'm trying to change an index on a 12Gb table (270 million rows). Within an
>hour or so the entire table is copied, and the index reaches 3.7Gb of data.
>Then the database appears to do nothing more, except for touching the Index
>file (the timestamp changes, with no change to file size). I've left it for
>4 days with no further increase in the index size (which should eventually
>be a similar size to the data). The MySQL process is at most 4-5% CPU util,
>having been at 60-90% during the initial hour.
>
>I've left it performing "Repair with keycache", tried set
>myisam_max_sort_file = 17179869184 forcing MySQL to "Repair by sorting"
>without success. With Repair by sorting a TMD file is created with a
>duplicate of the data, but the index reaches the same point and stops.
>
>I originally created the table through multiple-inserts.
>
>The table is a mix of varchars, ints and a year. It has a primary key over
>two ints, and a key over varchars/year.
>
>I know this isn't much to go on, but what's special about 3.7Gb? (A rogue
>unsigned int somewhere in Repair with keycache/Repair by sorting?)
>
>All the best,
>Tim.
>
>
>
>
