실행 취소 및 재실행 로그의 MySQL은

실행 취소

1.1 취소

수정되기 전에 수정 된 데이터 값을 저장하기위한 기록 취소 (이전 값으로 함), 수정 상정 TBA 광고 데이터 테이블 ID = 2 NAME = 'B'이름을 수정 = "B2", 상기 취소 로그를 사용 저장소 레코드 NAME = 'B'로, 이상 변형 경우, 트랜잭션 일관성을 보장하기 위해 롤백 동작을 달성하기 위해 취소 로그를 사용한다.

신분증	이름
1	ㅏ
이	비
삼	씨
4	디

, UNDO LOG 및 두 가지로 구분되어 삭제 된 데이터에 주로 INSERT UPDATE에서 변경 조작은, 하나 INSERT_UNDO (INSERT 동작)이며, 삽입 된 고유 키의 기록은, 하나 UPDATE_UNDO (갱신 및 삭제 동작에 포함)이며 유일한 열쇠는 기록과 오래된 열 기록을 수정할 수 있습니다.

1.2 undo 참조 수

mysql> show global variables like '%undo%';
+--------------------------+------------+
| Variable_name            | Value      |
+--------------------------+------------+
| innodb_max_undo_log_size | 1073741824 | -- 1G
| innodb_undo_directory    | ./         |
| innodb_undo_log_truncate | OFF        |
| innodb_undo_logs         | 128        |
| innodb_undo_tablespaces  | 0          |
+--------------------------+------------+

mysql> show global variables like '%truncate%';
+--------------------------------------+-------+
| Variable_name                        | Value |
+--------------------------------------+-------+
| innodb_purge_rseg_truncate_frequency | 128   |
| innodb_undo_log_truncate             | OFF   |
+--------------------------------------+-------+

• innodb_max_undo_log_size : innodb_max_undo_log_size가 시간 임계 값을 절단하기 위해 노력할 것보다 실행 취소 테이블 스페이스, innodb_undo_log_truncate을 시작했을 때 가장 큰 실행 취소 테이블 스페이스 파일의 크기를 제어 할 수 있습니다. 이 값은 기본 크기 1G는 기본 크기 10M을자를 수 있습니다.

• innodb_undo_tablespaces은 : 실행 취소 테이블 스페이스의 수는 독립적으로 0,0 실행 취소 테이블 스페이스를 나타냄과 ibdata가 로그 파일에 저장됩니다 취소에 0-128의 범위, 기본이 켜져 있지, 독립적으로 설정합니다. 이 매개 변수는 인스턴스가 작성되면 데이터베이스 구성 파일 innodb_undo_tablespaces에 지정된 번호는 번호가 인스턴스가 생성 될 때, 그것은 것 지정된 것보다 더 큰 .CNF 경우,이 매개 변수가 변화가 아니라, 단지 지정된 초기화 MySQL의 인스턴스의 시작이다 매개 변수가 잘못 설정 것을 제안, 시작하지 못했습니다.

• innodb_undo_log_truncate 다음 이노 퍼지 실, 또는 공간을 다시 초기화 innodb_undo_log_truncate, innodb_max_undo_log_size 파라미터 값 및 상기 주파수 잘라내있어서 상기 취소 파일을 복구 떨어져 배치. 이 파라미터가 적용되도록 제공되며, 별도의 테이블 공간보다 독립적 테이블 번호를 더 구비 한 또는 두 개의 동일. 공정 잘라 내기 실행 취소 로그 파일에 퍼지 스레드, 파일에 활성 트랜잭션이 있는지 여부를 확인하기 위해 필요하며, 그렇지 않은 경우 필요하므로 적어도, 실행 취소 로그를 다른 파일에 기록 될 것입니다이 시간에 할당되지 않은 상태로 표시 취소 로그 파일에 잘라 내기 작업을 할 수있는 두 개의 별도의 테이블 스페이스 파일이 필요 레이블이 할당 할 수 없습니다, 그것은 별도의 파일을 생성합니다 undo_<space_id>_trunc.log, 기록 이제 잘라 내기 실행 취소 로그 파일을 다음 작업의 종료 후, 10M에 초기화 취소 로그 파일을 시작, 대표 삭제할 잘라 내기 작업 undo_<space_id>_trunc.log도 다시 시작한 후, 프로세스 데이터베이스 서비스 잘라 내기를 다시 시작 실패의 경우에, 서비스가 파일을 발견 보장하지만이 삭제 된 파일의 종료 후, 작업의 완료를 잘라 계속 파일은, 식별은 실행 취소 로그 파일을 할당 할 수 있습니다.

