mysql got signal 11_mysqld got signal 11

09:05:03 UTC - 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.

Attempting to collect some information that could help diagnose the problem.

As this is a crash and something is definitely wrong, the information

collection process might fail.

Please help us make Percona Server better by reporting any

bugs at http://bugs.percona.com/

key_buffer_size=33554432

read_buffer_size=1048576

max_used_connections=40

max_threads=501

thread_count=9

connection_count=7

It is possible that mysqld could use up to

key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 1063797 K  bytes of memory

Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x7f6a13016000

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...

stack_bottom = 7f6d7b906ce0 thread_stack 0x30000

/usr/local/Percona-Server-5.7.12-5-Linux.x86_64.ssl101/bin/mysqld(my_print_stacktrace+0x2c)[0xec366c]

/usr/local/Percona-Server-5.7.12-5-Linux.x86_64.ssl101/bin/mysqld(handle_fatal_signal+0x461)[0x79cb41]

/lib64/libpthread.so.0[0x38c500f710]

/usr/local/Percona-Server-5.7.12-5-Linux.x86_64.ssl101/bin/mysqld[0xc90635]

/usr/local/Percona-Server-5.7.12-5-Linux.x86_64.ssl101/bin/mysqld(_ZN4JOIN14test_skip_sortEv+0x15d)[0xc913bd]

/usr/local/Percona-Server-5.7.12-5-Linux.x86_64.ssl101/bin/mysqld(_ZN4JOIN8optimizeEv+0x1b53)[0xc9e483]

/usr/local/Percona-Server-5.7.12-5-Linux.x86_64.ssl101/bin/mysqld(_ZN13st_select_lex8optimizeEP3THD+0x685)[0xce3965]

/usr/local/Percona-Server-5.7.12-5-Linux.x86_64.ssl101/bin/mysqld(_Z12handle_queryP3THDP3LEXP12Query_resultyy+0x155)[0xce3b45]

/usr/local/Percona-Server-5.7.12-5-Linux.x86_64.ssl101/bin/mysqld[0x75c26f]

/usr/local/Percona-Server-5.7.12-5-Linux.x86_64.ssl101/bin/mysqld(_Z21mysql_execute_commandP3THDb+0x46ae)[0xca715e]

/usr/local/Percona-Server-5.7.12-5-Linux.x86_64.ssl101/bin/mysqld(_Z11mysql_parseP3THDP12Parser_state+0x5b5)[0xcaa1b5]

/usr/local/Percona-Server-5.7.12-5-Linux.x86_64.ssl101/bin/mysqld(_Z16dispatch_commandP3THDPK8COM_DATA19enum_server_command+0x92f)[0xcaab5f]

/usr/local/Percona-Server-5.7.12-5-Linux.x86_64.ssl101/bin/mysqld(_Z10do_commandP3THD+0x1b7)[0xcac4f7]

/usr/local/Percona-Server-5.7.12-5-Linux.x86_64.ssl101/bin/mysqld(handle_connection+0x2a8)[0xd6d468]

/usr/local/Percona-Server-5.7.12-5-Linux.x86_64.ssl101/bin/mysqld(pfs_spawn_thread+0x1b4)[0xf39164]

/lib64/libpthread.so.0[0x38c50079d1]

/lib64/libc.so.6(clone+0x6d)[0x35636e8b6d]

Trying to get some variables.

Some pointers may be invalid and cause the dump to abort.

Query (7f6a13367030): is an invalid pointer

Connection ID (thread ID): 83119

Status: NOT_KILLED

You may download the Percona Server operations manual by visiting

http://www.percona.com/software/percona-server/. You may find information

in the manual which will help you identify the cause of the crash.

2017-03-21T09:05:03.697135Z mysqld_safe Number of processes running now: 0

2017-03-21T09:05:03.698458Z mysqld_safe mysqld restarted

2017-03-21T09:05:03.878082Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).

2017-03-21T09:05:03.878174Z 0 [Warning] Insecure configuration for --secure-file-priv: Current value does not restrict location of generated files. Consider setting it to a valid, non-empty path.

2017-03-21T09:05:03.878211Z 0 [Note] /usr/local/Percona-Server-5.7.12-5-Linux.x86_64.ssl101/bin/mysqld (mysqld 5.7.12-5-log) starting as process 7000 ...

2017-03-21T09:05:03.883671Z 0 [Note] InnoDB: PUNCH HOLE support available

2017-03-21T09:05:03.883696Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins

2017-03-21T09:05:03.883713Z 0 [Note] InnoDB: Uses event mutexes

2017-03-21T09:05:03.883717Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier

2017-03-21T09:05:03.883721Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.3

2017-03-21T09:05:03.883725Z 0 [Note] InnoDB: Using Linux native AIO

2017-03-21T09:05:03.884396Z 0 [Note] InnoDB: Number of pools: 1

2017-03-21T09:05:03.884481Z 0 [Note] InnoDB: Using CPU crc32 instructions

2017-03-21T09:05:04.037706Z 0 [Note] InnoDB: Initializing buffer pool, total size = 12G, instances = 8, chunk size = 128M

2017-03-21T09:05:04.365943Z 0 [Note] InnoDB: Completed initialization of buffer pool

2017-03-21T09:05:04.469139Z 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().

2017-03-21T09:05:04.471073Z 0 [Note] InnoDB: Recovering partial pages from the parallel doublewrite buffer at /data/var/xb_doublewrite

2017-03-21T09:05:04.499303Z 0 [Note] InnoDB: Highest supported file format is Barracuda.

2017-03-21T09:05:04.565854Z 0 [Note] InnoDB: Log scan progressed past the checkpoint lsn 88951119468

2017-03-21T09:05:04.658262Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 88956362240

2017-03-21T09:05:04.744173Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 88961605120

2017-03-21T09:05:04.826703Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 88966848000

2017-03-21T09:05:04.911678Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 88972090880

2017-03-21T09:05:04.999084Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 88977333760

2017-03-21T09:05:05.083839Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence numb

......

......

后来查到是一个sql的问题！

发现过程是这样的，本来90 和 97 是一对master/slave ，运行了半年一切正常，突然某一天slave机器日志里面有这个报警，开始研发人员怀疑是slave机器的系统或mysql有问题，让我们来重做系统，先将读写都切换到master，结果master上也出现了上面的问题，我随即就猜到是sql的问题了，后来确认了就是sql的问题，只要是那个sql一运行，mysql日志里面就会有上面的输出！

修改sql后，机器恢复正常！

阅读(850) | 评论(0) | 转发(0) |