- 积分
- 61
- 威望
-
- 金钱
-
- 注册时间
- 2010-11-29
- 在线时间
- 小时
- 最后登录
- 1970-1-1
|
楼主 |
发表于 2016-7-4 10:08:40
|
显示全部楼层
错误信息。。。
- key_buffer_size=16777216
- read_buffer_size=262144
- max_used_connections=0
- max_threads=151
- thread_count=0
- connection_count=0
- It is possible that mysqld could use up to
- key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 133456 K bytes of memory
- Hope that's ok; if not, decrease some variables in the equation.
- Thread pointer: 0x0
- 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 = 0 thread_stack 0x30000
- /usr/local/mysql/bin/mysqld(my_print_stacktrace+0x33)[0x838ba93]
- /usr/local/mysql/bin/mysqld(handle_fatal_signal+0x432)[0x8280d72]
- [0xb77bd500]
- /lib/libc.so.6(abort+0x17a)[0xb72c13aa]
- /usr/local/mysql/bin/mysqld[0x842fef8]
- /usr/local/mysql/bin/mysqld[0x8430477]
- /usr/local/mysql/bin/mysqld[0x84e64be]
- 160703 17:58:02 [Note] Event Scheduler: Loaded 0 events
- 160703 17:58:02 [Note] /usr/local/mysql/bin/mysqld: ready for connections.
- Version: '5.5.28-log' socket: '/tmp/mysql.sock' port: 3306 Source distribution
- /usr/local/mysql/bin/mysqld[0x84dd1fe]
- /usr/local/mysql/bin/mysqld[0x842ed8e]
- /usr/local/mysql/bin/mysqld[0x84225d5]
- /usr/local/mysql/bin/mysqld[0x84250f7]
- /lib/libpthread.so.0(+0x6a49)[0xb779fa49]
- /lib/libc.so.6(clone+0x5e)[0xb7377aae]
- The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
- information that should help you find out what is causing the crash.
- 160703 17:58:02 mysqld_safe Number of processes running now: 0
- 160703 17:58:02 mysqld_safe mysqld restarted
- 160703 17:58:02 InnoDB: The InnoDB memory heap is disabled
- 160703 17:58:02 InnoDB: Mutexes and rw_locks use GCC atomic builtins
- 160703 17:58:02 InnoDB: Compressed tables use zlib 1.2.3
- 160703 17:58:02 InnoDB: Initializing buffer pool, size = 16.0M
- 160703 17:58:02 InnoDB: Completed initialization of buffer pool
- 160703 17:58:02 InnoDB: highest supported file format is Barracuda.
- InnoDB: The log sequence number in ibdata files does not match
- InnoDB: the log sequence number in the ib_logfiles!
- 160703 17:58: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...
- InnoDB: Last MySQL binlog file position 0 5602, file name ./mysql-bin.000126
- 160703 17:58:02 InnoDB: Waiting for the background threads to start
- 160703 17:58:03 InnoDB: 1.1.8 started; log sequence number 4422896040
- 160703 17:58:03 [Note] Recovering after a crash using mysql-bin
- 160703 17:58:03 [Note] Starting crash recovery...
- 160703 17:58:03 [Note] Crash recovery finished.
- 160703 17:58:03 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
- 160703 17:58:03 [Note] - '0.0.0.0' resolves to '0.0.0.0';
- 160703 17:58:03 [Note] Server socket created on IP: '0.0.0.0'.
- 160703 17:58:03 InnoDB: Assertion failure in thread 2874518384 in file trx0purge.c line 829
- InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
- InnoDB: We intentionally generate a memory trap.
- InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
- InnoDB: If you get repeated assertion failures or crashes, even
- InnoDB: immediately after the mysqld startup, there may be
- InnoDB: corruption in the InnoDB tablespace. Please refer to
- InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
- InnoDB: about forcing recovery.
- 09:58:03 UTC - mysqld got signal 6 ;
- 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=16777216
- read_buffer_size=262144
- max_used_connections=0
- max_threads=151
- thread_count=0
- connection_count=0
- It is possible that mysqld could use up to
- key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 133456 K bytes of memory
- Hope that's ok; if not, decrease some variables in the equation.
- Thread pointer: 0x0
- 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 = 0 thread_stack 0x30000
- /usr/local/mysql/bin/mysqld(my_print_stacktrace+0x33)[0x838ba93]
- /usr/local/mysql/bin/mysqld(handle_fatal_signal+0x432)[0x8280d72]
- [0xb7728500]
- /lib/libc.so.6(abort+0x17a)[0xb722c3aa]
- /usr/local/mysql/bin/mysqld[0x842fef8]
- /usr/local/mysql/bin/mysqld[0x8430477]
- /usr/local/mysql/bin/mysqld[0x84e64be]
- /usr/local/mysql/bin/mysqld[0x84dd1fe]
- /usr/local/mysql/bin/mysqld[0x842ed8e]
- /usr/local/mysql/bin/mysqld[0x84225d5]
- /usr/local/mysql/bin/mysqld[0x84250f7]
- /lib/libpthread.so.0(+0x6a49)[0xb770aa49]
- /lib/libc.so.6(clone+0x5e)[0xb72e2aae]
- The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
- information that should help you find out what is causing the crash.
- 160703 17:58:03 mysqld_safe mysqld from pid file /usr/local/mysql/var/default.hostname.pid ended
复制代码 |
|