Hi, friendly neighborhood DBA here.

Turns out @Abdussamad and @jarland are both right because "data corruption/data loss" has two different meanings.

**Where @Abdussamad was right:**

MyISAM doesn't support foreign keys and is not transactionally consistent.  So if we send these two statements like these (semi-colons left out because CloudFlare was having kittens):

UPDATE accounts SET balance = balance - 1000, note = 'Taylor Swift Fan Club Special Dues' WHERE owner = 'jarland'

UPDATE accounts SET balance = balance + 1000, note = 'From jarland' where owner = 'tswift'

And the server fails after command #1, then jarland will be out 1000 dollars and Taylor Swift will not receive the credit, meaning she won't send her concert-worn panties to @jarland and man, will he be pissed.  Some would call that data loss/data corruption.

On the other hand:

BEGIN TRANSACTION
UPDATE accounts SET balance = balance - 1000, note = 'Taylor Swift Fan Club Dues' WHERE owner = 'jarland'
UPDATE accounts SET balance = balance + 1000, note = 'From jarland' where owner = 'tswift'
COMMIT

Means that either both statements succeed or both fail as a unit - no partial failures.  You get that with InnoDB, you don't get it with MyISAM.

Now if you're not running the Taylor Swift Fan Club but are instead running a Wordpress blog, you might not even notice a problem if it's just that one comment isn't associated correctly or something.

**Where @jarland was right:**

If InnoDB isn't recording in a crash-tolerant way, that's actually a completely different issue.  The theory is simple - write to an append-only log for performance, then have a daemon the follows behind to flush those blocks back to the datafiles asynchronously.  Add something smart in memory to keep track of which blocks are current, and maybe a couple levels of indirection if you want to support point-in-time queries or flashing the DB back, and that's the modern RDBMS.  Quite disappointing if InnoDB is not getting something write.

I don't do a lot of InnoDB in my ${DAY_JOB} but I've had numerous experience in the last ten years where the rug was pulled from under Oracle or MS SQL Server (from a datacenter power outage to a bad SAN controller to someone doing something stupid) and I've never seen a case where there was a problem with recovery.  In general the main commercial DBs are stellar at recovering from mayhem.