MySQL innodb 예외 복구 프로세스 예

이 글에서는 주로 mysql innodb 예외 복구 경험 공유를 소개합니다. 필요한 친구들은

테스트용 mysql 라이브러리 세트를 참고하세요. centos6 기본 소스에서는 mysql 5.1.71 버전이 사용됩니다. 전에 . 나중에 Percona 서버 5.7을 사용해 보고 싶었습니다. 이 라이브러리에는 중요한 데이터가 없기 때문입니다. 따라서 작업 전 백업을 수행하지 않고 소스 구성 후 직접 설치를 진행하였습니다. 데이터 파일도 기본 위치에 저장되어 있습니다. 설치가 완료된 후 mysql을 직접 실행해 보니 시동이 실패하고 정상적으로 시작이 되지 않습니다.

1. 돌아가서 mysql을 다시 설치하세요

이 데이터를 다른 곳에서 가져오는 문제를 방지하려면 먼저 현재 데이터베이스 파일을 백업하세요. 라이브러리(/var/lib/mysql/location). 다음으로 Percona 서버 5.7 패키지를 제거하고 원래 5.1.71 패키지를 다시 설치한 후 mysql 서비스를 시작했습니다. Unknown/unsupported table type: innodb 메시지가 표시되고 정상적으로 시작할 수 없습니다.

110509 12:04:27 InnoDB: Initializing buffer pool, size = 384.0M
110509 12:04:27 InnoDB: Completed initialization of buffer pool
InnoDB: Error: log file ./ib_logfile0 is of different size 0 5242880 bytes
InnoDB: than specified in the .cnf file 0 157286400 bytes!
110509 12:04:27 [ERROR] Plugin 'InnoDB' init function returned error.
110509 12:04:27 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
110509 12:04:27 [ERROR] Unknown/unsupported table type: innodb
110509 12:04:27 [ERROR] Aborting
110509 12:04:27 [Note] /usr/sbin/mysqld: Shutdown complete

/var/lib/mysql/ 디렉터리를 삭제하고 데이터베이스 서비스를 다시 시작한 후 초기화하면 정상적으로 innodb 엔진을 찾을 수 있습니다. 그런 다음 데이터베이스를 중지하고 이전에 백업한 /var/lib/mysql/ 디렉터리의 내용을 현재 위치의 내용으로 덮어쓴 후 다시 시작합니다. 또한 시작할 수 없고 오류 내용도 이전과 동일하다는 것을 확인했습니다.

/var/lib/mysql 디렉토리의 내용 구조는 다음과 같습니다.

-rw-rw---- 1 mysql mysql 10485760 2月  26 18:10 ibdata1
-rw-rw---- 1 mysql mysql 5242880 2月  26 18:10 ib_logfile0
-rw-rw---- 1 mysql mysql 5242880 2月  26 17:20 ib_logfile1
drwx------ 2 mysql mysql   4096 2月  26 17:20 mysql
drwx------ 2 mysql mysql   4096 2月 26 17:24 wiki

wiki 디렉토리는 테스트 데이터용 라이브러리, ibdata1 파일은 데이터 파일, ib로 시작하는 두 파일은 로그 파일, mysql입니다. 이 디렉토리에는 시스템 라이브러리 관련 내용이 포함되어 있습니다. 초기화된 데이터를 다시 사용하고, wiki 디렉토리와 ibdata1 파일을 /var/lib/mysql 디렉토리에 덮어쓰면 정상적으로 시작하고 로그인할 수 있습니다.

2. innodb 모듈을 다시 설치합니다

그런데 mysqldump를 통해 백업할 때 알 수 없는 테이블 엔진 "Innodb"가 표시됩니다. 로그인 후 현재 엔진 유형을 모두 확인하고 그중 innodb 유형이 존재하지 않는지 확인합니다.

alter 명령을 사용하여 테이블 중 하나의 유형을 수정합니다. MyISAM에 접속하여 오류가 여전히 보고되는지 확인합니다.

찾기를 통해 /usr/lib64/mysql/plugin/ 디렉터리에 ha_innodb_plugin.so 파일이 있음을 확인했습니다. mysql5의 최신 버전이 온라인 플러그인 설치를 지원한다는 인상을 받았습니다. 실제로 지원되는지 확인하려면 다음을 확인하세요.

다음 명령을 사용하여 로드할 때 실패한 것으로 나타났습니다.

install plugin innodb soname 'ha_innodb.so';

3. 백업

/etc/my.cnf에 다음 구성을 추가합니다:

plugin-load=innodb=ha_innodb_plugin.so
plugin_dir=/usr/lib64/mysql/plugin/
default-storage-engine=InnoDB

여전히 시작에 실패했습니다. mysql-error.log를 확인하고 다음 내용을 찾으세요.

InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 7.
InnoDB: You may have to recover from a backup.
InnoDB: It is also possible that your operating
InnoDB: system has corrupted its own file cache
InnoDB: and rebooting your computer removes the
InnoDB: error.
InnoDB: If the corrupt page is an index page
InnoDB: you can also try to fix the corruption
InnoDB: by dumping, dropping, and reimporting
InnoDB: the corrupt table. You can use CHECK
InnoDB: TABLE to scan your table for corruption.
InnoDB: See also http://dev.mysql.com/doc/refman/5.1/en/forcing-innodb-recovery.html

공식 forcing-innodb-recovery 페이지를 열고 innodb_force_recovery 매개변수를 지정하여 강제로 시작 및 복구할 수 있는지 확인하세요. /etc/my.cnf에 다음 콘텐츠를 추가합니다.

innodb_force_recovery=6

다시 시작에 성공했습니다. mysqldump를 통한 백업에는 문제가 없으며, 다른 호스트로 백업 데이터를 가져오는 것도 정상으로 확인 가능합니다.

이제 쉽습니다. mysql을 완전히 삭제하고 Percona 서버 5.7을 다시 설치한 후 데이터베이스를 구축하고 데이터를 복원하고 프로그램을 다시 연결하면 모든 것이 정상입니다.

요약:

mysql innodb 데이터 파일의 특성상 문제가 발생하여 정상적으로 시작할 수 없는 경우 ./ib_logfile0 및 ./ib_logfile1 두 로그는 먼저 파일을 이동한 후 시작하세요. 그래도 계속 실패하면 innodb_force_recovery 매개변수를 사용하여 강제 복구할 수 있습니다. 또한 로그는 다시 시작할 수도 있습니다. 궁금한 점이 있으면 먼저 로그를 확인하세요.

위 내용은 MySQL innodb 예외 복구 프로세스 예의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!