The mysqldump command I used originally was:
mysqldump --quick --add-locks --extended-insert -u root -p dbname > dbname.sql
When this didn't work upon restoration I also tried:
mysqldump --opt -u root -p dbname > dbname.sql
Both these commands created the dbname.sql file with no problems or complaints.
I copied the SQL file over to the target computer. I went into mySQL as root and did:
create database dbname;
The import would start, but it wouldn't get very far. In the end, after not many seconds it would just...stop. Here is an example:
Query OK, 8708 rows affected (0.11 sec)
Records: 8708 Duplicates: 0 Warnings: 0
Query OK, 8750 rows affected (0.12 sec)
Records: 8750 Duplicates: 0 Warnings: 0
Query OK, 8740 rows affected (0.11 sec)
Records: 8740 Duplicates: 0 Warnings: 0
Query OK, 8758 rows affected (0.11 sec)
Records: 8758 Duplicates: 0 Warnings: 0
Query OK, 8745 rows affected (0.12 sec)
Records: 8745 Duplicates: 0 Warnings: 0
And it would just stop here. I waited several minutes, and the load average of the machine went down to normal levels. The mySQLd stopped showing up on top.
I'd then CNTRL-C the process and get:
^CQuery aborted by Ctrl+C
mysql: 0 files and 1 streams is left open
I've done this a few times and the results have been consistent(ly bad). As I mentioned I also did two separate mysqldumps and both files failed to import the same way.
While the import was happening I watched "top." There didn't seem to be a memory issue since the mysqld never used more than 0.3% of the memory, although it did use 96% of the CPU (which was fine).
The mysqlds are running on the same operating system - Fedora 10 x_64. The only difference between them is the dump was done on mysql 5.0.27, and I am trying to source to a mysqld v5.0.67.