Bug 64924 - frequent table corruption
frequent table corruption
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: mysql (Show other bugs)
7.3
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Patrick Macdonald
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-05-14 12:31 EDT by bastiaan
Modified: 2007-04-18 12:42 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-05-22 09:55:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description bastiaan 2002-05-14 12:31:02 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226

Description of problem:
Both version 3.23.36 and 3.23.49a (and probably other versions) of RedHat
supplied MySQL packages cause frequent corruption of data tables as shown in:

mysql> check table bulkmessage;
+---------------------+-------+----------+---------------------------------------------+
| Table               | Op    | Msg_type | Msg_text                            
       |
+---------------------+-------+----------+---------------------------------------------+
| bulkmessage         | check | warning  | Table is marked as crashed          
       |
| bulkmessage         | check | error    | Wrong bytesec: 0-0-0 at linkstart:
41273800 |
| bulklog.bulkmessage | check | error    | Corrupt                             
       |
+---------------------+-------+----------+---------------------------------------------+
3 rows in set (11.63 sec)



Version-Release number of selected component (if applicable):
mysql-3.23.49-3

How reproducible:
Always

Steps to Reproduce:
The problem has not been reduced to a very small isolated script yet. 
In the actual system, one Java process connects to the database for batch
updates to the 'bulkmessage' table using MMMysql 2.0.6 JDBC once per hour.
Another process has a single JDBC connection doing continuous updates (about 2
per second) to the same table. 
This results in a corrupted table within a day. 
	

Actual Results:  'check table' detects the corruption shown in the 'description'
section above.

Expected Results:  The table should not get corrupted, of course.

Additional info:

The www.mysql.com website contains a big warning stating that compiling mysql
with gcc 2.96 may lead to table corruption, which in all observed cases went
away after switching to a 2.95 compiled mysql version.
In our case switching to MySQL AB supplied binaries of MySQL 3.23.49a resolved
the problem indeed. 
It may be wise to follow MySQL AB's advice and compile the Red Hat MySQL
packages with gcc 2.95 as well.
Comment 1 Trond Eivind Glomsrxd 2002-05-14 17:49:54 EDT
Gcc 2.95.x is known buggy, and without a testcase, this bug can't be confirmed
or fixed.
Comment 2 bastiaan 2002-05-15 15:31:06 EDT
Yes, of course you need a test case. I'll try to create one a.s.a.p. In the mean
while I'll attach other info that may be relevant (and me be interesting to
other experiencing similiar problems).
It turns out I was a bit to soon in stating that the MySQL AB supplied binaries
don't show the problem: it just appears to take a bit longer before corruption
occurs. Since this mysqld binary has been statically linked this leaves only the
mysql daemon, the kernel or the hardware as possible culprits. 
The system is a dual Pentium III 600 system with 1GB RAM, running kernel
2.2.19-7.0.12.

Comment 3 Trond Eivind Glomsrxd 2002-05-15 16:56:49 EDT
Can you try getting the SRPM for RHL 7.3, disable the assembler in the spec file
(look at the %configure statement) and try that? The assembly has had problems
in the past....
Comment 4 bastiaan 2002-05-22 09:55:30 EDT
Thanks for the suggestion. I've not been able to create a testcase yet, however,
because we have only 1 SMP machine running RH 7.x. Since it's a production
machine I don't have the liberty to experiment with it.
In the meanwhile I've run an 'optimize table' on all tables and turned on binary
logging. Also a cleaning job halved the row counts of most tables.After that
we've not experienced corruption anymore, it has been OK for 6 days now, where
usually corruption occurred within 1 or 2 days of the last 'repair table'.
Because of all these simultaneous changes, little can be said yet about where
the problem lies. 
 
Comment 5 Trond Eivind Glomsrxd 2002-08-28 12:43:41 EDT
OK, seems to work now. Closing.

Note You need to log in before you can comment on or make changes to this bug.