howa wrote:
>>From normal usage, InnoDB is sure better, i.e.
>
> quote from MySQL:
> ===============
> The outstanding feature of InnoDB tables is also automatic crash
> recovery - in case MySQL shutdown was unclean InnoDB tables will still
> recover to the consistent state, you will not have to check or repair
> them.
> ===============
>
> But they are talking normal/common usage, how about in the Worst Case
> Scenarios?
>
> I heard that in some rare case, if InnoDB table was corrupted, there
> are no method to repair them, is that true?
>
> So how about MyISAM vs InnoDB, in Worst Case Scenarios?

Yesterday at my previous employer someone turned off the power to a rack
of servers. The MySQL server in the rack was running 6 instances of
MySQL, 5 replicas and 1 primary server. The primary server application
uses innodb tables exclusively. When the systems were powered back on
everything came up fine except that the binary log for master server was
corrupt. This was sort of nasty because it made the replicas for the
master very unhappy. I got called to help them restart replication. We
had to do a complete copy to restore replication. So, I guess what I am
reporting is that in this case both innodb and myisam tables survived a
catastrophic system failure, but the binlog didn't.

The only innodb problems I have seen are with MySQL instances that are
configured to support innodb but do not have any innodb tables. Several
times I have seen the innodb structures get corrupt and keep the
instance from coming up. Since there were no innodb tables in the
instance my solution was just to delete the ibdata and log files and let
the MySQL startup recreate empty structures. I have never seen this for
a instance that has active innodb tables in it.

Bill