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=8388608 read_buffer_size=1044480 max_used_connections=430 max_connections=500 threads_connected=122 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 1030188 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xaf73ae40 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=0xad2ce528, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x81214d8 0xb7fa4420 0x5dc 0x821ac04 0x81a1bf4 0x8199ced 0x81904e0 0x81957da 0x8165d85 0x815faa9 0x81578d1 0x8103409 0x80fff84 0x8100ba7 0x80e276d 0x80e7855 0x8165d41 0x815faa9 0x81578d1 0x8158448 0x8154cc1 0x8133a45 0x8138c9e 0x81325e9 0x813222e 0x8131a25 0xb7f8db63 0xb7ec618a New value of fp=(nil) 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 0xac20e718 is invalid pointer thd->thread_id=2140552 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. 061206 12:15:01 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... 061206 12:15:01 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 2 2402975780. InnoDB: Doing recovery: scanned up to log sequence number 2 2402993009 061206 12:15:01 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 117590380, file name magic-sql-bin.000378 061206 12:15:02 InnoDB: Flushing modified pages from the buffer pool... 061206 12:15:02 InnoDB: Started; log sequence number 2 2402993009 /usr/local/mysql/bin/mysqld: ready for connections. Version: '4.1.18-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) 061206 12:15:02 [Note] Slave SQL thread initialized, starting replication in log 'magic-sql-bin.000378' at position 117590143, relay log './magic-sql2-relay-bin.000027' position: 117451832 061206 12:15:02 [Note] Slave I/O thread: connected to master 'replicat@magic-sql.echo-net.net:3306', replication started in log 'magic-sql-bin.000378' at position 117591655 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=8388608 read_buffer_size=1044480 max_used_connections=430 max_connections=500 threads_connected=122 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 1030188 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xaf73ae40 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=0xad2ce528, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x81214d8 0xb7fa4420 0x5dc 0x821ac04 0x81a1bf4 0x8199ced 0x81904e0 0x81957da 0x8165d85 0x815faa9 0x81578d1 0x8103409 0x80fff84 0x8100ba7 0x80e276d 0x80e7855 0x8165d41 0x815faa9 0x81578d1 0x8158448 0x8154cc1 0x8133a45 0x8138c9e 0x81325e9 0x813222e 0x8131a25 0xb7f8db63 0xb7ec618a New value of fp=(nil) 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 0xac20e718 is invalid pointer thd->thread_id=2140552 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. 061206 12:15:01 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... 061206 12:15:01 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 2 2402975780. InnoDB: Doing recovery: scanned up to log sequence number 2 2402993009 061206 12:15:01 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 117590380, file name magic-sql-bin.000378 061206 12:15:02 InnoDB: Flushing modified pages from the buffer pool... 061206 12:15:02 InnoDB: Started; log sequence number 2 2402993009 /usr/local/mysql/bin/mysqld: ready for connections. Version: '4.1.18-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) 061206 12:15:02 [Note] Slave SQL thread initialized, starting replication in log 'magic-sql-bin.000378' at position 117590143, relay log './magic-sql2-relay-bin.000027' position: 117451832 061206 12:15:02 [Note] Slave I/O thread: connected to master 'replicat@magic-sql.echo-net.net:3306', replication started in log 'magic-sql-bin.000378' at position 117591655 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=8388608 read_buffer_size=1044480 max_used_connections=331 max_connections=500 threads_connected=281 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 1030188 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xaf5d0de0 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=0xae76e508, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x81214d8 0xb7f38420 0xa 0x821ac04 0x81a1bf4 0x8199ced 0x81904e0 0x81957da 0x8166b0b 0x8165ca5 0x815faa9 0x81578d1 0x8103409 0x80fff84 0x8100ba7 0x80e276d 0x80e7855 0x8165d41 0x815faa9 0x81578d1 0x8158448 0x8154cc1 0x8133a45 0x8138c9e 0x81325e9 0x813222e 0x8131a25 0xb7f21b63 0xb7e5a18a New value of fp=(nil) 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 0x8dd8050 = select ID_USER, LOGIN, OTFA_HASH, US_CREATED_BY from APPUSER where OTFA_HASH is not null and US_STATUS <> 'K' and not exists (select UN.ID_USER from USER_NOTIFICATION UN, NOTIFICATION N where UN.ID_USER = APPUSER.ID_USER and UN.ID_NOTIFICATION = N.ID_NOTIFICATION and N.ID_MAIL in (3, 5)) thd->thread_id=185741 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. 061207 5:40:03 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... 061207 5:40:03 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 2 2696735925. InnoDB: Doing recovery: scanned up to log sequence number 2 2697235943 061207 5:40:03 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 576391708, file name magic-sql-bin.000378 061207 5:40:04 InnoDB: Flushing modified pages from the buffer pool... 061207 5:40:04 InnoDB: Started; log sequence number 2 2697235943 /usr/local/mysql/bin/mysqld: ready for connections. Version: '4.1.18-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) 061207 5:40:04 [Note] Slave SQL thread initialized, starting replication in log 'magic-sql-bin.000378' at position 576391612, relay log './magic-sql2-relay-bin.000028' position: 458800008 061207 5:40:04 [Note] Slave I/O thread: connected to master 'replicat@magic-sql.echo-net.net:3306', replication started in log 'magic-sql-bin.000378' at position 576419707 061207 5:40:04 [ERROR] Slave: Error 'Duplicate entry '1059232-21030726-1' for key 1' on query. Default database: 'magic4'. Query: 'insert into NOTIF_PUBLICATION values (1059232, 21030726, 1)', Error_code: 1062 061207 5:40:04 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'magic-sql-bin.000378' position 576391612 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=8388608 read_buffer_size=1044480 max_used_connections=430 max_connections=500 threads_connected=122 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 1030188 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xaf73ae40 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=0xad2ce528, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x81214d8 0xb7fa4420 0x5dc 0x821ac04 0x81a1bf4 0x8199ced 0x81904e0 0x81957da 0x8165d85 0x815faa9 0x81578d1 0x8103409 0x80fff84 0x8100ba7 0x80e276d 0x80e7855 0x8165d41 0x815faa9 0x81578d1 0x8158448 0x8154cc1 0x8133a45 0x8138c9e 0x81325e9 0x813222e 0x8131a25 0xb7f8db63 0xb7ec618a New value of fp=(nil) 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 0xac20e718 is invalid pointer thd->thread_id=2140552 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. 061206 12:15:01 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... 061206 12:15:01 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 2 2402975780. InnoDB: Doing recovery: scanned up to log sequence number 2 2402993009 061206 12:15:01 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 117590380, file name magic-sql-bin.000378 061206 12:15:02 InnoDB: Flushing modified pages from the buffer pool... 061206 12:15:02 InnoDB: Started; log sequence number 2 2402993009 /usr/local/mysql/bin/mysqld: ready for connections. Version: '4.1.18-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) 061206 12:15:02 [Note] Slave SQL thread initialized, starting replication in log 'magic-sql-bin.000378' at position 117590143, relay log './magic-sql2-relay-bin.000027' position: 117451832 061206 12:15:02 [Note] Slave I/O thread: connected to master 'replicat@magic-sql.echo-net.net:3306', replication started in log 'magic-sql-bin.000378' at position 117591655 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=8388608 read_buffer_size=1044480 max_used_connections=331 max_connections=500 threads_connected=281 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 1030188 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xaf5d0de0 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=0xae76e508, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x81214d8 0xb7f38420 0xa 0x821ac04 0x81a1bf4 0x8199ced 0x81904e0 0x81957da 0x8166b0b 0x8165ca5 0x815faa9 0x81578d1 0x8103409 0x80fff84 0x8100ba7 0x80e276d 0x80e7855 0x8165d41 0x815faa9 0x81578d1 0x8158448 0x8154cc1 0x8133a45 0x8138c9e 0x81325e9 0x813222e 0x8131a25 0xb7f21b63 0xb7e5a18a New value of fp=(nil) 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 0x8dd8050 = select ID_USER, LOGIN, OTFA_HASH, US_CREATED_BY from APPUSER where OTFA_HASH is not null and US_STATUS <> 'K' and not exists (select UN.ID_USER from USER_NOTIFICATION UN, NOTIFICATION N where UN.ID_USER = APPUSER.ID_USER and UN.ID_NOTIFICATION = N.ID_NOTIFICATION and N.ID_MAIL in (3, 5)) thd->thread_id=185741 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. 061207 5:40:03 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... 061207 5:40:03 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 2 2696735925. InnoDB: Doing recovery: scanned up to log sequence number 2 2697235943 061207 5:40:03 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 576391708, file name magic-sql-bin.000378 061207 5:40:04 InnoDB: Flushing modified pages from the buffer pool... 061207 5:40:04 InnoDB: Started; log sequence number 2 2697235943 /usr/local/mysql/bin/mysqld: ready for connections. Version: '4.1.18-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) 061207 5:40:04 [Note] Slave SQL thread initialized, starting replication in log 'magic-sql-bin.000378' at position 576391612, relay log './magic-sql2-relay-bin.000028' position: 458800008 061207 5:40:04 [Note] Slave I/O thread: connected to master 'replicat@magic-sql.echo-net.net:3306', replication started in log 'magic-sql-bin.000378' at position 576419707 061207 5:40:04 [ERROR] Slave: Error 'Duplicate entry '1059232-21030726-1' for key 1' on query. Default database: 'magic4'. Query: 'insert into NOTIF_PUBLICATION values (1059232, 21030726, 1)', Error_code: 1062 061207 5:40:04 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'magic-sql-bin.000378' position 576391612 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=8388608 read_buffer_size=1044480 max_used_connections=133 max_connections=500 threads_connected=133 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 1030188 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xb19eca90 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=0xb149e508, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x81214d8 0xb7ef6420 0xa 0x821ac04 0x81a1bf4 0x8199ced 0x81904e0 0x81957da 0x8166b0b 0x8165ca5 0x815faa9 0x81578d1 0x8103409 0x80fff84 0x8100ba7 0x80e276d 0x80e7855 0x8165d41 0x815faa9 0x81578d1 0x8158448 0x8154cc1 0x8133a45 0x8138c9e 0x81325e9 0x813222e 0x8131a25 0xb7edfb63 0xb7e1818a New value of fp=(nil) 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 0x8b69bd0 = select ID_USER, LOGIN, OTFA_HASH, US_CREATED_BY from APPUSER where OTFA_HASH is not null and US_STATUS <> 'K' and not exists (select UN.ID_USER from USER_NOTIFICATION UN, NOTIFICATION N where UN.ID_USER = APPUSER.ID_USER and UN.ID_NOTIFICATION = N.ID_NOTIFICATION and N.ID_MAIL in (3, 5)) thd->thread_id=360 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. 061207 5:45:02 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... 061207 5:45:02 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 2 2697266838. InnoDB: Doing recovery: scanned up to log sequence number 2 2697266868 InnoDB: In a MySQL replication slave the last master binlog file InnoDB: position 0 576391708, file name magic-sql-bin.000378 061207 5:45:02 InnoDB: Flushing modified pages from the buffer pool... 061207 5:45:02 InnoDB: Started; log sequence number 2 2697266868 /usr/local/mysql/bin/mysqld: ready for connections. Version: '4.1.18-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) 061207 5:45:02 [Note] Slave SQL thread initialized, starting replication in log 'magic-sql-bin.000378' at position 576391612, relay log './magic-sql2-relay-bin.000028' position: 458800008 061207 5:45:02 [Note] Slave I/O thread: connected to master 'replicat@magic-sql.echo-net.net:3306', replication started in log 'magic-sql-bin.000378' at position 576859096 061207 5:45:02 [ERROR] Slave: Error 'Duplicate entry '1059232-21030726-1' for key 1' on query. Default database: 'magic4'. Query: 'insert into NOTIF_PUBLICATION values (1059232, 21030726, 1)', Error_code: 1062 061207 5:45:02 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'magic-sql-bin.000378' position 576391612 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=8388608 read_buffer_size=1044480 max_used_connections=41 max_connections=500 threads_connected=38 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 1030188 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xb1713a78 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=0xb1b7e508, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x81214d8 0xb7eec420 0xa 0x821ac04 0x81a1bf4 0x8199ced 0x81904e0 0x81957da 0x8166b0b 0x8165ca5 0x815faa9 0x81578d1 0x8103409 0x80fff84 0x8100ba7 0x80e276d 0x80e7855 0x8165d41 0x815faa9 0x81578d1 0x8158448 0x8154cc1 0x8133a45 0x8138c9e 0x81325e9 0x813222e 0x8131a25 0xb7ed5b63 0xb7e0e18a New value of fp=(nil) 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 0x8b01ba0 = select ID_USER, LOGIN, OTFA_HASH, US_CREATED_BY from APPUSER where OTFA_HASH is not null and US_STATUS <> 'K' and not exists (select UN.ID_USER from USER_NOTIFICATION UN, NOTIFICATION N where UN.ID_USER = APPUSER.ID_USER and UN.ID_NOTIFICATION = N.ID_NOTIFICATION and N.ID_MAIL in (3, 5)) thd->thread_id=182 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. 061207 5:50:18 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... 061207 5:50:18 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 2 2697267384. InnoDB: Doing recovery: scanned up to log sequence number 2 2697267424 InnoDB: In a MySQL replication slave the last master binlog file InnoDB: position 0 576391708, file name magic-sql-bin.000378 061207 5:50:18 InnoDB: Flushing modified pages from the buffer pool... 061207 5:50:18 InnoDB: Started; log sequence number 2 2697267424 /usr/local/mysql/bin/mysqld: ready for connections. Version: '4.1.18-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) 061207 5:50:18 [Note] Slave SQL thread initialized, starting replication in log 'magic-sql-bin.000378' at position 576391612, relay log './magic-sql2-relay-bin.000028' position: 458800008 061207 5:50:18 [Note] Slave I/O thread: connected to master 'replicat@magic-sql.echo-net.net:3306', replication started in log 'magic-sql-bin.000378' at position 577335046 061207 5:50:18 [ERROR] Slave: Error 'Duplicate entry '1059232-21030726-1' for key 1' on query. Default database: 'magic4'. Query: 'insert into NOTIF_PUBLICATION values (1059232, 21030726, 1)', Error_code: 1062 061207 5:50:18 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'magic-sql-bin.000378' position 576391612 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=8388608 read_buffer_size=1044480 max_used_connections=430 max_connections=500 threads_connected=122 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 1030188 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xaf73ae40 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=0xad2ce528, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x81214d8 0xb7fa4420 0x5dc 0x821ac04 0x81a1bf4 0x8199ced 0x81904e0 0x81957da 0x8165d85 0x815faa9 0x81578d1 0x8103409 0x80fff84 0x8100ba7 0x80e276d 0x80e7855 0x8165d41 0x815faa9 0x81578d1 0x8158448 0x8154cc1 0x8133a45 0x8138c9e 0x81325e9 0x813222e 0x8131a25 0xb7f8db63 0xb7ec618a New value of fp=(nil) 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 0xac20e718 is invalid pointer thd->thread_id=2140552 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. 061206 12:15:01 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... 061206 12:15:01 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 2 2402975780. InnoDB: Doing recovery: scanned up to log sequence number 2 2402993009 061206 12:15:01 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 117590380, file name magic-sql-bin.000378 061206 12:15:02 InnoDB: Flushing modified pages from the buffer pool... 061206 12:15:02 InnoDB: Started; log sequence number 2 2402993009 /usr/local/mysql/bin/mysqld: ready for connections. Version: '4.1.18-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) 061206 12:15:02 [Note] Slave SQL thread initialized, starting replication in log 'magic-sql-bin.000378' at position 117590143, relay log './magic-sql2-relay-bin.000027' position: 117451832 061206 12:15:02 [Note] Slave I/O thread: connected to master 'replicat@magic-sql.echo-net.net:3306', replication started in log 'magic-sql-bin.000378' at position 117591655 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=8388608 read_buffer_size=1044480 max_used_connections=331 max_connections=500 threads_connected=281 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 1030188 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xaf5d0de0 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=0xae76e508, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x81214d8 0xb7f38420 0xa 0x821ac04 0x81a1bf4 0x8199ced 0x81904e0 0x81957da 0x8166b0b 0x8165ca5 0x815faa9 0x81578d1 0x8103409 0x80fff84 0x8100ba7 0x80e276d 0x80e7855 0x8165d41 0x815faa9 0x81578d1 0x8158448 0x8154cc1 0x8133a45 0x8138c9e 0x81325e9 0x813222e 0x8131a25 0xb7f21b63 0xb7e5a18a New value of fp=(nil) 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 0x8dd8050 = select ID_USER, LOGIN, OTFA_HASH, US_CREATED_BY from APPUSER where OTFA_HASH is not null and US_STATUS <> 'K' and not exists (select UN.ID_USER from USER_NOTIFICATION UN, NOTIFICATION N where UN.ID_USER = APPUSER.ID_USER and UN.ID_NOTIFICATION = N.ID_NOTIFICATION and N.ID_MAIL in (3, 5)) thd->thread_id=185741 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. 061207 5:40:03 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... 061207 5:40:03 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 2 2696735925. InnoDB: Doing recovery: scanned up to log sequence number 2 2697235943 061207 5:40:03 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 576391708, file name magic-sql-bin.000378 061207 5:40:04 InnoDB: Flushing modified pages from the buffer pool... 061207 5:40:04 InnoDB: Started; log sequence number 2 2697235943 /usr/local/mysql/bin/mysqld: ready for connections. Version: '4.1.18-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) 061207 5:40:04 [Note] Slave SQL thread initialized, starting replication in log 'magic-sql-bin.000378' at position 576391612, relay log './magic-sql2-relay-bin.000028' position: 458800008 061207 5:40:04 [Note] Slave I/O thread: connected to master 'replicat@magic-sql.echo-net.net:3306', replication started in log 'magic-sql-bin.000378' at position 576419707 061207 5:40:04 [ERROR] Slave: Error 'Duplicate entry '1059232-21030726-1' for key 1' on query. Default database: 'magic4'. Query: 'insert into NOTIF_PUBLICATION values (1059232, 21030726, 1)', Error_code: 1062 061207 5:40:04 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'magic-sql-bin.000378' position 576391612 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=8388608 read_buffer_size=1044480 max_used_connections=133 max_connections=500 threads_connected=133 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 1030188 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xb19eca90 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=0xb149e508, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x81214d8 0xb7ef6420 0xa 0x821ac04 0x81a1bf4 0x8199ced 0x81904e0 0x81957da 0x8166b0b 0x8165ca5 0x815faa9 0x81578d1 0x8103409 0x80fff84 0x8100ba7 0x80e276d 0x80e7855 0x8165d41 0x815faa9 0x81578d1 0x8158448 0x8154cc1 0x8133a45 0x8138c9e 0x81325e9 0x813222e 0x8131a25 0xb7edfb63 0xb7e1818a New value of fp=(nil) 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 0x8b69bd0 = select ID_USER, LOGIN, OTFA_HASH, US_CREATED_BY from APPUSER where OTFA_HASH is not null and US_STATUS <> 'K' and not exists (select UN.ID_USER from USER_NOTIFICATION UN, NOTIFICATION N where UN.ID_USER = APPUSER.ID_USER and UN.ID_NOTIFICATION = N.ID_NOTIFICATION and N.ID_MAIL in (3, 5)) thd->thread_id=360 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. 061207 5:45:02 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... 061207 5:45:02 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 2 2697266838. InnoDB: Doing recovery: scanned up to log sequence number 2 2697266868 InnoDB: In a MySQL replication slave the last master binlog file InnoDB: position 0 576391708, file name magic-sql-bin.000378 061207 5:45:02 InnoDB: Flushing modified pages from the buffer pool... 061207 5:45:02 InnoDB: Started; log sequence number 2 2697266868 /usr/local/mysql/bin/mysqld: ready for connections. Version: '4.1.18-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) 061207 5:45:02 [Note] Slave SQL thread initialized, starting replication in log 'magic-sql-bin.000378' at position 576391612, relay log './magic-sql2-relay-bin.000028' position: 458800008 061207 5:45:02 [Note] Slave I/O thread: connected to master 'replicat@magic-sql.echo-net.net:3306', replication started in log 'magic-sql-bin.000378' at position 576859096 061207 5:45:02 [ERROR] Slave: Error 'Duplicate entry '1059232-21030726-1' for key 1' on query. Default database: 'magic4'. Query: 'insert into NOTIF_PUBLICATION values (1059232, 21030726, 1)', Error_code: 1062 061207 5:45:02 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'magic-sql-bin.000378' position 576391612 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=8388608 read_buffer_size=1044480 max_used_connections=41 max_connections=500 threads_connected=38 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 1030188 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xb1713a78 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=0xb1b7e508, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x81214d8 0xb7eec420 0xa 0x821ac04 0x81a1bf4 0x8199ced 0x81904e0 0x81957da 0x8166b0b 0x8165ca5 0x815faa9 0x81578d1 0x8103409 0x80fff84 0x8100ba7 0x80e276d 0x80e7855 0x8165d41 0x815faa9 0x81578d1 0x8158448 0x8154cc1 0x8133a45 0x8138c9e 0x81325e9 0x813222e 0x8131a25 0xb7ed5b63 0xb7e0e18a New value of fp=(nil) 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 0x8b01ba0 = select ID_USER, LOGIN, OTFA_HASH, US_CREATED_BY from APPUSER where OTFA_HASH is not null and US_STATUS <> 'K' and not exists (select UN.ID_USER from USER_NOTIFICATION UN, NOTIFICATION N where UN.ID_USER = APPUSER.ID_USER and UN.ID_NOTIFICATION = N.ID_NOTIFICATION and N.ID_MAIL in (3, 5)) thd->thread_id=182 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. 061207 5:50:18 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... 061207 5:50:18 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 2 2697267384. InnoDB: Doing recovery: scanned up to log sequence number 2 2697267424 InnoDB: In a MySQL replication slave the last master binlog file InnoDB: position 0 576391708, file name magic-sql-bin.000378 061207 5:50:18 InnoDB: Flushing modified pages from the buffer pool... 061207 5:50:18 InnoDB: Started; log sequence number 2 2697267424 /usr/local/mysql/bin/mysqld: ready for connections. Version: '4.1.18-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) 061207 5:50:18 [Note] Slave SQL thread initialized, starting replication in log 'magic-sql-bin.000378' at position 576391612, relay log './magic-sql2-relay-bin.000028' position: 458800008 061207 5:50:18 [Note] Slave I/O thread: connected to master 'replicat@magic-sql.echo-net.net:3306', replication started in log 'magic-sql-bin.000378' at position 577335046 061207 5:50:18 [ERROR] Slave: Error 'Duplicate entry '1059232-21030726-1' for key 1' on query. Default database: 'magic4'. Query: 'insert into NOTIF_PUBLICATION values (1059232, 21030726, 1)', Error_code: 1062 061207 5:50:18 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'magic-sql-bin.000378' position 576391612 061207 6:08:32 [ERROR] Slave I/O thread killed while reading event 061207 6:08:32 [ERROR] Slave I/O thread exiting, read up to log 'magic-sql-bin.000378', position 578238748 061207 6:09:03 [Note] Slave SQL thread initialized, starting replication in log 'magic-sql-bin.000378' at position 576391612, relay log './magic-sql2-relay-bin.000028' position: 458800008 061207 6:09:03 [Note] Slave I/O thread: connected to master 'replicat@magic-sql.echo-net.net:3306', replication started in log 'magic-sql-bin.000378' at position 578238748