Re: Can replicating between versions cause crashed tables?

[Rick James]

The Master is 4.0 and the Slave is 5.1 right? (The other way probably won't work.)

We are doing a similar thing. mysqldump 4.0, import it into 5.1 (no intermediate steps). Recommend you, too, do it in a single hop.

Things that can be an issue... The strings had no real encoding (4.0 is pretty dumb there), so for expediency we made the CHARSET defaults latin1 on the 5.1 system. Converting the charset at the same time was deemed to be fraught with problems. Do you have any non-ascii characters?

There are perhaps 30 minor incompatibilities between 4.0 and 5.1; we hit two of them. (Example: inserting NULL into NOT NULL used to insert the DEFAULT; now it is an error. The fix: change the code.)

The documentation says to walk through 4.1 and 5.0 -- I think it is referring to upgrading the software with the data in place; that is not using mysqldump.

We did not encounter any crashes. Sounds like you are using MyISAM? Most of our tables are MyISAM, and designed by dozens of people.

We are currently stress testing the situation (4.0 master still live; 5.1 slave). ~150 queries/sec are being replicated 24/7.

A table crash usually comes from a server crash, not replication. So, your specific issue remains a mystery.

Suggest you check the record counts _before_ it crashes. Possibly the import lost some rows. SHOW WARNINGS after the import -- 5.1 is more generous in telling you things, but it hides them in WARNINGS. (Of course, realize that SELECT COUNT(*) or SHOW TABLE STATUS is a moving target if INSERTs are coming in. And SHOW TABLE STATUS gives imprecise row counts for InnoDB.)
I think it is unfortunate that you are switching from Unix to Windows.

Don't know if there is anything to spot, but could you present the before and after my.cnf (my.ini) files? And, if possible, a diff.