동시 자르기 명령 중 서버 충돌 후 MySQL INNODB 손상


9

INNODB 테이블 중 하나에서 동시 truncate table 명령으로 인해 서버가 오늘 추락했습니다. 서버를 다시 시작할 수는 있지만 시작한 후 SQL 명령을 실행할 때마다 다음 오류가 발생합니다.

ERROR 2006 (HY000): MySQL server has gone away

이것은 로그에서 일어난 일입니다.

121206 01:11:12  mysqld restarted
121206  1:11:13  InnoDB: Started; log sequence number 275 559321759
InnoDB: !!! innodb_force_recovery is set to 1 !!!
121206  1:11:13 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.0.95-log'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  Source distribution
InnoDB: Error: trying to load index PRIMARY for table 
InnoDB: but the index tree has been freed!
121206  1:11:37 - 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=134217728
read_buffer_size=1048576
max_used_connections=1
max_connections=400
threads_connected=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 950272 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x9900950
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...
Cannot determine thread, fp=0x46353fa0, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
(nil)
New value of fp=0x9900950 failed sanity check, terminating stack trace!
Please read http://dev.mysql.com/doc/mysql/en/using-stack-trace.html and follow instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do
resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x993e500 =
thd->thread_id=1
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.

온라인으로 검색했는데 MySQL 버그라는 힌트를 얻었지만 어떻게 해결 해야할지 모르겠습니다. MySQL 버전 5.0.95를 사용하고 있습니다.

새 데이터베이스를 작성하고 이전 데이터를 새 데이터베이스에 덤프 해야하는 것처럼 보이지만 현재 데이터베이스에 SQL 명령을 발행 할 수없는 경우 어떻게 할 수 있습니까?

--- 업데이트 ---
버전 : '5.0.95-log'소켓 : '/var/lib/mysql/mysql.sock'포트 : 3306 소스 배포 InnoDB : 오류 : InnoDB 테이블에 대해 PRIMARY 인덱스를로드하려고합니다. 인덱스 트리가 해제되었습니다! 121206 4:13:41-mysqld는 신호 11을 얻었다; 버그가 발생했기 때문일 수 있습니다. 이 바이너리 또는 링크 된 라이브러리 중 하나가 손상되었거나 잘못 빌드되었거나 잘못 구성되었을 수도 있습니다. 이 오류는 하드웨어 오작동으로 인해 발생할 수도 있습니다. 문제를 진단하는 데 도움이되는 정보를 긁어 내기 위해 최선을 다할 것입니다. 그러나 이미 충돌했기 때문에 무언가 잘못되어 실패 할 수 있습니다.

key_buffer_size=134217728
read_buffer_size=1048576
max_used_connections=1
max_connections=400
threads_connected=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 950272 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x17fb8950
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...
Cannot determine thread, fp=0x464a3fa0, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
(nil)
New value of fp=0x17fb8950 failed sanity check, terminating stack trace!
Please read http://dev.mysql.com/doc/mysql/en/using-stack-trace.html and follow instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do
resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x17ff6500 =
thd->thread_id=3
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.

Number of processes running now: 0
121206 04:13:41  mysqld restarted
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
121206  4:13:42  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...
121206  4:13:43  InnoDB: Started; log sequence number 275 559323148
121206  4:13:43 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.0.95-log'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  Source distribution

답변:


6

화면 # 1

내 눈을 사로 잡은 첫 번째는이 라인

InnoDB : 오류 : 테이블 /에 대한 PRIMARY 인덱스를로드하려고합니다.

이것은 InnoDB 스토리지 엔진을 사용하는 테이블이 있음을 나타냅니다

InnoDB에서 흥미로운 점은 PRIMARY KEY가 저장되는 방식입니다. gen_clust_index 또는보다 일반적으로 Clustered Index 라고하는 구조에 저장됩니다 .

필자의 즉각적인 추측은 특정 기본 키 항목이 너무 크다는 것입니다.

긴 기본 키를 사용하는 좋은 점, 나쁜 점 및 추한 점에 대한 기사를 고려하십시오.

그런 다음 <DB Hidden>.<Table Hidden>다시 디자인해야하는지 확인하십시오.

화면 # 2

병렬 자르기 테이블에 관한 추측의 관점에서 볼 때 그것은 위험합니다. 왜? InnoDB는 TRUNCATE TABLE을 DDLnot으로 수행합니다 DML. 나는 전에 이것에 대해 썼다 :

화면 # 3

몇 가지 튜닝 제안

에 다음을 추가하십시오 my.ini

[mysqld]
max_allowed_packet=1G
innodb_fast_shutdown=0

mysql 시작

다른 세션에서 tail -f <errorlogfile>InnoDB Crash Recovery를 실행 하고보십시오.

mysql이 완전히 백업되고 InnoDB 응급 복구가 완료되면 mysql을 즉시 종료하십시오. InnoDB 트랜잭션 로그의 크기를 조정해야 할 수도 있습니다.

이 거친 제안에 대해 죄송하지만 여기에서 장님 비행을하고 있습니다.

질문에 다음을 게시하십시오.

  • 너의 전체 my.cnf
  • 보드에 RAM 용량

업데이트 2012-12-05 12:09 EDT

다음을 수행하십시오.

1 단계)이 변경 사항을 my.cnf

[mysqld]
max_allowed_packet=1G
innodb_fast_shutdown=0
innodb_thread_concurrency=0

2 단계) service mysql restart

MySQL이 등장하도록

STEP 03) ib_logfile0과 ib_logfile1의 크기를 조정해야합니다 (24M이 너무 작을 수 있음)

service mysql stop
cd /var/lib/mysql
mv ib_logfile0 ib_logfile0.bak
mv ib_logfile1 ib_logfile1.bak

STEP 04)이 변경 사항을 my.cnf

[mysqld]
innodb_log_file_size=512M
innodb_log_buffer_size=8M

단계 05) service mysql start

mysqld는 각각 ib_logfile0과 ib_logfile1 512M을 재생성합니다

자, 무슨 일이 일어나고 있는지보십시오 ....

업데이트 2012-12-05 12:18 EDT

그 동안 다른 사람의 ServerFault 게시물 에서 배운대로 innodb_log_file_sizeinnodb_log_buffer_size 와 관련 하여 mysql 패킷에 대한 ServerFault 게시물 과 크기에 미치는 영향을 읽으십시오 .

업데이트 2012-12-05 14:28 EDT

이 질문에서 고객 테이블에 대한 모든 참조를 편집했습니다.

근본 원인은 ibdata1데이터와 색인 페이지가 혼합 된 손상된 페이지입니다 . Andrew가 데이터를 마이그레이션하고 innodb_file_per_table을 사용 하여 ibdata1을 다시 만들도록 도와 주었고 Andrew 는 데이터를 다시로드했습니다.


귀하의 의견에 감사드립니다. 기본 키의 구조를 확실히 다시 생각하겠습니다. 한편, 기사를 살펴보고 서버를 최대한 빨리 다시 실행할 수 있는지 확인하겠습니다.
앤드류

ibdata1의 일부에 손상된 페이지가 있습니다. 호스팅 클라이언트에서이 상태를 여러 번 보았습니다.
RolandoMySQLDBA


요청에 따라 민감한 정보를 숨기려면 모든 의견을 삭제했습니다.
RolandoMySQLDBA

@RolandoMySQLDBA, 근본 원인을 어떻게 발견했는지 자세히 설명해 주시겠습니까? 어떻게 알았습니까? 이 문제를 해결하기 위해 어떤 단계를 수행 했습니까?
Bhupesh Pant
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.