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. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
