사리
당신은 당신이 사용하고 있다고 말했다 ext4. 파일 크기 제한은 16TB입니다. 따라서 Sample.ibd꽉 차서는 안됩니다.
당신은 당신 innodb_data_file_path이 말했다 ibdata1:10M:autoextend. 따라서 ibdata1 파일 자체는 OS를 제외하고는 크기에 제한이 없습니다.
이 메시지가 왜 나오나요? "디스크가 꽉 찼습니다"가 아니라 "테이블이 꽉 찼습니다"라는 메시지가 표시됩니다. 이 테이블 전체 조건은 논리적 관점에서 입니다. InnoDB에 대해 생각해보십시오. 어떤 상호 작용이 진행되고 있습니까?
내 생각에 InnoDB는 93GB의 데이터를 단일 트랜잭션으로로드하려고합니다. Table is Full메시지 는 어디 에서 나오는가? 물리적 크기 (이미 배제한)가 아니라 어떤 트랜잭션 한계에 도달했는지에 대해서는 ibdata1을 살펴 보겠습니다.
innodb_file_per_table 이 활성화되어 있고 새 데이터를 MySQL에로드 할 때 ibdata1의 내부는 무엇입니까 ?
내 의심은 Undo Logs 및 / 또는 Redo Logs가 책임이 있다고 말합니다.
이 로그는 무엇입니까? 책 에 따르면
3 장 : 4, 4 절 : "저장 엔진"은 다음과 같이 말합니다.
InnoDB 엔진은 실행 취소 로그와 재실행 로그라는 두 가지 유형의 로그를 유지합니다. 실행 취소 로그 의 목적은 트랜잭션을 롤백하고 트랜잭션 격리 수준에서 실행되는 쿼리에 대한 이전 버전의 데이터를 표시하는 것입니다. 실행 취소 로그를 처리하는 코드는 storage / innobase / buf / log / log0log.c 에서 찾을 수 있습니다 .
재실행 로그 의 목적은 응급 복구에 사용될 정보를 저장하는 것입니다. 복구 프로세스가 충돌 전에 완료되었거나 완료되지 않은 트랜잭션을 다시 실행할 수 있습니다. 해당 트랜잭션을 다시 실행 한 후 데이터베이스는 일관된 상태가됩니다. 리두 로그를 다루는 코드는 storage / innobase / log / log0recv.c 에서 찾을 수 있습니다 .
분석
ibdata1 안에 1023 개의 실행 취소 로그가 있습니다 (롤백 세그먼트 및 실행 취소 공간 참조) . 실행 취소 로그는 다시로드하기 전에 표시된대로 데이터 사본을 유지하므로 모든 1023 실행 취소 로그가 한계에 도달했습니다. 다른 관점에서, 모든 1023 실행 취소 로그는 Sample테이블 을로드하는 하나의 트랜잭션 전용 일 수 있습니다 .
하지만 기다려...
"빈 Sample테이블을 로드하고 있습니다"라고 말하고있을 것입니다 . 실행 취소 로그는 어떻게 관련됩니까? Sample테이블에 93GB의 데이터가로드 되기 전에 비어있었습니다. 존재하지 않는 모든 행을 나타내려면 실행 취소 로그에서 일부 집 청소 공간을 차지해야합니다. 1023 개의 Undo Log를 채우는 것은 데이터 양이 많기 때문에 사소한 것 같습니다 ibdata1. 나는 이것을 의심 한 최초의 사람이 아니다 :
MySQL 4.1 문서에서 다음을 참고하십시오 Posted by Chris Calender on September 4 2009 4:25pm.
5.0 (5.0.85 이전) 및 5.1 (5.1.38 이전)에서 InnoDB에 실행 취소 슬롯이 부족하면 InnoDB 테이블에 대해 "테이블이 가득 찼습니다"오류가 발생할 수 있습니다 (버그 # 18828).
다음은 MySQL 5.0에 대한 버그 보고서입니다. http://bugs.mysql.com/bug.php?id=18828
제안
Sample테이블 의 mysqldump를 만들 때 --no-autocommit을 사용하십시오.
mysqldump --no-autocommit ... mydb Sample > Sample.sql
이것은 COMMIT;매번 명시 적으로 나타납니다 INSERT. 그런 다음 테이블을 다시로드하십시오.
이것이 작동하지 않으면 (이것이 마음에 들지 않을 것입니다 ), 이렇게하십시오
mysqldump --no-autocommit --skip-extended-insert ... mydb Sample > Sample.sql
이렇게하면 각 INSERT에 하나의 행만 있습니다. mysqldump는 훨씬 커지고 (10 배 이상) 리로드하는 데 10 ~ 100 배 더 걸릴 수 있습니다.
두 경우 모두 실행 취소 로그가 초과되지 않도록합니다.
시도 해봐 !!!
업데이트 2013-06-03 13:05 EDT
추가 제안
InnoDB 시스템 테이블 (일명 ibdata1)이 파일 크기 제한에 도달하고 실행 취소 로그를 사용할 수없는 경우 다른 시스템 테이블 공간 (ibdata2) 만 추가 할 수 있습니다.
방금 이틀 전에 이런 상황이 발생했습니다. 이전 게시물을 내가 한 일로 업데이트했습니다. 데이터베이스 디자인-여러 데이터베이스 만들기를 참조 하여 테이블 크기에 대한 제한을 피하십시오.
본질적 으로 새 시스템 테이블 스페이스 파일을 수용 하려면 innodb_data_file_path 를 변경해야 합니다. 방법을 설명하겠습니다 :
대본
디스크 (ext3)에서 내 클라이언트의 서버는 다음을 갖습니다.
[root@l*****]# ls -l ibd*
-rw-rw---- 1 s-em7-mysql s-em7-mysql 362807296 Jun 2 00:15 ibdata1
-rw-rw---- 1 s-em7-mysql s-em7-mysql 2196875759616 Jun 2 00:15 ibdata2
설정은
innodb_data_file_path=ibdata1:346M;ibdata2:500M:autoextend:max:10240000M
참고 ibdata2입니다 2196875759616로 증가했다 2145386484M.
파일 크기 ibdata2를 innodb_data_file_path에 포함시키고 추가해야했습니다.ibdata3
innodb_data_file_path=ibdata1:346M;ibdata2:2196875759616;ibdata3:10M:autoextend
mysqld를 다시 시작했을 때 작동했습니다.
[root@l*****]# ls -l ibd*
-rw-rw---- 1 s-em7-mysql s-em7-mysql 362807296 Jun 3 17:02 ibdata1
-rw-rw---- 1 s-em7-mysql s-em7-mysql 2196875759616 Jun 3 17:02 ibdata2
-rw-rw---- 1 s-em7-mysql s-em7-mysql 32315015168 Jun 3 17:02 ibdata3
40 시간 만 ibdata3에 31G로 성장했습니다. MySQL은 다시 한 번 작동했습니다.