☰

MySQL 테이블이 반복적으로 충돌합니다.

tag-icon • tag-icon mysql
MySQL 테이블이 반복적으로 충돌합니다.

나는 xen VM(Debian은 PV 모드에서 안정적임)을 가지고 있고 여기에 Joomla가 있습니다. 나는 웹사이트 홈페이지에서 이 메시지를 하루에도 여러 번씩 본다.

jtablesession::Store Failed
DB function failed with error number 144
Table './database@002enet/hfd_session' is marked as crashed and last (automatic?) repair failed SQL=INSERT INTO `hfd_session` 
( `session_id`,`time`,`username`,`gid`,`guest`,`client_id` ) VALUES ( 'iae9qhmfhst464v4d0a6ho6nt3','1330628728','','0','1','0' )

충돌이 나는 이유를 찾을 수 없습니다.

mysql.log 및 mysql.err 로그는 깨끗합니다. mysql 느린 로그에 일부 기록만 있는데, 이 테이블에는 연결되지 않은 것 같습니다. 이 테이블만 무너졌습니다.

테이블을 삭제하고 다시 생성해 보고 시스템을 다시 시작한 다음 fsck를 사용하여 디스크를 확인했습니다(오류 없음). 하지만 여전히 이 충돌이 발생하므로 이를 볼 때마다 수동으로 수정해야 합니다.

이 문제를 해결할 방법이 있나요?

 $ dpkg -l | grep mysql
ii  libdbd-mysql-perl                       4.016-1                         Perl5 database interface to the MySQL database
ii  libmysqlclient16                        5.1.49-3                        MySQL database client library
ii  mysql-client-5.1                        5.1.49-3                        MySQL database client binaries
ii  mysql-common                            5.1.49-3                        MySQL database common files, e.g. /etc/mysql/my.cnf
ii  mysql-server                            5.1.49-3                        MySQL database server (metapackage depending on the latest version)
ii  mysql-server-5.1                        5.1.49-3                        MySQL database server binaries and system database setup
ii  mysql-server-core-5.1                   5.1.49-3                        MySQL database server binaries
ii  php5-mysql                              5.3.3-7+squeeze3                MySQL module for php5

답변1

우리는 충돌이 발생한 mysql 테이블을 자주 다루기 때문에 무엇을 시도해야 할지에 대한 제안이 거의 없습니다.

먼저 테이블을 삭제하고 mysql을 다시 시작한 다음 테이블을 다시 추가해 보세요. 이렇게 하면 테이블을 완전히 다시 만들고 잠재적인 구조적 오류를 수정할 수 있습니다. 또는 테이블을 복구한 후 flash_tables를 수행하는 방법도 작동할 수 있지만 성공률이 높지 않은 것으로 나타났습니다.

그래도 문제가 해결되지 않으면 테이블을 완전히 메모리에 있는 테이블로 이동해 보세요. InnoDB 또는 MyISM에서 MEMORY로 전환하고 충돌이 계속 발생하는지 확인하세요. 이 테이블은 재부팅 시 결과를 유지하지 않지만 세션 테이블이므로 영향을 미치지 않습니다. 그 이유는 시스템/데이터베이스 체크포인트가 발생할 때 속도가 느린 디스크에서는 테이블 손상과 같은 많은 수의 쿼리가 생성될 수 있기 때문입니다. 나는 이것에 대한 완전한 상관 관계를 보지 못했지만 각 경우에 더 빠른 서버의 오류 수는 느린 서버의 오류 수에 가깝지 않습니다. 가상 머신이라는 점을 고려하면 느린 디스크가 때때로 문제가 될 수 있습니다.

마지막으로 전체 mysql 쿼리 로깅을 활성화하는 것입니다. 이것~ 할 것이다성능에 영향을 미치므로 주의하세요. 여기서의 아이디어는 결국 어떤 쿼리가 성공하고 어떤 쿼리가 실패하는지 추적하는 것입니다. 충분한 실패를 발견하면 패턴을 발견하게 될 것입니다. 충돌을 안정적으로 재현할 수 있다면 MySQL 버그가 있는 것입니다. 이 지점에 도달하지 않기를 바랍니다 :)

답변2

repair table [name of crashed table]

관련 정보