MyISAM을 사용하여 각 테이블을 해당 파일에 저장하는 것이 편리했습니다. InnoDB는 여러 측면에서 발전했지만 InnoDB가 모든 데이터베이스를 하나의 파일 ( ibdata1기본적으로)로 저장하는 이유가 궁금 합니다.
InnoDB가 파일의 데이터 위치를 테이블의 개별 인덱스 파일별로 매핑한다는 것을 이해하지만 모든 데이터가 하나의 파일로 혼합되는 이유를 이해하지 못합니다. 그리고 더 중요한 것은 왜 서버의 모든 데이터베이스의 데이터를 혼합합니까?
MyISAM의 흥미로운 기능은 데이터베이스 폴더를 다른 컴퓨터에 복사 / 붙여 넣기 한 다음 데이터베이스를 덤프없이 사용할 수 있다는 것입니다.
답변:
InnoDB의 아키텍처는 네 가지 기본 유형의 정보 페이지를 사용해야합니다.
기본적으로 innodb_file_per_table 은 비활성화되어 있습니다. 이로 인해 네 가지 정보 페이지 유형이 모두 ibdata1이라는 단일 파일을 랜딩합니다. 많은 사람들이 여러 ibdata 파일을 만들어 데이터를 분산 시키려고합니다. 이로 인해 데이터 및 인덱스 페이지가 조각화 될 수 있습니다.
그렇기 때문에 기본 ibdata1 파일을 사용하여 InnoDB 인프라를 정리하는 것이 좋습니다 .
복사는 InnoDB가 작동하는 인프라 때문에 매우 위험합니다. 두 가지 기본 인프라가 있습니다
로 innodb_file_per_table 장애인, 이노 정보의 모든 유형을 ibdata1에서 살고 있습니다. ibdata1 외부에있는 InnoDB 테이블의 유일한 표시는 InnoDB 테이블의 .frm 파일입니다. 모든 InnoDB 데이터를 한 번에 복사하려면 모든 / var / lib / mysql을 복사해야합니다.
개별 InnoDB 테이블을 복사하는 것은 완전히 불가능합니다. 데이터 및 해당 인덱스 정의의 논리적 표현으로 테이블 덤프를 추출하려면 MySQL 덤프가 있어야합니다. 그런 다음 해당 덤프를 동일한 서버 또는 다른 서버의 다른 데이터베이스에로드합니다.
함께 innodb_file_per_table이 가능, 테이블 데이터와 인덱스 옆 .frm 파일에 데이터베이스 폴더에 살고 있습니다. 예를 들어, db1.mytable 테이블의 경우 ibdata1 외부에서 해당 InnoDB 테이블의 표시는 다음과 같습니다.
/var/lib/mysql/db1/mytable.frm/var/lib/mysql/db1/mytable.ibdibdata1db1.mytable의 모든 메타 데이터는 여전히 ibdata1에 상주하며 그 방법은 전혀 없습니다 . 리두 로그 및 MVCC 데이터도 여전히 ibdata1과 함께 작동합니다.
테이블 조각화와 관련하여 ibdata1은 다음과 같습니다.
ALTER TABLE db1.mytable ENGINE=InnoDB;또는로db1.mytables를 축소 할 수 있습니다OPTIMIZE TABLE db1.mytable;. 결과적으로 /var/lib/mysql/db1/mytable.ibd는 조각화없이 물리적으로 더 작습니다.ALTER TABLE db1.mytable ENGINE=InnoDB;하거나ibdata1에OPTIMIZE TABLE db1.mytable;상주하므로db1.mytables를 축소 할 수 없습니다. 두 명령 중 하나를 실제로 실행하면 테이블을 연속적이고 빠르게 읽고 쓸 수 있습니다. 불행하게도, 이것은 ibdata1의 끝에서 발생합니다. 이로 인해 ibdata1이 빠르게 성장합니다. 이것은 InnoDB Cleanup Post에서 완전히 해결되었습니다 ..frm 및 .ibd 파일을 복사하려고하는 경우 상처를 입을 수있는 세계에 있습니다. InnoDB 테이블의 .frm 및 .ibd 파일을 복사하는 것은 .ibd 파일의 테이블 스페이스 ID가 ibdata1 파일의 메타 데이터에있는 테이블 스페이스 ID 항목과 정확히 일치 함을 보장 할 수있는 경우에만 적합합니다 .
이 테이블 스페이스 ID 개념에 대해 DBA StackExchange에 두 개의 게시물을 작성했습니다.
일치하지 않는 테이블 스페이스 ID가있는 경우 .ibd 파일을 ibdata1에 다시 첨부하는 방법에 대한 훌륭한 링크는 다음과 같습니다. http://www.chriscalender.com/?tag=innodb-error-tablespace-id-in-file . 이 내용을 읽은 후에는 .ibd 파일을 복사하는 것이 정말 미친 짓이라는 것을 즉시 깨달아야합니다.
InnoDB의 경우 이동하기 위해 무언가 만 필요합니다.
CREATE TABLE db2.mytable LIKE db1.mytable;
INSERT INTO db2.mytable SELECT * FROM db1.mytable;
InnoDB 테이블의 복사본을 만듭니다.
다른 DB 서버로 마이그레이션하는 경우 mysqldump를 사용하십시오.
모든 데이터베이스에서 모든 InnoDB 테이블을 혼합하는 것과 관련하여 실제로 그렇게하는 지혜를 볼 수 있습니다. 고용주의 DB / 웹 호스팅 회사에는 한 데이터베이스에 테이블이 있고 하나의 MySQL 클라이언트가 동일한 MySQL 인스턴스 내의 다른 데이터베이스에있는 다른 테이블에 제약 조건이 매핑되어 있습니다. 하나의 공통 메타 데이터 저장소를 사용하면 여러 데이터베이스에서 트랜잭션 지원 및 MVCC 작동이 가능합니다.
cno에 테이블 당 innodb-file을 추가하여 InnoDB를 토글하여 파일 당 테이블을 저장할 수 있습니다.
Innodb는 기본적으로 데이터 페이지에 관심이 있습니다. 실제로, 파일 시스템이없는 원시 블록 장치 만 사용하도록 InnoDB를 설정할 수 있습니다! http://dev.mysql.com/doc/refman/5.5/en/innodb-raw-devices.html
최적화를 통해 사용 된 공간을보다 쉽게 회복 할 수있는 것과 같이 파일 용 테이블을 저장하는 것이 편리합니다.
테이블 당 파일을 사용하더라도 InnoDB는 트랜잭션 방식이므로 ibd 파일을 쉽게 복사 할 수 없으며, 해당 상태에 대한 정보를 전역 적으로 공유되는 ibdata / log 파일에 저장합니다.
그것은 할 수 없다고 말하는 것이 아닙니다. 테이블이 오프라인 인 경우 테이블 스페이스를 삭제 / 가져 오기하고 http://dev.mysql.com/doc/refman/5.5/en/innodb-multiple-tablespaces.html 주위에 .idbs를 복사 할 수 있습니다.
이것이 기본 동작이지만 필수는 아닙니다. 에서 MySQL의 문서, 테이블 스페이스 - 테이블 당 사용 :
기본적으로 모든 InnoDB 테이블 및 인덱스는 시스템 테이블 스페이스에 저장됩니다. 대안으로, 각 InnoDB 테이블과 인덱스를 자체 파일에 저장할 수 있습니다 . 이 설정을 적용 할 때 생성되는 각 테이블에는 고유 한 테이블 스페이스가 있으므로이 기능을 "다중 테이블 스페이스"라고합니다.
이유는 아마도 두 엔진 (MyISAM과 InnoDB)의 아키텍처가 다르기 때문일 것입니다. 예를 들어 InnoDB에서는 .ibd 파일을 다른 데이터베이스 나 설치로 복사 할 수 없습니다. 설명 (같은 페이지에서) :
.ibd 파일의 이식성 고려 사항
MyISAM 테이블 파일과 마찬가지로 데이터베이스 디렉토리간에 .ibd 파일을 자유롭게 이동할 수 없습니다. InnoDB 공유 테이블 스페이스에 저장된 테이블 정의에는 데이터베이스 이름이 포함됩니다. 테이블 스페이스 파일에 저장된 트랜잭션 ID 및 로그 시퀀스 번호도 데이터베이스마다 다릅니다.