Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Please see the log below and make out the reason behind abrupt MySQL restart?

110324 17:19:37 - 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=2097152 read_buffer_size=2093056 max_used_connections=155 max_connections=800 threads_connected=105 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 3275641 K bytes of memory Hope that's ok; if not, decrease some variables in the equation.

thd=0x21525240 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=0x46946088, backtrace may not be correct. Stack range sanity check OK, backtrace follows: (nil) New value of fp=0x21525240 failed sanity check, terminating stack trace! Please read http://dev.mysql.com/doc/mysql/en/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 0x2aab98514ee0 is invalid pointer thd->thread_id=3133802 The manual page at http://www.mysql.com/doc/en/Crashing.html contains information that should help you find out what is causing the crash.

Number of processes running now: 0 110324 17:19:37 mysqld restarted 110324 17:19:37 [Warning] The syntax for replication startup options is deprecated and will be removed in MySQL 5.2. Please use 'CHANGE MASTER' instead. 110324 17:19:38 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... 110324 17:19:42 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 75 131221842. InnoDB: Doing recovery: scanned up to log sequence number 75 132702399 110324 17:19:43 InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed InnoDB: In a MySQL replication slave the last master binlog file InnoDB: position 0 232, file name lalithamba-bin.003081 InnoDB: Last MySQL binlog file position 0 31496822, file name /data/db/MySql_5.0.41/log/mysql_repl_log/amritamba-bin.009607 110324 17:19:49 InnoDB: Started; log sequence number 75 132702399 110324 17:19:49 [Note] Recovering after a crash using /data/db/MySql_5.0.41/log/mysql_repl_log/amritamba-bin 110324 17:19:50 [Note] Starting crash recovery... 110324 17:19:50 [Note] Crash recovery finished. 110324 17:19:51 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.41-log' socket: '/data/db/MySql_5.0.41/mysql.sock' port: 3306 MySQL Community Server (GPL) 110324 17:56:48 [Note] /usr/local/mysql/bin/mysqld: Normal shutdown

110324 17:56:50 InnoDB: Starting shutdown... 110324 17:56:53 InnoDB: Shutdown completed; log sequence number 75 132702778 110324 17:56:53 [Note] /usr/local/mysql/bin/mysqld: Shutdown complete

110324 17:56:53 mysqld ended

110324 17:56:56 mysqld started 110324 17:56:56 [Warning] The syntax for replication startup options is deprecated and will be removed in MySQL 5.2. Please use 'CHANGE MASTER' instead. 110324 17:56:58 InnoDB: Started; log sequence number 75 132702778 110324 17:56:58 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.41-log' socket: '/data/db/MySql_5.0.41/mysql.sock' port: 3306 MySQL Community Server (GPL) 110324 17:57:20 [Note] Slave SQL thread initialized, starting replication in log 'lalithamba-bin.003081' at position 31228372, relay log '/data/db/MySql_5.0.41/log/mysql_repl_log/amritamba_mysql_relaylog.005857' position: 31228514 110324 17:57:20 [Note] Slave I/O thread: connected to master 'ReplSlave@192.168.111.116:3306', replication started in log 'lalithamba-bin.003081' at position 31228372

share|improve this question

migrated from stackoverflow.com Mar 24 '11 at 13:06

This question came from our site for professional and enthusiast programmers.

closed as not a real question by Iain, jscott, Ben Pilbrow, Scott Pack, coredump Mar 24 '11 at 14:43

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

3  
You're not paying me and I'm not working for you. No reason for me to make anything out of this wall of text. –  mauris Mar 24 '11 at 13:02
1  
Maybe you could enlighten us with some troubleshooting steps you've already tried and at least appear to be putting some effort in yourself... –  Ben Pilbrow Mar 24 '11 at 13:38

1 Answer 1

Your memory statistics read close to insane:

key_buffer_size=2097152
read_buffer_size=2093056
max_used_connections=155
max_connections=800
threads_connected=105 

It is possible that mysqld could use up to  key_buffer_size + 
(read_buffer_size +  sort_buffer_size)*max_connections = 
3 275 641 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

That means that at the time of the crash it is not completely unlikely that your mysqld has been killed by the OOM killer or a similar mechanism in your operating system. If that was the case, additional information will be in the kernel message log (not the MySQL log) with the same or a similar timestamp as the crash message (110324 17:19:37 = 24-Mar-2011, 17:19:37 local time).

Also, you should seriously get a review of your MySQL configuration. Not just the memory stuff, your replication configuration also produces startup warnings, and the version you are using (5.0.41) is seriously outdated (current version is two major releases further - 5.5). The version of MySQL you are using was released 01 May 2007, almost 4 years ago.

This has no place in any production configuration whatsoever.

share|improve this answer