• innodb_purge_rseg_truncate_frequency : 퍼지 제어를위한 롤백 주파수, 기본값은 128입니다. 가정이 n으로 설정되어, 그것은 이노 디비 제거 작업 스레드 퍼지 업무 128 시간을 조정하는 경우, 그것은, 현재 실행 취소 로그 테이블 스페이스 상태가 잘라 내기를 트리거 여부를 확인 열어 본 퍼지를 게재 할 것을 나타냅니다.

1.3 실행 취소 공간 관리

별도의 테이블 공간을 설정해야하는 경우, 데이터베이스 인스턴스, 별도의 테이블의 지정된 수를 초기화 할 필요가있다.

resg의 슬롯 0에서 내부 UNDO 롤백 각각 시스템 테이블 ibdata 공간에 저장 즉 롤백 세그먼트 (128)의 전체, 복수 - resg의 slot127 내부 의해 각 resg 슬롯 롤백 즉 각각, 1024 개 실행 취소 세그먼트 구성 요소.

다음과 같이 롤백 (롤백 세그먼트) 배포 :

• 슬롯 0, 공간은 시스템 테이블 예약;
• 슬롯 1 (32), 공간이 임시 테이블 예약, 임시 테이블 공간을 다시 각 데이터베이스 재시작 시간;
• slot33-127, 별도의 테이블 공간 별도 테이블 UNDO 예약 공간이있는 경우, 그렇지 않으면, 시스템 테이블 예약 공간;

롤백 제거 임시 테이블 (32)은 1024 * 96 동작을 동시 트랜잭션을 수행 나머지 128-32 = 96 롤백을 사용하여 트랜잭션에 공급되고, 각각의 트랜잭션은 참고 취소 세그먼트 슬롯을 차지하는 경우, 트랜잭션 이 임시 테이블의 문제가 있지만, 또한 실행 취소 세그먼트 슬롯에 임시 테이블 스페이스에 다시 두 개의 실행 취소 세그먼트 슬롯에 의해 점유되는 실행 취소 세그먼트 슬롯을 차지합니다. 오류 로그 인 경우 : Cannot find a free slot for an undo log。이 사업을 분할 할 것인지 여부를 고려해야 할 너무 많은 동시 트랜잭션, 필요성을 나타냅니다.

롤백 (롤백 세그먼트) 제공된 별도의 테이블은, 시스템이 동시에 대신 별도의 테이블 공간을 사용하는 세그먼트 취소 롤백 테이블을 사용하지 않을 경우, 할당 할 폴링 스케줄링 모드, 만약 자르기 작업 기간이 리콜, 할당되지 않습니다.

도형 표시 기본 레이아웃 구조 취소 롤백있어서

1. rseg0 테이블에 ibdata 시스템 예약 공간은;
2. rseg 1 ~ rseg 롤백 시스템 테이블 스페이스 임시 테이블에 저장됩니다 (32) (32)
3. 합니다 (ibdata 저장 열린 독립적 취소 테이블이없는 경우) rseg33 ~ 독립적 취소 테이블 공간에 기억 된 구성에 따라

