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=8388600
read_buffer_size=131072
max_used_connections=0
max_connections=100
threads_connected=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 225791 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Number of processes running now: 0
040804 01:36:18 mysqld restarted
040804 1:36:18 InnoDB: Started
/usr/local/libexec/mysqld: ready for connections.
Version: '4.0.20' socket: '/tmp/mysql.sock' port: 3306
처음에는 이와 비슷한 에러가 발생했는데, 아예 mysqld 가 뜨지도 못했습니다. 그래서 optimized 와 static 옵션을 켜고 새로 컴파일해서 겨우 mysqld 는 떴지만 로그는 계속 남네요.
당장에 쓰는 데에는 문제가 없을지 궁금합니다. 이 로그가 2~3 초에 한 번은 발생하거든요.
현재 돌리고 있는 머신은 기존 서버의 유저랜드 프로그램들이 맛이 가서 임시로 돌릴 PC 거든요.
FreeBSD 5.0 이라 바이너리는 없고 컴파일할 수 밖에 없습니다.
문제 없을까요? 아니면, 램이나 CPU 같은 다른 부분에 문제가 있는 것일까요?
커널을 업데이트하고 나니 괜찮네요. -_-;
-------------------------------------------------------------
전 세계의 mysql을 사용하는 사람들을 가슴아프게 하는 버그입니다.
버그 내용요?
mysql.com에서도 모른답니다. -_-
이때까지의 경험으로는 주로 hardware장애인 경우가 많았습니다.
잘 사용했었는데,, 어느날 갑자기 MySql 이 죽은 후로
기동시키면 바로 죽어 버립니다.
로그는 다음과 같습니다.... 무슨 에러인지도 모르겠습니다.
====================================================================
030327 15:02:59 mysqld started
030327 15:03:00 bdb: Recovery function for LSN 1 3502454 failed
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=16777216
read_buffer_size=131072
sort_buffer_size=1702047021
max_used_connections=0
max_connections=100
threads_connected=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 2666857 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
thd=0x84855f0
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...
Bogus stack limit or frame pointer, fp=0xbffff398, stack_bottom=0x20, thread_stack=196608, aborting backtrace.
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at (nil) is invalid pointer
thd->thread_id=138960120
Successfully dumped variables, if you ran with --log, take a look at the
details of what thread 138960120 did to cause the crash. In some cases of really
bad corruption, the values shown above may be invalid.
The manual page at http://www.mysql.com/doc/C/r/Crashing.html contains
information that should help you find out what is causing the crash.
030327 15:03:00 mysqld ended
by Mysql맹
이 부분이 mysql을 사용하면서 가장 error 인 부분이겠죠. debugging 자료를 가지고 mysql에 문의해 본 결과는..
"우리도 모르겠다" 였습니다.
==
시스템과 무슨 마찰이 있는 것 같은데..
보통
i) mysql을 새로 설치한다.
ii) 시스템을 새로 설치한다.
하면 해결됩니다. 원인을 마땅히 모르니 대처방안이 새로 깐다~ 밖에 없네요
==
메모리 사용량 어쩌고 하는데.. 저걸 거의 0로 만들어도 안 될 겁니다. ^^
-rw-rw---- 1 mysql mysql 25088 5월 10 2003 ib_arch_log_0000000000
-rw-rw---- 1 mysql mysql 5242880 2월 14 02:54 ib_logfile0
-rw-rw---- 1 mysql mysql 5242880 2월 13 08:58 ib_logfile1
위와 같이 로그 파일들 어제 백업된 것으로 복원하니 자료 손상없이 될 되더군요...
'소프트웨어개발 > 데이터베이스_DB' 카테고리의 다른 글
| [ORA-00054] 자원이 사용중 (0) | 2009/06/08 |
|---|---|
| [mysql] mysqld got signal 10 (0) | 2006/02/08 |
| [mysql] 버전 정보 출력 (0) | 2006/02/06 |
| [MYSQL] 4.1.X 이상 버전 콘솔 한글입력 (0) | 2005/12/07 |
| [mysql] MySQL 4.1.7 에서의 한글 입출력 문제 (0) | 2005/12/07 |
| [mysql] MySQL 데이터베이스 최적화, MySQL 성능을 200%로 1 (0) | 2005/12/06 |
