답변:
당신은 함께 가야한다 innodb_file_per_table 와 이노의 현재 인프라와 청소 방법 몇 가지를 할 필요가있다.
많은 DB 호스팅 클라이언트가 MySQL을 설정하고 InnoDB를 기본 상태로 유지하는 것을 보았습니다. 이로 인해 시스템 테이블 공간 (보다 나은 ibdata1)이 크게 커집니다.
innodb_file_per_table로 전환하더라도 .ibd 파일은 ibdata1에서 추출되어야하며 ibdata는 절대 축소되지 않습니다. 예를 들어, ibdata1 내부에 2GB를 차지하는 mydb.mytable이라는 테이블이 있으면이를 추출하려면 다음을 수행해야합니다.
STEP 01) 이것을 /etc/my.cnf에 추가하십시오
[mysqld]
innodb_file_per_table
2 단계) service mysql restart
단계 03) ALTER TABLE mydb.mytable ENGINE=InnoDB;
그러면 /var/lib/mysql/mydb/mytable.ibd 파일이 만들어집니다.
불행히도, 변경 전에 테이블이 차지한 2GB의 공간을 회수 할 수 없습니다. InnoDB 인프라를 정리하는 방법과 이유에 대한 과거 게시물을 작성했습니다.
이 중요한 변경을 한 후에는 innodb_open_files (기본값 300) 를 늘리는 것을 잊지 마십시오 . 그렇지 않으면 디스크 액세스가 매우 제한됩니다.
조인과 관련하여 조인 기준을 지원하는 적절한 인덱스가 있는지 확인하십시오.
새로 설치시 innodb_file_per_table을 사용하면 모든 DDL이 ibdata 외부에서 수행되므로 ibdata1이 매우 느리게 커집니다. 앞에서 언급했듯이 InnoDB 테이블을 축소 할 수 있습니다.
ALTER TABLE mydb.mytable ENGINE=InnoDB;백업과 관련하여 .ibd 파일을 복사하는 데 매우주의하십시오. 왜?
모든 .ibd 파일 안에는 tablespace_id라는 특별한 값이 있습니다. ibdata1에는 tablespace_id 값 목록이 있습니다. 테이블을 삭제하고 다시 작성해야하는 테이블 유지 보수를 수행하는 경우 tablespace_id가 달라집니다. 이러한 .ibd 파일의 복사본을 만드는 것은 ibdata1의 복사본을 만드는 경우에만 사용하기 위해 데이터베이스로 다시 통합 될 수 있습니다. 이는 다른 모든 InnoDB 테이블의 tablespace_id를 위험에 빠뜨립니다. 이에 비추어, mysqldump는 데이터의 논리적 사본이므로 mysqldump 백업을 수행하는 것이 좋습니다. 즉, 백업은 ibdata1의 특정 시점과 무관하며 작동 성 문제없이 자유롭게 다시로드 할 수 있습니다.
@RolandoMySQLDBA에 동의하지 않는 부분은 백업입니다.
MySQL 백업 체제가 모두 해결되었고 파일 시스템 백업 전략에 .ibd 파일을 포함시키지 않은 경우에는 그렇게 중요하지 않습니다. 그러나 innodb 테이블에 ONE BYTES를 추가하면 .ibd 테이블을 증분 백업 할 수 있으며 백업 스토리지가 빨리 소진 될 수 있습니다.
나는 정확히 이런 상황을 가진 응용 프로그램을 가지고 있습니다 : 큰 테이블과 작은 테이블.
나는 작은 파일을 남겨두고 ibdata1큰 파일은 자신의 파일에 넣기 로 결정했습니다 .
나는 innodb_file_per_table기본적으로 스위치를 켜고 테이블을 ibdata1with로 이동하기 위해 일시적으로 스위치를 꺼서 그렇게합니다 ALTER TABLE.
ALTER TABLE그들. 그래서 내 전략은 innodb_file_per_table작은 테이블을 옮긴 다음 ibdata1다시 켤 수 있도록 정기적으로 켜고 부담없이 끄는 것입니다.