우리는 별도의 실행 취소 테이블 스페이스를 사용하는 경우, 항상 롤백 취소 최초의 실행 취소 공간 할당 폴링에서 시작합니다. 대부분의 경우이 OK 인하지만 순차적 33 증분 구성 (128)에서 롤백 세그먼트의 수는, 그것이 동일한 취소 공간에 저장된 모든 롤백 세그먼트로 이어질 수 있다고 가정한다. (참고 함수 trx_sys_create_rsegs 및 버그 # 74471 )

각 페이지를 따라서 96 명 * 1,024 총무 이론적 이노를 지원, 1024 슬롯 (TRX_RSEG_N_SLOTS), 로그 취소 대상으로 턴 상당의 각각의 슬롯에 분할된다 롤백 세그먼트 헤더 페이지를 유지한다.

다시 하다

2.1 다시 실행

데이터베이스의 데이터를 변경할 때, 당신이 디스크 버퍼 풀 데이터 페이지를 읽은 후 버퍼 풀을 변경할 필요가, 데이터 페이지 버퍼 풀은 디스크의 페이지 내용에있는 데이터와 일치하지 않는이 시간, 버퍼는 말했다 풀 데이터 페이지가 더러운 페이지 더러운, 메모리, 및, 즉, (랜덤 IO있는 디스크 파일 동기화 주) 디스크 파일 동기화되지 아니 비정상적인 DB 서비스를 다시 시작이 시간이 발생하는 경우,이 데이터가있다한다 (로깅이 순차적 IO는 것을 주), 파일에 해당하는 변경 로그 레코드의 데이터 페이지 변경 버퍼 풀의 끝, 다음 DB 서비스가 충돌 발생했을 때이 시간에, 파일을 가질 수있는 경우 데이터 손실이 발생됩니다 상황은,이 파일의 내용을 디스크에 다시 적용 파일을 기록 할 수 DB 복구 시간, 데이터가 일치한다.

이 파일은 기록 데이터 변경, 기록의 순서를 기록, 리두 로그입니다. 그것은 이러한 혜택을 가져올 수 :

• 더러운 페이지의 버퍼 풀은 디스크에 플러시되지 않은 경우 서비스를 시작한 후 발생 사고는 기록을 디스크 파일로 플러시해야 리두 로그를 찾을 수 있습니다 때
• 디스크 파일에 직접 플러시 데이터 버퍼 풀은 IO는 임의의 가난한 효율성, 그리고 로그를 다시 실행 버퍼 풀에 데이터를 기록하는 것은, 시퀀스는 IO입니다, 트랜잭션 커밋의 속도를 향상시킬 수 있습니다;

디스크 파일 높이를 수정하는 경우에는 수정 가정 TBA 광고 데이터 테이블 ID = 2 NAME = 'B'이름 변경이 = 다음 기록을 다시 'B2'는 상기 기록 = 'B2'를 이름을 저장하는 데 사용될 수있다 예외가 발생하면 트랜잭션의 내구성을 보장하기 위해, 리두 로그 다시 실행 작업을 사용하여 얻을 수 있습니다.

신분증	이름
1	ㅏ
이	비
삼	씨
4	디

여기서 재실행 로그의 바이너리 로그와의 차이를 유의 리두 로그 스토리지 엔진 층을 생성하고, 바이너리 로그 데이터베이스 계층이 생성된다. 이 트랜잭션이 커밋 것을 알고, 그 과정에서 우리는 리두 로그의 순서를 기록하는 계속하고, 바이너리 로그가 기록하지 않습니다 삽입 100,000 라인에 메모를 TBA, 큰 거래를 가정 한 번 바이너리 로그 파일에 기록됩니다 한다. 같은 기록 형식의 혼합, 다른 형태의 행, 문되지 않습니다 바이너리 로그 레코드 형식은 3 종류가 있습니다.

2.2 재실행 파라미터

• innodb_log_files_in_group : ib_logfile0, iblogfile1 ... iblogfilen :로 명명 된 리두 로그 파일의 수를. 기본 2, 최대 100.

• innodb_log_file_size : 파일 크기 설정, 기본 값 48M, 512G의 최대, 최대 관심은 최대 512G보다 크지 않은 (* innodb_log_file_size innodb_log_files_in_group) 문서 및 리두 로그, 즉 전체 시리즈를 말합니다.

• innodb_log_group_home_dir : 파일 저장 경로

• innodb_log_buffer_size : 리두 로그는 기본 8M 버퍼, 1-8M을 설정할 수 있습니다. 지연된 트랜잭션 로그 버퍼에 디스크에 다시 실행 로그를 기록하고에서 innodb_flush_log_at_trx_commit 설정 파라미터에 따라, 그 다음 디스크 버퍼로부터 로그 플러시된다.

• 에서 innodb_flush_log_at_trx_commit

  • = 1에서 innodb_flush_log_at_trx_commit 각각 리두 로그 시스템에 리두 로그 버퍼로부터 기록 커밋되며 fsync를 디스크 파일에 플러시.
  • 에서 innodb_flush_log_at_trx_commit = 2, 트랜잭션이 MySQL의 로그 시스템에 리두 로그 버퍼에서 작성하지만 파일 시스템 버퍼, 디스크 파일에 대한 fsync를에 내부 시스템에 기록됩니다 커밋 때마다. 데이터베이스 인스턴스 충돌하면 리두 로그를 손실되지 않습니다,하지만 인해 파일 시스템 버퍼에 서버 충돌, 디스크 파일에 대한 fsync를 할 수있는 기회가 있다면 데이터의 일부가 손실 될 수 있도록.
  • 에서 innodb_flush_log_at_trx_commit = 0, 트랜잭션 로그가 재실행 로그 버퍼에 기록되어있는 동안 다른 설정과 같은 발생하지만 때 리두 로그 버퍼로부터 트랜잭션 커밋 리두 기록 동작하지만, 초당 MySQL의 내부 동작, 데이터 시스템에 기록. 당신은 충돌, 1 초 내에 수정 작업을 손실 트랜잭션을 발생합니다.
  • 참고 : 인해 스케줄링 문제의 프로세스에서 "한 번 두 번째 플러시 당 실행 (디스크 브러시) 작업을"의 100 % 보장 할 수 없습니다 "당 초."

2.3 리두 공간 관리

로그 파일 다시 실행 ib_logfile[number]이름을 순차적으로 리두 로그 파일을 기록, 다시 채워진 첫 번째 파일, 덮여 쓰기에. (그러나 다시 실행 검사 점을 수행에서, 또한 너무 엄격 너무 작성하기 위해 말하기, 헤드 체크 포인트 마크를 첫 번째 로그 파일을 업데이트).

사실 리두 로그는 두 부분으로 구성 리두 로그는 리두 로그 파일을 버퍼. 로그 버퍼 기록 재실행 데이터 버퍼 풀을 수정하여 다음 후 재실행 로그 리두 로그 파일에 따라 브러시 발생

• 버퍼 공간 부족 리두 로그
• (종속 파라미터 설정에서 innodb_flush_log_at_trx_commit) 트랜잭션 커밋
• 배경 스레드
• 음주 체크 포인트
• 종료의 예
• 바이너리 로그 스위치

거래에서 2.4 응용 프로그램 다시 실행 및 실행 취소

취소 로그인

취소 로그 트랜잭션 자성 실현되면, 이노 MySQL의 데이터베이스 저장 엔진은 다중 버전 취소 로그 동시성 제어 (: MVCC 약어)로 이루어진다.

• 트랜잭션의 모든 작업 중 하나를 완료하거나 작업뿐만 아니라 부품 번호 조작 : (자성)이 거래의 자성. 오류가 실행 중에 발생하면이 트랜잭션이 실행되지 않을로, 트랜잭션의 시작 전의 상태로 (롤백)을 롤백합니다.

• 원리 : 실행 취소 로그 원칙은 모든 데이터의 작동에 이전 트랜잭션의 원 자성을 만나는 첫 번째 장소에 데이터를 백업하기 위해 매우 간단합니다
  (백업 데이터가 취소 로그인 언급 저장할 수있는이 곳을). 그런 다음, 데이터를 수정하는 단계를 포함한다. 오류 또는 사용자 ROLLBACK 문이 실행되면, 시스템은 트랜잭션이 시작되기 전에 그 상태로 데이터를 복원에서 백업 실행 취소 로그를 사용할 수 있습니다. 트랜잭션의 원 자성을 보장 할뿐만 아니라, 실행 취소 로그는 전체 거래의 지속성을 지원하는 데 사용할 수 있습니다.

• 거래의 내구성 (내구성) : 트랜잭션이 완료되면, 모든 변경 사항의 데이터베이스에 트랜잭션이 데이터베이스에 저장 지속됩니다. 내구성을 보장하기 위해, 데이터 시스템은 완전히 영구 저장소에 기록 된 데이터베이스를 수정합니다.

취소 로그인 자성 및 지속성 거래 과정으로 간소화

을 가정, B 개의 데이터 값을 각각 1, 2,.

A.事务开始.
B.记录A=1到undo log.
C.修改A=3.
D.记录B=2到undo log.
E.修改B=4.
F.将undo log写到磁盘。
G.将数据写到磁盘。
H.事务提交

데이터가 첫째를 메모리로 읽어 후 메모리에 데이터를 수정하고, 마지막으로 쓰기 데이터는 디스크에 백업 :이 암시 적 전제 조건이다.

동시에 우리는 다음 이유로 인해 특성, 원 자성을 보장하고 지속성 수 있었다 :

• 데이터를 업데이트하기 전에 실행 취소 로그를 기록합니다.
• 내구성을 보장하기 위해, 데이터는 트랜잭션 커밋 될 때까지 디스크에 기록해야합니다. 한 트랜잭션이 성공적으로 제출로, 데이터가 지속되어 있어야합니다.
• 데이터를 선행해야 실행 취소 로그가 디스크에 지속되었다. 시스템이 G, H 사이에 충돌하는 경우, 실행 취소 로그가 완료되면 트랜잭션을 롤백 할 수 있습니다.
• 시스템, AF 사이에서 충돌하는 경우 데이터가 디스크에 지속되지 않기 때문에. 트랜잭션이 시작되기 전에 따라서, 디스크 나의 데이터는 상태에 남아 있습니다.

결함

각 트랜잭션의 커밋 및 취소 로그 데이터가 디스크에 기록되기 전에,이 디스크 IO의 많은, 따라서 매우 낮은 성능의 원인이됩니다.

데이터가 몇 시간 동안 캐시 할 수 있다면, 그것은 성능을 향상시키기 위해 IO를 줄일 수 있습니다. 하지만이 거래의 내구성을 잃게됩니다. 따라서 다른 사람의 도입
종 메커니즘은 지속적인을 달성하기 위해, 그 리두 로그입니다.

다시 실행 + 취소 로그인

원리 : 실행 취소와 반대로 로그, 리두 로그의 기록이다 새로운 데이터 백업. 트랜잭션이 커밋되기 전에만큼 리두 로그 지속성 수 있듯이,
당신은 데이터 지속성이 필요하지 않습니다. 시스템 데이터가 지속되지 않지만, 충돌,하지만 때 리두 로그는 지속하고있다. 이 시스템은 기반으로 할 수있는
일에 모든 데이터를 복원 할 수있는 리두 로그의 내용.

취소 +는 트랜잭션 프로세스를 다시 실행을 단순화

을 가정, B 개의 데이터 값 1, 2, 각각

A.事务开始.
B.记录A=1到undo log.
C.修改A=3.
D.记录A=3到redo log.
E.记录B=2到undo log.
F.修改B=4.
G.记录B=4到redo log.
H.将redo log写入磁盘。
I.事务提交

• 취소 +는 다시 실행 업무를 제공합니다
  • 오래 지속되는 보장하기 위해서는, 리두 로그 트랜잭션 커밋 될 때까지 유지해야합니다.
  • 데이터는 트랜잭션 커밋 전에 디스크에 기록하지만, 메모리에 캐시 할 필요는 없다.
  • 영구 리두 로그 보증 거래.
  • 취소 로그 자성 보증 거래.
  • 나중에 리두 로그 영구 저장보다 더 작성해야합니다 암시 적 특성 데이터가있다.

IO 성능

취소 + 다시 실행은 주요 고려 사항의 디자인은 IO 성능을 향상하는 것입니다. 입출력 쓰기 데이터를 줄이고, 데이터를 캐싱하여 있지만. 그러나 소개하고 새로운 IO, 재실행 IO를 로그 쓰기. 재실행 로그 IO 성능이 좋지 않은 경우, 성능을 개선 할 목적으로 서비스를 제공 할 수 없다. 리두 로그가 더 나은 IO 성능을 가질 수 있도록하기 위해, 리두 로그 이노 디자인의 특징은 다음과 같습니다

• 리두 로그는 연속 된 공간에 저장하십시오. 완전히 로그 파일에 공간을 할당 할 수 있도록 시스템이 처음 시작할 때.
  또한 순차적 IO에 의한 성능을 향상시키기 위해 순차적으로 재실행 로그를 기록.

• 일괄 로그에 기록. 직접 파일에 쓸 수 있지만 처음 기록 된 리두 로그 버퍼되지 로그인합니다. (예 : 트랜잭션 커밋 등) 디스크에 로그를 새로 고침 할 필요가있을 때, 로그의 많은과 함께 디스크에 기록됩니다.

• 메모리 공간을 공유 리두 로그 동시 트랜잭션은 자신의 실행 순서 리두 로그 문을 교대로 로그가 차지하는 공간을 줄이기 위해 함께 기록됩니다. 예를 들어, 컨텐츠 리두 로그 기록은 다음과 같습니다

  记录1: <trx1, insert …>
  记录2: <trx2, update …>
  记录3: <trx1, delete …>
  记录4: <trx3, update …>
  记录5: <trx2, insert …>
  

• 트랜잭션이 디스크 리두 로그에 기록됩니다 위의 이유는, 기록합니다 때문에 다른 커밋되지 않은 트랜잭션은 디스크에 기록됩니다.

• 롤 다시에 거래 요구는, 그것의 리두 로그의 기록에 리두 로그에서 삭제되지 않습니다 만 리두 로그에 순차 추가 운영.

복구 (복구)

복구 전략 :로 그러므로 복구하는 동안, 이러한 거래는 특별해야, 이전 커밋되지 않은 트랜잭션 및 트랜잭션이 리두 로그를 기록됩니다 롤 다시 언급
치료. 두 개의 서로 다른 복구 전략이있다 :

복구, 그냥 트랜잭션을 다시 A.이 제출되었습니다.
B. 복구는 커밋되지 않은 트랜잭션과 롤백 트랜잭션을 포함한 모든 트랜잭션을 다시 실행합니다. 그런 다음 취소로 로그인하는 커밋되지 않은 트랜잭션을 롤백.

InnoDB 스토리지 엔진에 대한 복구 메커니즘

MySQL의 InnoDB의 데이터베이스 스토리지 엔진은 전략 B, 복구 메커니즘 InnoDB 스토리지 엔진은 다음과 같은 특징이 있습니다를 사용합니다 :

• 때 리두 로그를 다시 실행 및 트랜잭션에 대해 걱정하지 않는다 . 복구, 아니, ROLLBACK 동작을 BEGIN 없으며, COMMIT. 각 로그는 중요한 일에 대해 걱정하지 않습니다. 트랜잭션 ID 및 기타 거래 관련 내용이 리두 로그에 기록되지만, 이러한 데이터의 한 부분으로 조작 할 만 내용입니다.

• 사용 B 실행 취소 로그 전략은 지속되어야하며 실행 취소 로그 디스크에 기록 해당하는 리두 로그 전에 작성해야합니다. 지속성이 복잡해 지도록 취소 및 재실행 로그이 협회. 복잡성을 감소시키기 위하여, 이노가 취소 로그 데이터를 고려하므로 리두 로그 기록 동작 것 취소 로그 레코드있다. 캐시보다는 리두 로그 전에 디스크에 기록 그래서 당신은 로그 데이터를 취소 할 수있다. 리두 로그는 실행 취소 로그 작동이 같은 외모를 포함 :

  记录1: <trx1, **Undo log insert** <undo_insert …>>
  记录2: <trx1, insert …>
  记录3: <trx2, **Undo log insert** <undo_update …>>
  记录4: <trx2, update …>
  记录5: <trx3, ***\*Undo log insert\**** <undo_delete …>>
  记录6: <trx3, delete …>
  

• 여기서 문제가 명확하지 않다가있다. 트랜잭션하지 다시 실행하기 때문에, 그 다시 실행 트랜잭션이 롤백 할 등을 의미? 사실 그것입니다. 한편 이노 디비는 트랜잭션도 롤백의 리두 로그에 기록 될 때 작동합니다. 롤백 동작은 기본적으로도 재실행 로그에 기록 된 데이터의 데이터 때문에 롤백 동작을 수정한다. 리두 로그 업무의 롤백은 다음과 같습니다 :

  记录1: <trx1, Undo log insert <undo_insert …>>
  记录2: <trx1, **insert A**…>
  记录3: <trx1, Undo log insert <undo_update …>>
  记录4: <trx1, **update B**…>
  记录5: <trx1, Undo log insert <undo_delete …>>
  记录6: <trx1, **delete C**…>
  记录7: <trx1, **insert C**>
  记录8: <trx1, **update B** to old value>
  记录9: <trx1, **delete A>**
  

• 복구 작업을 다시 실행 한 후 실행 취소, 그것은 데이터 일관성을 파괴하지 않을 때 트랜잭션은 다시 롤백됩니다.

이노 스토리지 엔진 관련 기능
재실행 : recv_recovery_from_checkpoint_start ()
취소 : recv_recovery_rollback_active ()
취소 재실행 로그의 로그 : trx_undof_page_add_undo_rec_log ()

참고

http://mysql.taobao.org/monthly/2015/04/01/
http://mysql.taobao.org/monthly/2016/07/01/
http://www.zhdba.com/mysqlops/2012/ 04 / 06 / 이노 - 로그 1 /
https://juejin.im/post/5c3c5c0451882525487c498d
https://www.cnblogs.com/cchust/p/4439107.html
https://segmentfault.com/a/1190000014810628
은 https : / /blog.csdn.net/joy0921/article/details/80130768
https://www.cnblogs.com/xinysu/p/6555082.html