Interesting innodb activity with 3.23.52
Hi, We experienced some interesting things when we upgraded to Mysql-Max 3.23.52 (Red Hat 7.1, 2.4.7-10enterprise). It looked like after a sustained amount of large disk activity, the whole system would slow to a crawl and CPU idle % would go down to 0 for about 30 seconds before it popped back. We tried fiddling around with the configuration files and even tried another kernel (2.4.9-34enterprise) but without any luck. What did work was downgrading our MySQL version to 3.23.49a . Once we downgraded, everything worked fine. Has anyone seen anything like this before? Ideally we'd like to take advantage of all the changes made between .49a and .52. Adrian Liang Em: [EMAIL PROTECTED] - 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
RE: Interesting innodb activity with 3.23.52
Thanks Heikki, Is there an easy way for me to see which version of glibc a particular RPM was compiled against? Adrian Liang Em: [EMAIL PROTECTED] -Original Message- From: Heikki Tuuri [mailto:[EMAIL PROTECTED]] Sent: Saturday, September 21, 2002 1:34 PM To: [EMAIL PROTECTED] Subject: Re: Interesting innodb activity with 3.23.52 Adrian, - Original Message - From: ""Adrian Liang"" <[EMAIL PROTECTED]> Newsgroups: mailing.database.mysql Sent: Saturday, September 21, 2002 6:48 AM Subject: Interesting innodb activity with 3.23.52 > > Hi, > > We experienced some interesting things when we upgraded to Mysql-Max > 3.23.52 (Red Hat 7.1, 2.4.7-10enterprise). It looked like after a > sustained amount of large disk activity, the whole system would slow > to a crawl and CPU idle % would go down to 0 for about 30 seconds > before it popped back. We tried fiddling around with the configuration > files and even tried another kernel (2.4.9-34enterprise) but without > any luck. What did work was downgrading our MySQL version to 3.23.49a > . Once we downgraded, everything worked fine. > > Has anyone seen anything like this before? Ideally we'd like to take > advantage of all the changes made between .49a and .52. this sounds like the well-known 'thread thrashing' problem in Linux. It also occurs with MyISAM tables. CPU usage increases 100-fold to normal. Small changes in glibc seem to affect this. Some users have got a good version by compiling themselves and linking with the glibc on their own computer. The new Linux O(1) thread schedulers may solve this problem. > Adrian Liang > Em: [EMAIL PROTECTED] Best regards, Heikki Tuuri Innobase Oy --- Order technical MySQL/InnoDB support at https://order.mysql.com/ See http://www.innodb.com for the online manual and latest news on InnoDB sql query - 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 - 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
how to recover innodb tables
Hi, Recently my MySQL (3.23.52-max) db crashed. Although I'm still trying to debug what happened, the bigger issue is for me to get the data out of there as soon as possible. I thought that by setting the variable innodb_force_recovery would allow the database to come up so I could at least do a "select into outfile" and my data, but it won't start (I've tried values of 4, 5 and 6). What else can I do to get at the data? Thanks! -Adrian uname -a: Linux db1f2 2.4.2-13-p1-psmp-4g #1 SMP Mon Aug 20 13:24:15 PDT 2001 i686 unknown Error log snippet: 021101 03:10:26 mysqld started 021101 3:10:28 InnoDB: Database was not shut down normally. InnoDB: Starting recovery from log files... InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 2 3270822049 InnoDB: Error: trying to access page number 2833 in space 0 InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10 InnoDB: Assertion failure in thread 4096 in file fil0fil.c line 1098 InnoDB: We intentionally generate a memory trap. InnoDB: Send a detailed bug report to [EMAIL PROTECTED] 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 agaist 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=0 max_connections=2000 threads_connected=0 It is possible that mysqld could use up to key_buffer_size + (record_buffer + sort_buffer)*max_connections = 188588 K bytes of memory Hope that's ok, if not, decrease some variables in the equation 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... Bogus stack limit or frame pointer, fp=0xbfffe348, stack_bottom=0x4bb86320, thread _stack=65536, aborting backtrace. Trying to get some variables. Some pointers may be invalid and cause the dump to abort... thd->query at 0x4ae41390 is invalid pointer thd->thread_id=138727560 __ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/ - 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
Replication error?
Hi, I currently have my replication setup with 3 machines as such: A > B > C Machine A just died, so B is now my master. However, I want to re-adjust my setup so it looks like this: B > A > C So what I did was stop C and copy everything over to A. At this point, either A or C should be able to act as a slave reading from B. However, whenever I start A it starts to skip large chunks of the update log. C doesn't seem to have this problem. Does anyone know what is making this happen? Using: 3.23.49a-Max kernel: 2.4.9-34enterprise Thanks, Adrian mysql query __ Do you Yahoo!? U2 on LAUNCH - Exclusive greatest hits videos http://launch.yahoo.com/u2 - 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
