alf wrote:
> Gordon Burditt wrote:
>
>>> is it possible that due to OS crash or mysql itself crash or some e.g.
>>> SCSI failure to lose all the data stored in the table (let's say million
>>> of 1KB rows).
>>
>>
>> Managing to smash just one sector, the sector containing the data
>> file inode, or worse, the sector containing the data file, index
>> file, AND table definition inodes, could pretty well kill a table.
>> I have had the experience of a hard disk controller that sometimes
>> flipped some bits in the sectors before writing them. It took weeks
>> to discover this.
>>
>>
>>> In other words what is the worst case scenario for MyISAM
>>> backend?
>>
>>
>>
>> Probably, total loss of data and hardware.
>>
>
> well, let's narrow it down to the mysql bug causing it to crash. Or
> better to the all situations where trx's capabilities of InnoDB can
> easily take care of a recovery (to the last committed trx).
>
> I wonder if there is a possibility due to internal structure of MyISAM
> backend to lose entire table where even recovery tools give up.
>
> Would using ext3 help?
>
>
> Thx in advance, Andy

As Gordon said - anything's possible.

I don't see why ext3 would help. It knows nothing about the internal
format of the tables, and that's what is most likely to get screwed up
in a database crash. I would think it would be almost impossible to
recover to a consistent point in the database unless you have a very
detailed knowledge of the internal format of the files. And even then
it might be impossible if your system is very busy.

The best strategy is to keep regular backups of the database.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================