대신에게 가르침을 청하니, MySQL 이 갑자기 매우 느려졌다.

MySQL 이 충돌에서 복구되면 모든 IBD 파일의 첫 페이지를 반복하여 데이터 사전의 정확성을 확인합니다. MySQL 에 많은 수의 테이블이 포함되어 있는 경우 이 검증 프로세스는 시간이 오래 걸릴 수 있습니다. MySQL 에서의 충돌 복구는 실제로 테이블 수와 관련이 있습니다. 총 테이블 수가 많을수록 충돌 복구 시간이 길어집니다. 또한 디스크 IOPS 는 충돌 복구 시간에도 영향을 미칩니다. 예를 들어 이곳의 개발 라이브러리는 HDD IOPS 가 낮기 때문에 대량의 테이블스페이스 검증 속도가 매우 느립니다. 또 다른 발견은 MySQL 8 이 정상적으로 활성화되면 실제로 테이블 공간을 확인하고, 복구 시 다시 테이블 공간을 확인하는 것은 두 번 검사하는 것과 같다는 것입니다. 그러나 MySQL 8.0 에는 테이블 수가 5W 를 초과하면 멀티 스레드 스캔이 활성화되어 테이블스페이스 검증 프로세스 속도가 빨라진다는 추가 기능이 있습니다.

검증을 건너뛰려면 어떻게 해야 합니까? MySQL 5.7 에서 충돌 복구 시 테이블스페이스 검증 프로세스를 건너뛸 수 있습니까? 자료를 보는 데는 크게 두 가지 방법이 있다.

1. innodb_force_recovery 를 구성하면 srv_force_recovery! = 0 이면 validate = false 로 테이블스페이스 검증을 건너뛸 수 있습니다. 실제 테스트에는 innodb_force_recovery = 1 이 설정되어 있습니다. 즉, 강제 복구에서는 잘못된 페이지를 건너뛰고 검증을 건너뛰고 정상적인 시작을 다시 시작할 수 있습니다. 이 임시 접근 방식은 충돌 복구 후 시간이 많이 걸리는 테이블스페이스 검증 프로세스를 방지하고 MySQL 을 신속하게 시작합니다. 개인은 현재 어떠한 숨겨진 위험도 발견하지 못했다. 2. 별도의 테이블 영역 대신 * * * 공유 테이블 영역을 사용합니다. 이렇게 하면 n 개의 IBD 파일을 열 필요 없이 하나의 ibdata 파일만 열 수 있어 검증 시간이 크게 절약됩니다. 강 선생님의 * * * 공유 테이블스페이스를 독립 테이블스페이스 대신 사용하여 큰 테이블을 해결할 때 성능 지터에 대한 이론을 듣고 * * * 공유 테이블스페이스가 많은 비즈니스 환경에서 더 유리하다고 느꼈다.

또 다른 솔루션은 GDB 를 사용하여 충돌 복구를 디버깅하고 validate 변수의 값을 임시로 수정하여 MySQL 이 테이블스페이스 검증 프로세스를 건너뛰고 MySQL 을 정상적으로 종료하고 정상적으로 다시 시작하는 것입니다. 그러나 실제 테스트에 따르면 디버그 모드에서 실행 중인 경우 테이블스페이스 검증 프로세스를 생략하고 validate 변수를 임시로 수정할 수 있지만 디버그 모드에서 코드 실행 효율성은 크게 저하되지만 시간이 더 오래 걸리는 것으로 나타났습니다. 그러나 디버그 모드가 아닌 모드에서 실행 중인 경우 validate 변수를 수정할 수 없습니다. 당신의 생각은 산산이 부서집니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 디버그, 디버그, 디버그)