디스크 구조는 주로 테이블 스페이스라고하는 다양한 테이블 스페이스입니다. 테이블 스페이스는 InnoDB 스토리지 엔진의 논리적 구조에서 가장 높은 수준으로 볼 수 있으며 모든 데이터는 테이블 스페이스에 저장됩니다 . InnoDB의 테이블 스페이스는 5 가지 범주로 나뉩니다.
1. 시스템 테이블 스페이스 (시스템 테이블 스페이스)
기본적으로 InnoDB 스토리지 엔진에는 시스템 테이블 스페이스라고도하는 공유 테이블 스페이스 (/ var / lib / mysql / ibdata1 파일에 해당)가 있습니다.
InnoDB 시스템 테이블 스페이스에는 InnoDB 데이터 딕셔너리와 이중 쓰기 버퍼, ChangeBuffer 및 UndoLogs가 포함되어 있으며, 테이블 별 파일을 지정하지 않으면 사용자가 생성 한 테이블 및 인덱스 데이터도 포함됩니다.
- undo는 독립적 인 테이블 스페이스가 있기 때문에 나중에 소개 될 것입니다.
- 데이터 딕셔너리 : 내부 시스템 테이블로 구성되어 있으며 테이블 및 인덱스의 메타 데이터 (정의 정보)를 저장합니다.
- 이중 쓰기 버퍼링 (InnoDB의 주요 기능) : InnoDB 페이지 및 운영 체제 페이지 크기가 일치하지 않음, InnoDB 페이지 크기가 일반적으로 16K, 운영 체제 페이지 크기가 4K, InnoDB 페이지가 디스크에 기록 될 때 페이지를 분할해야 함 4 쓸 시간.
페이지 데이터를 디스크에 쓰는 동안 스토리지 엔진이 충돌하면 페이지의 일부만 기록되는 상황이 발생할 수 있습니다. 예를 들어 4K 만 기록되면 충돌이 발생할 수 있습니다.이 상황을 부분 페이지 쓰기 실패 (부분적 페이지 쓰기 실패)라고합니다. 페이지 쓰기), 데이터 손실이 발생할 수 있습니다.
show variables like 'innodb_doublewrite';
리두 로그가 없습니까? 하지만 문제가 있는데, 페이지 자체가 훼손된 경우 크래시 복구에 사용하는 것은 의미가 없습니다. 따라서 리두 로그를 적용하기 전에 페이지 사본이 필요합니다. 쓰기 실패가 발생하면 페이지 사본을 사용하여 페이지를 복원 한 다음 리두 로그를 적용하십시오. 이 페이지의 사본은 이중 쓰기 , 이노의 이중 쓰기 기술. 이를 통해 데이터 페이지의 신뢰성이 실현됩니다.
리두 로그와 마찬가지로 이중 쓰기는 두 부분으로 구성되며 한 부분은 메모리에 이중 쓰기이고 다른 부분은 디스크에 이중 쓰기입니다. 이중 쓰기는 순차적으로 작성되기 때문에 많은 오버 헤드가 발생하지 않습니다. 기본적으로 모든 테이블은 시스템 테이블 스페이스를 공유하며이 파일은 점점 더 커지며 해당 공간은 축소되지 않습니다.
2. 테이블 당 파일 테이블 스페이스 (배타적 테이블 스페이스)
각 테이블이 테이블 공간을 독점적으로 차지하도록 만들 수 있습니다. 이 스위치는 innodb_file_per_table에 의해 설정되며 기본적으로 켜져 있습니다.
SHOW VARIABLES LIKE 'innodb_file_per_table';
열면 각 테이블이 테이블 스페이스를 엽니 다.이 파일은 테이블
의 인덱스와 데이터를 저장하는 데이터 디렉토리 (예 : /var/lib/mysql/forum/user_innodb.ibd) 의 ibd 파일입니다 .
그러나 실행 취소 정보, 삽입 버퍼 인덱스 페이지, 시스템 트랜잭션 정보, 이중 쓰기 버퍼 등과 같은 다른 유형의 데이터는 여전히 원래 공유 테이블 공간에 저장됩니다.
3. 일반 테이블 스페이스 (일반 테이블 스페이스)
일반 테이블 스페이스는 ibdata1과 유사한 공유 테이블 스페이스이기도합니다. 일반 테이블 스페이스를 생성하여 다른 데이터베이스에 테이블을 저장할 수 있으며 데이터 경로 및 파일을 사용자 정의 할 수 있습니다. 문법:
create table space ts2673 add datafile '/var/lib/mysql/ts2673.ibd' file_block_size=16K engine=innodb;
테이블을 작성할 때 테이블 스페이스를 지정하고 ALTER를 사용하여 테이블 스페이스를 전송하도록 테이블 스페이스를 수정할 수 있습니다.
create table t2673(idinteger) tablespace ts2673;
다른 테이블 스페이스의 데이터를 이동할 수 있습니다. 테이블 스페이스를 삭제하려면 내부의 모든 테이블을 삭제해야합니다.
drop table t2673;
drop tablespace ts2673;
4. 임시 테이블 스페이스 (임시 테이블 스페이스)
사용자가 만든 임시 테이블과 디스크에 내부 임시 테이블을 포함하여 임시 테이블의 데이터를 저장합니다. 데이터 디렉토리의 ibtmp1 파일에 해당합니다. 데이터 서버가 정상적으로 종료되면 테이블 스페이스가 삭제되고 다음에 다시 생성됩니다.
5. 실행 취소 로그 테이블 스페이스
실행 취소 로그 (실행 취소 로그 또는 롤백 로그)는 트랜잭션 이전의 데이터 상태를 기록합니다 (선택 제외). 필요한 경우 롤백을 보장하는 데 사용됩니다. 다른 트랜잭션이 일관된 읽기 작업으로 원본 데이터를 확인해야하는 경우 수정되지 않은 데이터는 실행 취소 로그 레코드에서 검색됩니다. 즉, MVCC 메커니즘은 실행 취소 로그를 사용하여 이루다. 실행 취소가 실행되면 데이터는 로그의 논리적 형식에 속하는 물리적 페이지의 작업에서 실현되는 것이 아니라 트랜잭션 이전의 상태로만 논리적으로 복원됩니다.
리두 로그 및 실행 취소 로그는 트랜잭션 과 밀접한 관련이 있으며 총체적으로 트랜잭션 로그 라고합니다 . 그러나 리두 로그와의 차이점은 다음과 같습니다.
- 리두 로그는 물리적 로그를 저장하고 실행 취소 로그는 논리적 로그를 저장합니다.
- 리두 로그 리두 로그 및 롤 프론트 작업. 실행 취소 로그는 롤백 작업을 제공 하는 롤백 로그 입니다.
실행 취소는 트랜잭션 시작 전에 저장된 수정 된 데이터의 버전입니다. 실행 취소 로그가 생성되면 보호 트랜잭션 지속성 메커니즘과 유사한 리두 로그도 생성됩니다.
- 값을 수정 한 후 데이터 블록 을 다시 기록하면 데이터 가 성공적으로 업데이트 된 트랜잭션에 기록되지 않은 데이터 파일을 복원하는 데 사용할 수 있습니다. -거래 내구성 보장
- 트랜잭션을 롤백하는 데 값을 사용 하기 전에 기록 데이터 가 수정 된 실행 취소 -원 자성 보장
예를 들어, 데이터베이스가 특정 순간에 다운되고 두 개의 트랜잭션이 있고 한 트랜잭션이 커밋되고 다른 트랜잭션이 처리 중입니다. 데이터베이스를 다시 시작할 때 로그에 따라 롤 포워드 및 롤백하고 커밋 된 트랜잭션의 변경 사항을 데이터 파일에 쓰고 커밋되지 않은 트랜잭션의 변경 사항을 트랜잭션이 시작되기 전의 상태로 복원해야합니다.
- 데이터가 크래시 복구 인 경우 리두 로그를 사용하여 리두 로그를 통해 스토리지 엔진 내부에서 커밋 된 모든 트랜잭션을 복구합니다.
- 준비되었지만 커밋되지 않은 모든 트랜잭션은 실행 취소 로그를 사용하여 롤백됩니다.
실행 취소 로그 데이터는 기본적으로 시스템 테이블 스페이스 ibdata1 파일에 있습니다. 공유 테이블 스페이스는 자동으로 축소되지 않으므로 별도의 실행 취소 테이블 스페이스를 생성 할 수도 있습니다.
