Chinaunix首页 | 论坛 | 博客
  • 博客访问: 2749059
  • 博文数量: 587
  • 博客积分: 6356
  • 博客等级: 准将
  • 技术积分: 6410
  • 用 户 组: 普通用户
  • 注册时间: 2008-10-23 10:54
个人简介

器量大者,福泽必厚

文章分类

全部博文(587)

文章存档

2019年(3)

2018年(1)

2017年(29)

2016年(39)

2015年(66)

2014年(117)

2013年(136)

2012年(58)

2011年(34)

2010年(50)

2009年(38)

2008年(16)

分类: LINUX

2017-03-29 20:12:28

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


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
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后,机器恢复正常!
阅读(1838) | 评论(0) | 转发(0) |
0

上一篇:js被劫持导致打开异常

下一篇:zabbix死掉

给主人留下些什么吧!~~