alf wrote:
> Jerry Stuckle wrote:
>
>> That doesn't mean the tables themselves can't be corrupted. For
>> instance if MySQL crashes in the middle of large write operation.
>> Nothing the file system can do to prevent that from happening. And
>> you would have to know exactly where to stop the file system restore
>> to recover the data - which would require a good knowledge of MySQL
>> table structure.
>
>
> I understand that.
>
>
>> Yes, it does. That's its job, after all. But if the tables
>> themselves are corrupted, nothing the file system will do will help
>> that. And if MySQL can't recover the data because of this, which file
>> system you use doesn't make any difference.
>
>
> Not sure I agree. ext3 enables a quick recovery because there is a
> trxlog of the file system itself. In ext2 you can lose files. So there
> is a small step froward.
>

So? If the file itself is corrupted, all it will do is recover a
corrupted file. What's the gain there?

>
>>
>> Backups are ALWAYS feasible. And critical if you want to keep your
>> data safe. There is no replacement.
>
>
> In my case backups get outdated every minute or so. There is a lot of
> data coming into DB and leaving it. Also losing the data from last
> minute or so is not as critical (as opposed to banking systems).
> Critical is losing like 5%. I know the system is just different.
>

Without backups or logs/journals, I don't think ANY RDB can provide the
recovery you want.

>
>> You can get some help by using INNODB tables and enabling the binary
>> log. That will allow MySQL to recover from the last good backup by
>> rolling the logs forward. There should be little or no loss of data.
>
>
>
> For some other reasons INNODB is not an option. My job is to find out if
> crashing the mysql or the actual hardware the mysql is running on can
> lead that significant amount of data (more then 5%) is lost. From what
> I understand from here it is.
>
> Thx a lot, A.
>
>

You have a problem. The file system will be able to recover a file, but
it won't be able to fix a corrupted file. And without backups and
logs/journals, neither MySQL nor any other RDB will be able to guarantee
even 1% recovery - much less 95%.

Let's say MySQL starts to completely rewrite a 100Mb table. 10 bytes
into it, MySQL crashes. Your file system will see a 10 byte file and
recover that much. The other 99.99999MB will be lost. And without a
backup and binary logs, MySQL will not be able to recover.

Sure, you might be able to roll forward the file system journal. But
you'll have to know *exactly* where to stop or your database will be
inconsistent. And even if you do figure out *exactly* where to stop,
the database may still not be consistent.

You have the wrong answer to your problem. The RDB must do the
logging/journaling. For MySQL that means INNODB. MSSQL, Oracle, DB2,
etc. all have their versions of logging/journaling, also. And they
still require a backup to start.

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