다시 실행 및 실행 취소 이해

하나, 리두 로그

1.1 기본 개념

WAL의 전체 이름은 Write-Ahead Logging이며 핵심은 로그를 먼저 쓴 다음 디스크에 쓰는 것입니다. 변경 작업의 경우 innodb 엔진은 먼저 레코드를 다시 실행 로그에 쓰고 메모리 레코드를 업데이트합니다. 이때 업데이트가 완료됩니다. 이러한 더티 페이지는 시스템이 상대적으로 유휴 상태 일 때 종종 플러시됩니다.

리두 로그에는 두 가지 주요 기능이 있습니다.
하나는 크래시 복구입니다. 버퍼 풀의 더티 페이지를 새로 고칠 시간이 없더라도 이때 갑자기 크래시가 발생하면 다시 실행을 사용하여 크래시에서 복구 할 수 있습니다. 두 번째는 임의 쓰기를 순차적 쓰기로 변경하여 데이터베이스 처리의 쓰기 성능을 크게 향상시키는 것입니다.

1.2 관련 매개 변수

innodb_log_files_in_group

리두 로그 파일 수, 이름 지정 방법 : ib_logfile0, iblogfile1 ... iblogfilen. 기본값은 2이고 최대 값은 100입니다.

innodb_log_file_size

파일 설정 크기, 기본값은 48M, 최대 값은 512G입니다. 최대 값은 전체 리두 로그 시리즈 파일의 합계를 나타냅니다. 즉, (innodb_log_files_in_group * innodb_log_file_size)는 최대 값보다 클 수 없습니다. 512G.

innodb_log_group_home_dir
리두 로그 파일 저장 경로
innodb_log_buffer_size

Redo Log 버퍼 영역, 기본값은 8M이며 1-8M을 설정할 수 있습니다. 디스크에 트랜잭션 로그 쓰기를 지연하고, 리두 로그를 버퍼에 넣은 다음 특정 전략에 따라 리두 로그 파일로 플러시합니다.

innodb_flush_log_at_trx_commit

리두 로그를 버퍼에서 디스크로 플러시하는 전략에는 주로 다음 세 가지 모드가 있습니다.

0，每次commit都只是把redo log记录在redo log buffer中，fsync到磁盘的操作由系统来调度。
   如果MySQL发生crash，丢失1s内的事务修改操作
1：每次commit都会把redo log从redo log buffer写入到os 缓冲，并fsync刷新到磁盘文件中。
2：每次事务提交时MySQL会把日志从redo log buffer写入到os 缓冲，但fsync操作由依赖系统调度。
   如果MySQLcrash，不会丢失redo log，但是如果OS发生crash，丢失这一部分的数据。

1.3 리두 로그 버퍼 브러싱 전략

1. 공간이 리두 로그 버퍼의 1/2 미만인 경우

2. 각 트랜잭션이 커밋됩니다 (innodb_flush_log_at_trx_commit = 1).

3. 백그라운드 스레드

4. 체크 포인트 수행

5. 데이터베이스가 닫힙니다.

6, binlog 스위치

1.4 redo와 binlog의 차이점

1, 다시 실행

1) 엔진 레이어 제품

2) 레코드 형식은 물리적 로그입니다.

3) 재실행 로그 파일이 주기적으로 덮어 쓰기하여 쓰기

4) 데이터를 수정할 준비가되기 전에 캐시의 리두 로그에 기록한 다음 캐시의 데이터를 수정하고, 트랜잭션 커밋시 캐시의 리두 로그가 캐시의 리두 로그에 기록되는지 확인합니다. 명령이 실행되고 쓰기가 완료됩니다. 그러면 제출 작업이 실행됩니다.

2 、 빈 로그

1) 서버 계층 제품

2) 레코드 형식은 논리 로그입니다.

3) Binlogfile은 순서대로 작성되며, 삭제되지 않는 한 항상 존재합니다.

4) 트랜잭션이 커밋 될 때마다 한 번만 캐시의 로그를 binlog 파일에 씁니다.

둘째, 실행 취소 로그

2.1 기본 개념

실행 취소 로그는 주로 레코드 수정 및 수정 전 값을 저장하는 데 사용됩니다. 그 기능은 주로 트랜잭션의 롤백을 보장하는 것입니다. 다른 하나는 읽기 비 차단 쓰기, 쓰기 비 차단 읽기, 다중 버전 동시성 (MVCC)을 실현하는 것입니다.

내부는 resg slot0-resg slot127에서 ibdata 시스템 테이블 스페이스에 저장된 128 개의 롤백 세그먼트 (ollback 세그먼트)로 구성됩니다. 각 resg 슬롯, 즉 각 롤백 세그먼트는 내부적으로 1024 개의 실행 취소 세그먼트로 구성됩니다. 롤백 세그먼트는 다음과 같이 할당됩니다.

