MySQL에서 테이블 데이터 파일이 손상되어 데이터베이스를 시작할 수 없는 문제 해결

黄舟
풀어 주다: 2017-09-07 13:23:21
원래의
2314명이 탐색했습니다.

1. 문제 로그

2017-08-31 14:18:05 4122 [Note] InnoDB: Database was not shutdown normally!
2017-08-31 14:18:05 4122 [Note] InnoDB: Starting crash recovery.
2017-08-31 14:18:05 4122 [Note] InnoDB: Reading tablespace information from the .ibd files...
2017-08-31 14:18:05 4122 [ERROR] InnoDB: Attempted to open a previously opened tablespace. Previous tablespace dev/tb_test uses spac
e ID: 1 at filepath: ./dev/tb_test.ibd. Cannot open tablespace mysql/innodb_table_stats which uses space ID: 1 at filepath: ./mysql/
innodb_table_stats.ibd
2017-08-31 14:18:05 2ad861898590  InnoDB: Operating system error number 2 in a file operation.
InnoDB: The error means the system cannot find the path specified.
InnoDB: If you are installing InnoDB, remember that you must create
InnoDB: directories yourself, InnoDB does not create them.
InnoDB: Error: could not open single-table tablespace file ./mysql/innodb_table_stats.ibd
InnoDB: We do not continue the crash recovery, because the table may becomeInnoDB: corrupt if we cannot apply the log records in the InnoDB log to it.
InnoDB: To fix the problem and start mysqld:
InnoDB: 1) If there is a permission problem in the file and mysqld cannot
InnoDB: open the file, you should modify the permissions.
InnoDB: 2) If the table is not needed, or you can restore it from a backup,
InnoDB: then you can remove the .ibd file, and InnoDB will do a normal
InnoDB: crash recovery and ignore that table.
InnoDB: 3) If the file system or the disk is broken, and you cannot remove
InnoDB: the .ibd file, you can set innodb_force_recovery > 0 in my.cnf
InnoDB: and force InnoDB to continue crash recovery here.
150126 14:18:06 mysqld_safe mysqld from pid file /home/mysql/mysql_app/dbdata/liuyazhuang136.pid ended
로그인 후 복사

2. 해결 방법

1. my.cnf

에 다음 매개변수를 추가합니다.

innodb_force_recovery=6
로그인 후 복사

innodb_force_recovery 매개변수 설명:
innodb_force_recovery는 전체 InnoDB 저장소 복구에 영향을 줍니다. 엔진 상태, 기본값은 0이며, 이는 복구가 필요할 때 모든 복구 작업이 수행됨을 나타냅니다.
효과적인 복구 작업을 수행할 수 없는 경우 mysql이 시작되지 않을 수 있으며 오류 로그가 기록됩니다.
innodb_force_recovery는 1~6으로 설정할 수 있으며, 숫자가 클수록 이전 모든 숫자의 영향이 포함됩니다.
설정 매개변수 값이 0보다 큰 경우 테이블에서 선택, 생성, 삭제 작업을 수행할 수 있지만 삽입, 업데이트, 삭제 등의 작업은 허용되지 않습니다.
1(SRV_FORCE_IGNORE_CORRUPT): 감지된 손상된 페이지를 무시합니다.
2(SRV_FORCE_NO_BACKGROUND): 메인 스레드가 전체 제거 작업을 수행해야 하는 경우 충돌이 발생합니다.
3(SRV_FORCE_NO_TRX_UNDO): 수행하지 않음 트랜잭션 롤백 작업.
4(SRV_FORCE_NO_IBUF_MERGE): 삽입 버퍼 병합 작업을 수행하지 마세요.
5(SRV_FORCE_NO_UNDO_LOG_SCAN): 리두 로그를 확인하지 않고 InnoDB 스토리지 엔진은 커밋되지 않은 트랜잭션을 커밋된 것으로 처리합니다.
6(SRV_FORCE_NO_LOG_REDO): 롤포워드 작업을 수행하지 않습니다.

2. 데이터베이스 백업

$mysqldump -h 192.168.209.136 -uroot -p dev > /home/mysql/dev.sql
로그인 후 복사

3. 데이터베이스 삭제

$mysql -h 192.168.209.136 -uroot -p
mysql> drop database dev;
ERROR 1051 (42S02): Unknown table 'dev.tb_test'
로그인 후 복사

tb_test

mysql> drop database dev;
Query OK, 0 rows affected (0.00 sec)
로그인 후 복사

4에 해당하는 frm 및 ibd 파일을 물리적으로 삭제합니다. innodb_force_recovery

5를 제거합니다. 이전에 설정된 매개변수를 사용하여 데이터베이스를 다시 시작


mysql> create database dev;
Query OK, 1 row affected (0.03 sec)
로그인 후 복사

6. 데이터 가져오기

##innodb_force_recovery=6
로그인 후 복사

프롬프트 테이블이 이미 존재합니다. 이는 innodb_force_recovery 매개변수를 제거한 후 데이터베이스가 롤백 작업을 수행하고 해당 ibd 파일이 생성되기 때문입니다. 따라서 파일을 삭제해야 합니다.

삭제 후 다시 가져오기


[mysql@liuyazhuang136 dev]$ mysql -h 192.168.209.136 -uroot -pmysql dev</home/mysql/dev.sql
Warning: Using a password on the command line interface can be insecure.
ERROR 1050 (42S01) at line 25: Table &#39;`dev`.`tb_test`&#39; already exists
로그인 후 복사

위 내용은 MySQL에서 테이블 데이터 파일이 손상되어 데이터베이스를 시작할 수 없는 문제 해결의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!

관련 라벨:
원천:php.cn
본 웹사이트의 성명
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.
인기 튜토리얼
더>
최신 다운로드
더>
웹 효과
웹사이트 소스 코드
웹사이트 자료
프론트엔드 템플릿