William, ----- Original Message ----- From: "William R. Mussatto" <[EMAIL PROTECTED]> To: "Heikki Tuuri" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, August 12, 2002 10:29 PM Subject: Re: Found cause of crash - simple SQL statement.
> Pardon my ignorance, what "Linux table corruption" and what versions of > Linux and MySQL are we talking about? I googled, but came back only with > "4.4.6.7 Using myisamchk for Crash Recovery ... --skip-external-locking". > > Not much help. I'm sorry if this is old news, but I thougth I was > following this and didn't notice any threads on it. the downloads page contains the following text: " Linux Advisory: Several of our users have reported random table corruption with Linux kernel 2.2.14 under heavy load. The table corruptions went away after an upgrade to a newer kernel. It appears that version 2.2.14 of the Linux kernel has a bug in the I/O implementation. Under some rather rare circumstances, the kernel will write incorrect data to the disk. " Unfortunately the problem is more widespread than just the kernel 2.2.14. In some Linux computers both MyISAM and InnoDB type tables will occasionally get corrupt. We do not know the cause. In some cases we know for sure that the bug was in the Linux file cache, because rebooting the computer fixed an apparent page checksum error. The page was ok on disk, but corrupt in the Linux file cache. In February I think that someone reported that he got page checksum errors. By updating the RAID driver to a new version he was able to fix the problem. It is possible that many cases of corruption are caused by some unknown memory overwrite bug in MySQL, but if that is the case, the bug has eluded tracking for years. My current hypothesis is that the disk drivers or some other drivers are buggy in some Linux / hardware combinations. Our own 4-way Linux server Suse-2.4.16-SMP seems to be totally stable. No table corruption seen in stress tests. Other operating systems, FreeBSD, Solaris, Windows seem to be almost free of table corruption problems. If the problem really is buggy drivers, then it is inevitable that, for example, Sun's computers will always be more reliable than Linux/PC-based solutions. Sun provides the whole package, operating system, hardware and all. They can test the systems better than PC vendors. Regards, Heikki Innobase Oy > On Mon, 12 Aug 2002, Heikki Tuuri wrote: > > > Date: Mon, 12 Aug 2002 20:52:14 +0300 > > From: Heikki Tuuri <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED] > > Subject: Re: Found cause of crash - simple SQL statement. > > > > Julian, > > > > the crash probably means the table is corrupt. That is a very basic query > > you run. Difficult to believe in any bug in SQL itself. > > > > Please dump your tables. > > > > Then upgrade to MySQL-Max-3.23.51. It is best to use an official binary. > > > > Then run CHECK TABLE on the table statcache. What does it print to the .err > > log? > > > > Then recreate the InnoDB database, data files and all, and import your > > tables back to it. > > > > Please test the query again then. > > > > There have been lots of bug fixes since 3.23.39. It is also possible that > > this is yet another case of Linux table corruption where the cause will > > never be found. > > > > Best regards, > > > > Heikki > > Innobase Oy > > > > >Description: > > See previous bug report > > Mysql crashes when executing simple query: > > mysql> delete from statcache where spamdate < 1028304682; > > ERROR 2013: Lost connection to MySQL server during query > > > > Table def: > > CREATE TABLE statcache ( > > reportid int(10) unsigned NOT NULL default '0', > > spamid int(10) unsigned NOT NULL default '0', > > issueid int(10) unsigned NOT NULL default '0', > > recipid int(10) unsigned NOT NULL default '0', > > spamdate int(10) unsigned NOT NULL default '0', > > type tinyint(3) unsigned NOT NULL default '0', > > PRIMARY KEY (reportid), > > KEY date (spamdate), > > KEY dr (recipid,type,spamdate), > > KEY di (issueid,type,spamdate) > > ) TYPE=InnoDB; > > > > I can provide table contents if needed. I'll dump it now so we have a > > snapshot > > of the problematic data. > > > > mysqld got signal 11; > > This could be because you hit a bug. It is also possible that this binary > > or one of the libraries it was linked against is corrupt, improperly built, > > or misconfigured. This error can also be caused by malfunctioning hardware. > > We will try our best to scrape up some info that will hopefully help > > diagnose > > the problem, but since we have already crashed, something is definitely > > wrong > > and this may fail. > > > > key_buffer_size=402649088 > > record_buffer=2093056 > > sort_buffer=2097144 > > max_used_connections=50 > > max_connections=100 > > threads_connected=10 > > It is possible that mysqld could use up to > > key_buffer_size + (record_buffer + sort_buffer)*max_connections = 802411 K > > bytes of memory > > Hope that's ok; if not, decrease some variables in the equation. > > > > thd=0x8720c8a8 > > Attempting backtrace. You can use the following information to find out > > where mysqld died. If you see no messages after this, something went > > terribly wrong... > > Cannot determine thread, fp=0xbfc7e2f8, backtrace may not be correct. > > Stack range sanity check OK, backtrace follows: > > 0x8071b58 + 134683480 > > 0x825a668 + 136685160 > > 0x81737bf + 135739327 > > 0x816f5bd + 135722429 > > 0x815960e + 135632398 > > 0x812a29b + 135439003 > > 0x8135131 + 135483697 > > 0x8136142 + 135487810 > > 0x8136332 + 135488306 > > 0x8122a7d + 135408253 > > 0x80c91ad + 135041453 > > 0x80a6c41 + 134900801 > > 0x807bad0 + 134724304 > > 0x807d955 + 134732117 > > 0x8078ed3 + 134713043 > > 0x807ece1 + 134737121 > > 0x80780ae + 134709422 > > 0x8257c7c + 136674428 > > 0x828d3ba + 136893370 > > New value of fp=(nil) failed sanity check, terminating stack trace! > > Please read http://www.mysql.com/doc/U/s/Using_stack_trace.html and follow > > instructions > > on how to resolve the stack trace. Resolved > > stack trace is much more helpful in diagnosing the problem, so please do > > resolve it > > Trying to get some variables. > > Some pointers may be invalid and cause the dump to abort... > > thd->query at 0x84e8788 = delete from statcache where spamdate < 1028304682 > > thd->thread_id=806 > > > > Successfully dumped variables, if you ran with --log, take a look at the > > details of what thread 806 did to cause the crash. In some cases of really > > bad corruption, the values shown above may be invalid. > > > > The manual page at http://www.mysql.com/doc/C/r/Crashing.html contains > > information that should help you find out what is causing the crash. > > > > Number of processes running now: 0 > > > > >How-To-Repeat: > > See above. > > >Fix: > > Still working on a workaround. Will have to set up a non-production server > > to > > bang on. > > > > >Submitter-Id: <submitter ID> > > >Originator: > > >Organization: > > spamcop.net (Julian Haight) > > >MySQL support: licence > > >Synopsis: MySQL crashes on simple 'delete from' query > > >Severity: serious > > >Priority: medium > > >Category: mysql > > >Class: sw-bug > > >Release: mysql-3.23.39 (Source distribution) > > > > >Environment: > > > > System: Linux sandyman 2.4.18 #8 SMP Thu Jul 18 18:24:01 EDT 2002 i686 > > unknown > > Architecture: i686 > > > > Some paths: /usr/bin/perl /usr/bin/make /usr/bin/gmake /usr/bin/gcc > > /usr/bin/cc > > GCC: Reading specs from /usr/lib/gcc-lib/i386-slackware-linux/2.95.3/specs > > gcc version 2.95.3 20010315 (release) > > Compilation info: CC='gcc' CFLAGS='' CXX='c++' CXXFLAGS='' LDFLAGS='' > > LIBC: > > lrwxrwxrwx 1 root root 13 Mar 19 12:57 /lib/libc.so.6 -> > > libc-2.2.3.so > > -rwxr-xr-x 1 root root 4783716 May 25 2001 /lib/libc-2.2.3.so > > -rw-r--r-- 1 root root 24721042 May 25 2001 /usr/lib/libc.a > > -rw-r--r-- 1 root root 178 May 25 2001 /usr/lib/libc.so > > Configure command: > > ./configure --prefix=/usr --with-mysqld-user=mysql --with-unix-socket-path= > > /var/run/mysql/mysql.sock > > --localstatedir=/var/lib/mysql --with-pthread --enable-thread-safe-client -- > > enable-assembler > > --with-raid --with-libwrap --without-bench i386-slackware-linux > > > > > > > > > > > > --------------------------------------------------------------------- > > Before posting, please check: > > http://www.mysql.com/manual.php (the manual) > > http://lists.mysql.com/ (the list archive) > > > > To request this thread, e-mail <[EMAIL PROTECTED]> > > To unsubscribe, e-mail <[EMAIL PROTECTED]> > > Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php > > > > Sincerely, > > William Mussatto, Senior Systems Engineer > CyberStrategies, Inc > ph. 909-920-9154 ext. 27 > --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
