개발장비에 mysql 5.1.24를 깔아서 partitioning 등 기능을 테스트하고 있다.
오늘은 mysqldump를 받는데 장비가 hang이 걸려서 리붓이 됐다;
테이블사이즈가 커서 dump파일이 2G가 넘는게 몇개 있긴 했지만, 5.0버전에서 잘 돌고 있던 거라 dump를 다시 실행시켰다.
out of memory 라는 메시지가 나와서 dump받던 프로세스를 kill 로 죽이고,
my.cnf에서 mysqldump 실행시 max_allowed_packet 값을 좀 키운다음
mysql을 내렸다가 다시 올리려고 하는데.. 아래와 같은 에러가 나면서 mysqld이 안 올라간다;;
my.cnf바꾼거 때문인가 해서 원복해도 안되고... 몇번의 삽질과 검색끝에.. mysql의 버그라고 한다; 최근에 5.1.25 가 나왔길래 다시 컴파일해서 띄우니 잘되네~;
운영장비였으면 좀 많이 당황스런 하루가 됐을듯;;
----------------------------------------------------------------------------------
080618 18:14:03 mysqld_safe Starting mysqld daemon with databases from /user/data
080618 18:14:04 InnoDB: Started; log sequence number 0 46409
080618 18:14:04 [Note] Recovering after a crash using mysql-bin
080618 18:14:04 [Note] Starting crash recovery...
080618 18:14:04 [Note] Crash recovery finished.
080618 18:14:04 - 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=1073741824
read_buffer_size=25165824
max_used_connections=0
max_threads=151
threads_connected=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 82863 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
thd: 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...
[0x8216751]
[0x80f3e72]
[0x8253fb0]
[0x83acef8]
[0x8175015]
[0x8180dfa]
[0x80f5413]
[0x80f86c1]
[0x83a8b34]
[0x8048131]
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.
----------------------------------------------------------------------------------
오늘은 mysqldump를 받는데 장비가 hang이 걸려서 리붓이 됐다;
테이블사이즈가 커서 dump파일이 2G가 넘는게 몇개 있긴 했지만, 5.0버전에서 잘 돌고 있던 거라 dump를 다시 실행시켰다.
out of memory 라는 메시지가 나와서 dump받던 프로세스를 kill 로 죽이고,
my.cnf에서 mysqldump 실행시 max_allowed_packet 값을 좀 키운다음
mysql을 내렸다가 다시 올리려고 하는데.. 아래와 같은 에러가 나면서 mysqld이 안 올라간다;;
my.cnf바꾼거 때문인가 해서 원복해도 안되고... 몇번의 삽질과 검색끝에.. mysql의 버그라고 한다; 최근에 5.1.25 가 나왔길래 다시 컴파일해서 띄우니 잘되네~;
운영장비였으면 좀 많이 당황스런 하루가 됐을듯;;
----------------------------------------------------------------------------------
080618 18:14:03 mysqld_safe Starting mysqld daemon with databases from /user/data
080618 18:14:04 InnoDB: Started; log sequence number 0 46409
080618 18:14:04 [Note] Recovering after a crash using mysql-bin
080618 18:14:04 [Note] Starting crash recovery...
080618 18:14:04 [Note] Crash recovery finished.
080618 18:14:04 - 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=1073741824
read_buffer_size=25165824
max_used_connections=0
max_threads=151
threads_connected=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 82863 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
thd: 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...
[0x8216751]
[0x80f3e72]
[0x8253fb0]
[0x83acef8]
[0x8175015]
[0x8180dfa]
[0x80f5413]
[0x80f86c1]
[0x83a8b34]
[0x8048131]
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.
----------------------------------------------------------------------------------
반응형