slot 0 ，预留给系统表空间；
slot 1- 32，预留给临时表空间，每次数据库重启的时候，都会重建临时表空间；
slot33-127，如果有独立表空间，则预留给UNDO独立表空间；如果没有，则预留给系统表空间；

롤백 세그먼트에서는 임시 테이블 트랜잭션을 위해 32 개가 제공됩니다. 나머지 128-32 = 96 롤백 세그먼트는 96 * 1024 개의 동시 트랜잭션 작업을 수행 할 수 있습니다. 각 트랜잭션은 실행 취소 세그먼트 슬롯을 차지합니다. 트랜잭션이 임시 테이블이있는 경우 트랜잭션이 임시 테이블 스페이스에있는 경우 다른 실행 취소 세그먼트 슬롯이 임시 테이블 스페이스의 실행 취소 세그먼트 슬롯에서 점유됩니다. 즉, 2 개의 실행 취소 세그먼트 슬롯이 점유됩니다. 있는 경우 : 오류 로그에서 실행 취소 로그를위한 여유 슬롯을 찾을 수 없습니다. 이는 동시 트랜잭션이 너무 많고 비즈니스를 분할할지 여부를 고려해야 함을 의미합니다.

롤백 세그먼트 (롤백 세그먼트)는 폴링 스케줄링에 의해 할당되고 사용됩니다. 독립 테이블 스페이스가 설정되면 시스템 테이블 스페이스 롤백 세그먼트의 실행 취소 세그먼트는 사용되지 않지만 독립 테이블 스페이스가 사용됩니다. 동시에 시간, 소급 세그먼트가 Truncate에서 작동 중이므로 할당되지 않습니다.

2.2 관련 매개 변수

innodb_max_undo_log_size

undo log> = 2 및 innodb_undo_log_truncate 매개 변수가 켜진 경우 undo 테이블 스페이스가 innodb_max_undo_log_size 임계 값을 초과하면 제거 스레드가 크기를 초과하는 실행 취소 로그 파일을 자르고 실행 취소 로그를 다시 초기화하고 테이블 공간을 다시 확보하려고합니다.

이 값의 기본 크기는 1G이고 자르기 후 기본 크기는 10M입니다.

innodb_undo_tablespaces

실행 취소 독립 테이블 스페이스의 수입니다. 기본값은 0입니다. 0은 독립 실행 취소 테이블 스페이스가 활성화되지 않고 실행 취소 로그가 ibdata 파일에 저장됨을 의미합니다. 이 매개 변수는 MySQL 인스턴스를 초기화 할 때만 지정할 수 있습니다.

innodb_undo_log_truncate

실행 취소 로그 파일을 자르는 과정에서 제거 스레드는 파일에 활성 트랜잭션이 있는지 확인해야합니다. 그렇지 않으면 실행 취소 로그 파일을 할당되지 않은 것으로 표시합니다. 이때 실행 취소 로그는 다른 파일에 기록되므로 자르기 작업을 수행하려면 두 개 이상의 독립된 테이블 스페이스 파일이 필요합니다. 할당되지 않음으로 표시 한 후 특정 실행 취소 로그 파일이 현재 자르고 있음을 기록 하기 위해 별도의 파일 undo_ <space_id> trunc.log 가 생성 된 다음 초기화를 시작합니다. undo log file to 10M 작업이 끝나면 자르기 작업을 나타내는 undo <space_id> _trunc.log 파일 을 삭제합니다 .이 파일은 자르기 프로세스 중에 오류가 발생하더라도 데이터베이스 서비스가 다시 시작되도록합니다. 재시작 후 , 서비스는이 파일을 찾고 자르기 작업을 계속 완료합니다. 파일을 삭제 한 후 실행 취소 로그 파일을 할당 할 수 있음을 표시합니다.

innodb_purge_rseg_truncate_frequency

제거 롤백 세그먼트의 빈도를 제어하는 데 사용되며 기본값은 128입니다. n으로 설정되어 있다고 가정하면 Innodb Purge 작업의 조정 스레드가 128 회 퍼지 트랜잭션을 수행 할 때 현재 실행 취소 로그 테이블 스페이스 상태가 잘림을 트리거하는지 여부를 확인하기 위해 히스토리 제거가 트리거됨을 의미합니다.

기사 참조 :

https://www.cnblogs.com/xinysu/p/6555082.html#_lab2_1_0

https://www.cnblogs.com/f-ck-need-u/archive/2018/05/08/9010872.html#auto_id_15