hi all,

I'm not confident to post the topic in this section, but not yet find batter match

Recently we had a mail server failed because of the database broken, I made an investigation that is because the disk used by database (mysql) has broken sectors just at the ibdata and ib_logfiles that ruin the whole database. The disk is a normal seagate sata disk using under 24x7 loads for several months without stop.

I then take an investigations to all hard disks we have from workstations to servers. I then find another 4 disks has broken sectors and all of them has installed with database (mysql or postgresql). All other disks using in application server or other workstations even running 24x7 has no problem. (we use normal SATA or SATAII disks with S.M.A.R.T. enabled)

This gives me an conclusion that database uses will easily give broken sectors to hard disks. So I'm looking solutions to monitor bad sectors in a running linux.

I think the usual solution is periodically reboot the server to force check the disk or use RAID, but in my concern even use RAID we need to have a knowledge of the broken sectors on the disk, for managed repair or change.

I'll do some google of the topic and update here, also appreciate any of your knowledge!

P.S. for modern disks that has extra blank sectors that the firmware can detect broken sectors and relocate it with transfer the data before it is impossible to read. but it seems not 100% reliable as our disks are those bad samples.

Since your question is really more of a Linux question than a database issue, I'll move it to the appropriate forum where it should get more useful replies.

While it is quite possible that you've found errors on your hard disks in the database files, I firmly believe that the database engine was the victim and not the culprit. Databases tend to use the disk intensely, and this intense use will often uncover problems that would otherwise be undetectable.

If it turns out that the problem is actually caused by MySQL, please open another thread in the MySQL forum or ask a moderator to move this thread there so you can take advantage of the MySQL expertise of DBForums users.

-PatP

Hi Pat,

Thanks for moving to the right place.

The database engine we use not only mysql, also postgresql. and both of them we detect problems.

About the victim or culprit I don't know, but the fact is all disks we using on servers or workstations are same, and is SATA disk. It begin with one database system fail to start, and we check is disk sector corruption, and then we did the same testing to all disks we have from server to workstation that still seems running well, and those disks detected broken sectors are all for the database uses. So it makes me believe the intensive use of disk shorten the life of it. Maybe is same concept it is more easy to broken a disk if you running eMule 24x7 on it.

Maybe database engines prefer to make sure the integrity of the data, so is more often commit changes to disk when there is any, instead of caching it for later batch commit, so less cache usage result in more write cycles that may sooner use up the cycles designed for the disk.

B.R.

Muzi

by the way, the tool we use for testing is the SeaTools which designed to find every hidden problem on the disk.

So is not the database discover the hidden problem on disk, but is us using seatools uncover the disk broken sector, and later surprisingly notice all those defective disks were use in database systems, and not only mysql engine.

Muzi

Switch to SCSI disks and a RAID controller that does sorted writes (write cache is sorted by track number before writing), or a solid state disk.

thank for the advise, I'll convince them to upgrade.

so it does mean db engines are stressful and actually "hurt" normal disks.

sincerely,

muzi

thx man
i will see later