mysql 로그 파일 실행 취소 로그 및 다시 실행 로그를 설정하는 방법

1 undo

1.1 undo

undo 로그는 데이터가 수정되기 전의 값을 저장하는 데 사용됩니다. tba 테이블에서 id=2인 행 데이터를 수정하고 Name='을 변경한다고 가정합니다. B'를 Name = 'B2'로 변경하면 Undo 로그를 사용하여 Name = 'B'의 레코드를 저장합니다. 이 수정에서 예외가 발생하면 Undo 로그를 사용하여 롤백 작업을 구현하고 일관성을 보장할 수 있습니다. 거래의.

데이터에 대한 변경 작업은 주로 INSERT UPDATE DELETE에서 나오며 UNDO LOG는 두 가지 유형으로 나누어집니다. 하나는 삽입된 고유 키 값을 기록하는 INSERT_UNDO(INSERT 작업)이고 다른 하나는 UPDATE_UNDO(UPDATE 및 DELETE 작업 포함)입니다. ), 수정된 고유 키 값과 이전 열 레코드를 기록합니다. ㅋㅋㅋ

4D

1.2 undo 매개변수

MySQL undo 관련 매개변수 설정은 다음과 같습니다.

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

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_undo_log_truncate 시작 시 undo 테이블 공간이 inno를 초과하는 경우에만 undo 테이블 공간을 제어합니다. db_max_undo_log_size 임계값 잘라내기를 시도합니다. 이 값의 기본 크기는 1G이고, 잘라낸 후의 기본 크기는 10M입니다.

• innodb_undo_tablespaces

undo 독립 테이블스페이스 수를 설정합니다. 범위는 0~128, 기본값은 0입니다. 0은 독립 undo 테이블스페이스를 열지 않음을 의미하며 undo 로그는 테이블에 저장됩니다. ibdata 파일입니다. 이 파라미터는 MySQL 인스턴스를 초기화할 때만 지정할 수 있으며, 인스턴스가 생성된 경우 데이터베이스 구성 파일.cnf에 지정된 innodb_undo_tablespaces 수가 인스턴스 생성 시 지정된 개수보다 큰 경우에는 이 파라미터를 변경할 수 없습니다. 시작이 실패하여 매개변수 설정이 잘못되었음을 나타냅니다.

이 매개변수를 n(n>0)으로 설정하면 n개의 실행 취소 파일(undo001, undo002... undo n)이 실행 취소 디렉토리에 생성됩니다. 각 파일의 기본 크기는 10M입니다.

언제 이 매개변수를 설정해야 합니까?

DB 쓰기 부담이 높을 때 독립적인 UNDO 테이블스페이스를 설정하고, UNDO LOG를 ibdata 파일에서 분리하고, innodb_undo_directory 디렉토리를 지정해 저장하면 속도를 높일 수 있다. UNDO LOG의 읽기 및 쓰기 성능을 향상시킵니다. innodb_undo_log_truncate

• innodb의 퍼지 스레드는 innodb_undo_log_truncate 설정, innodb_max_undo_log_size의 매개 변수 값 및 UNDO 파일의 공간 재활용 및 재 시합을 수행하기위한 트렁크의 빈도에 따라 켜지거나 꺼집니다.

이 매개변수가 적용되는 전제는 독립된 테이블스페이스가 설정되어 있고 독립된 테이블스페이스의 개수가 2 이상이라는 것입니다.

실행 취소 로그 파일을 자르는 과정에서 제거 스레드는 파일에 활성 트랜잭션이 있는지 확인해야 합니다. 그렇지 않으면 실행 취소 로그 파일을 할당 불가로 표시해야 합니다. 따라서 truncate 작업을 수행하려면 최소한 2개의 독립된 테이블스페이스 파일이 필요합니다. 이를 할당 불가로 표시한 후 특정 undo 로그 파일이 있음을 기록하기 위해 독립된 파일 undo__trunc.log가 생성됩니다. 작업이 완료된 후 잘라내기 중에 오류가 발생하더라도 undo__trunc.log 파일을 삭제합니다. 프로세스가 끝나면 데이터베이스 서비스가 다시 시작됩니다. 서비스는 이 파일을 찾아서 계속해서 완료합니다. 실행 취소 로그 파일은 할당 가능으로 표시됩니다.

innodb_purge_rseg_truncate_주파수

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

1.3 실행 취소 공간 관리

독립적인 테이블스페이스를 설정해야 하는 경우 데이터베이스 인스턴스 초기화 시 독립된 테이블스페이스의 개수를 지정해야 합니다.

UNDO는 내부적으로 여러 개의 롤백 세그먼트, 즉 ibdata 시스템 테이블 공간에 저장되는 총 128개의 세그먼트로 구성됩니다. 각 resg 슬롯, 즉 각 슬롯은 ibdata 시스템 테이블 공간에 저장됩니다. 롤백 세그먼트, 내부적으로 1024개의 실행 취소 세그먼트로 구성됩니다.

롤백 세그먼트는 다음과 같이 할당됩니다.

슬롯 0, 시스템 테이블 공간용으로 예약됨

• 슬롯 1-32, 데이터베이스가 다시 시작될 때마다 재구축됩니다. 임시 테이블 공간

• slot33-127, 독립 테이블 공간이 있으면 UNDO 독립 테이블 공간을 위해 예약됩니다. 그렇지 않으면 시스템 테이블 공간을 위해 예약됩니다.

• 에서 32를 제거합니다. 롤백 세그먼트 임시 테이블 트랜잭션에 제공되는 나머지 128-32=96개의 롤백 세그먼트는 96*1024개의 동시 트랜잭션 작업을 실행할 수 있습니다. 각 트랜잭션은 트랜잭션에 임시 테이블 트랜잭션이 있는 경우 실행 취소 세그먼트 슬롯을 차지합니다. 임시 테이블 공간의 실행 취소 세그먼트 슬롯에 있는 또 다른 실행 취소 세그먼트 슬롯, 즉 2개의 실행 취소 세그먼트 슬롯을 차지합니다. 다음과 같은 경우:

  오류 로그에 동시 트랜잭션이 너무 많다는 의미이므로 비즈니스 부담을 덜어줄지 여부를 고려해야 합니다.

롤백 세그먼트는 폴링 스케줄링을 사용하여 할당됩니다. 독립 테이블스페이스가 설정된 경우 시스템 테이블스페이스 롤백 세그먼트의 실행 취소 세그먼트는 사용되지 않지만 동시에 독립 테이블스페이스가 사용됩니다. 룩백 세그먼트가 Truncate 작업 중이면 할당되지 않습니다.

2 redo

2.1 redo란 무엇입니까

데이터베이스가 데이터를 수정할 때 디스크에서 데이터 페이지를 버퍼 풀로 읽어온 다음 버퍼 풀에서 수정해야 합니다. 이때 버퍼 풀에 있는 데이터 페이지가 디스크에 있는 데이터 페이지의 내용과 일치하지 않는 경우가 있는데, 이때 비정상적인 DB 서비스 재시작이 발생하면 해당 데이터는 더티 페이지라고 합니다. 메모리에 없고 디스크 파일에 동기화되지 않습니다(디스크 파일에 대한 동기화는 임의 IO임). 즉, 이때 파일이 있으면 데이터 페이지에 있는 경우 데이터 손실이 발생합니다. 버퍼 풀이 변경되면 해당 수정 기록이 이 파일에 기록되고(로그는 순차 IO에 기록됨에 유의) DB 서비스가 중단되어 DB가 복원되면 이 파일에 기록된 내용을 다시 적용할 수 있습니다. 디스크 파일과 데이터는 일관성을 유지합니다.

이 파일은 수정된 데이터를 순차적으로 기록하는 데 사용되는 Redo 로그입니다. 다음과 같은 이점을 가져올 수 있습니다.

• 버퍼 풀의 더티 페이지가 디스크에 새로 고쳐지지 않은 경우 서비스 시작 후 새로 고쳐야 할 레코드를 디스크 파일에서 찾을 수 있습니다.

• 버퍼 풀의 데이터를 디스크 파일로 직접 플러시하는 랜덤 IO로 효율성이 떨어지는 반면, 버퍼 풀의 데이터를 리두 로그에 기록하는 것은 순차 IO입니다.

가설 tba 테이블에서 id=2로 행 데이터를 수정하고 Name='B'를 Name = 'B2'로 변경하면 리두 로그가 저장됩니다. Name='B2'의 레코드입니다. 이 수정 사항이 디스크 파일에 플러시되는 경우 예외가 발생하면 리두 로그를 사용하여 리두 작업을 구현하여 트랜잭션의 내구성을 보장할 수 있습니다. ㅋㅋㅋ

4D

여기서 리두 로그와 바이너리 로그의 차이점에 주목하세요. 리두 로그는 스토리지 엔진 계층에서 생성되는 반면 바이너리 로그는 데이터베이스 계층에서 생성됩니다. 대규모 트랜잭션이 100,000행의 레코드를 tba에 삽입한다고 가정해 보겠습니다. 이 과정에서 레코드는 계속해서 순차적으로 리두 로그에 기록되지만 바이너리 로그에는 기록되지 않습니다. 트랜잭션이 커밋된 경우에만 바이너리 로그 파일에 기록됩니다. 한 번. 바이너리 로그에는 행(Row), 명령문(Statement), 혼합(Mix) 등 3가지 기록 형식이 있으며, 이들 간의 기록 형식이 다릅니다.

2.2redoParameters

• innodb_log_files_in_group

redo 로그 파일 수, 이름 지정 방법: ib_logfile0, iblogfile1... . 기본값은 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 로그 캐시 영역, 기본 8M, 1로 설정 가능 8M. 디스크에 트랜잭션 로그 쓰기를 지연하고, redo 로그를 버퍼에 넣은 다음 innodb_flush_log_at_trx_commit 매개변수 설정에 따라 버퍼에서 디스크로 로그를 플러시합니다.

• innodb_flush_log_at_trx_commit

• innodb_flush_log_at_trx_commit=1, 각 커밋은 리두 로그 버퍼의 리두 로그를 시스템에 기록하고 이를 디스크 파일에 fsync합니다.

• innodb_flush_log_at_trx_commit=2, 트랜잭션이 커밋될 때마다 MySQL은 리두 로그 버퍼의 로그를 시스템에 기록하지만 파일 시스템 버퍼에만 기록하며 시스템은 이를 내부적으로 디스크 파일에 fsync합니다. 데이터베이스 인스턴스가 충돌하더라도 다시 실행 로그는 손실되지 않습니다. 그러나 서버가 충돌하면 파일 시스템 버퍼가 디스크 파일에 fsync할 시간이 없기 때문에 데이터의 이 부분이 손실됩니다.

• innodb_flush_log_at_trx_commit=0, 트랜잭션 프로세스 중에는 다른 설정과 마찬가지로 로그가 항상 redo 로그 버퍼에 있지만 트랜잭션이 커밋되면 redo 쓰기 작업이 발생하지 않지만 MySQL 내부 작업은 1초에 한 번씩 발생하므로, 리두 로그 버퍼에서 시스템에 데이터를 씁니다. 충돌이 발생하면 1초 이내의 트랜잭션 수정 작업이 손실됩니다.

• 참고: 프로세스 예약 정책 문제로 인해 이 "초당 한 번 플러시(디스크로 플러시) 작업 수행"은 "초당" 100%를 보장하지 않습니다.

2.3 redo Space Management

Redo 로그 파일의 이름은 ib_logfile[number]로 지정됩니다. Redo 로그는 파일이 가득 차면 첫 번째 파일로 돌아갑니다. 그리고 덮어씁니다. (단, redo 체크포인트를 수행하면 첫 번째 로그 파일의 헤더 체크포인트 표시도 함께 업데이트되므로 엄밀히 말하면 순차 쓰기에 포함되지 않습니다.)

실제로 리두 로그는 리두 로그 버퍼와 리두 로그 파일의 두 부분으로 구성됩니다. 버퍼 풀에서 데이터 수정 사항은 리두 로그 버퍼에 기록됩니다. 다음과 같은 경우 리두 로그가 리두 로그 파일로 플러시됩니다.

• 리두 로그 버퍼 공간 부족

• 트랜잭션 제출(에 따라 다름) innodb_flush_log_at_trx_commit 매개변수 설정)

• 백그라운드 스레드

• Do checkpoint

• Instance shutdown

• binlogswitching

3 실행 취소 및 다시 실행

3.1 실행 취소 + Redo 트랜잭션의 단순화된 프로세스

각각 1과 2의 값을 갖는 두 개의 데이터 A와 B가 있다고 가정합니다. 트랜잭션의 작업 내용은 1을 3으로 수정하고 2를 4로 수정합니다. 기록은 다음과 같습니다(단순화):

A. 트랜잭션이 시작됩니다.

B. 로그를 실행 취소하려면 A=1을 기록합니다.

C. A=3을 수정합니다.

D. 로그를 다시 실행하려면 A=3을 기록합니다.

E. 로그를 실행 취소하려면 B=2를 기록합니다.

F. B=4를 수정합니다.

G. 로그를 다시 실행하려면 B=4를 기록합니다.

H. 디스크에 다시 실행 로그를 씁니다.

I. Transaction submit

3.2 IO Impact

Undo + Redo를 설계하는 주요 목적은 입출력 성능을 향상시키고 데이터베이스의 처리 용량을 늘리는 것입니다. B D E G H는 모두 새로운 작업이지만 B D E G는 버퍼 영역에 버퍼링되어 있음을 알 수 있습니다. G만 IO 작업을 추가합니다. Redo Log가 더 나은 IO 성능을 가질 수 있도록 InnoDB의 Redo Log 설계에는 다음과 같은 특징이 있습니다.

B. Redo Log가 연속된 공간에 저장되도록 하세요. 따라서 시스템을 처음 시작하면 로그 파일의 공간이 완전히 할당됩니다. 성능 향상을 위해 Redo Log는 순차적 IO 방식으로 기록되어 단계별로 완료될 예정이다.

B. 로그를 일괄적으로 작성합니다. 로그는 파일에 직접 기록되지 않고 먼저 리두 로그 버퍼에 기록됩니다. 로그를 디스크에 플러시해야 하는 경우(예: 트랜잭션 제출) 많은 로그가 디스크에 함께 기록됩니다.

C. 동시성 트랜잭션은 Redo Log 저장 공간을 공유하며, 해당 트랜잭션의 Redo Log는 명령문의 실행 순서에 따라 교대로 함께 기록되어 로그가 차지하는 공간을 줄인다. 예를 들어 Redo 로그의 레코드 내용은 다음과 같을 수 있습니다.

레코드 1:
레코드 2:
레코드 3:
레코드 4:
레코드 5:

D. C 때문에 트랜잭션이 Redo Log를 disk 를 사용하면 커밋되지 않은 다른 트랜잭션의 로그도 디스크에 기록됩니다.

E. Redo Log에서는 순차 추가 작업만 수행됩니다. 트랜잭션을 롤백해야 하는 경우 해당 Redo Log 기록은 Redo Log에서 삭제되지 않습니다.

3.3 Recovery

앞서 언급한 것처럼 커밋되지 않은 트랜잭션과 롤백된 트랜잭션도 Redo Log에 기록되므로 이러한 트랜잭션은 복구 중에 특별히 처리되어야 합니다. 2가지 복구 전략이 있습니다.

A. 복구 시 커밋된 트랜잭션만 다시 실행하세요.

복구 시 커밋되지 않은 트랜잭션과 롤백된 트랜잭션을 포함하여 모든 트랜잭션을 다시 실행해야 합니다. 그런 다음 실행 취소 로그를 통해 커밋되지 않은 트랜잭션을 롤백합니다.

MySQL 데이터베이스 InnoDB 스토리지 엔진은 전략 B를 사용합니다.

InnoDB 스토리지 엔진의 복구 메커니즘에는 여러 가지 특징이 있습니다. A. Redo Log를 다시 실행할 때

트랜잭션성에 신경 쓰지 않습니다

. 복구 중에는 BEGIN, COMMIT 또는 ROLLBACK 동작이 없습니다. 각 로그가 어느 트랜잭션에 속하는지는 중요하지 않습니다. Redo Log에는 트랜잭션 ID 등 트랜잭션 관련 내용이 기록되지만, 이는 운용되는 데이터의 일부로만 간주된다. B. 전략 B를 사용할 경우 Undo Log가 유지되어야 하며, Redo Log를 작성하기 전에 해당 Undo Log를 디스크에 작성해야 합니다. Undo와 Redo Log 간의 이러한 관계는 지속성을 복잡하게 만듭니다. 복잡성을 줄이기 위해 InnoDB는 Undo Log를 데이터로 취급하므로 Undo Log를 기록하는 작업도 Redo 로그에 기록됩니다. 실행 취소 로그를 메모리에 캐시하면 다시 실행 로그를 쓰기 전에 디스크에 다시 쓸 필요가 없습니다.

실행 취소 로그 작업이 포함된 Redo 로그는 다음과 같습니다.

레코드 1: Undo log insert
> 레코드 2: 레코드 3: 로그 삽입 실행 취소
> 레코드 4: 레코드 5:
로그 삽입 실행 취소 > 레코드 6:
C. 이 시점에서 아직 명확하게 밝혀지지 않은 문제가 있습니다. Redo는 트랜잭션이 아니기 때문에 롤백된 트랜잭션을 다시 실행하지 않을까요?

사실이에요. 동시에 Innodb는 트랜잭션 롤백 중 작업을 리두 로그에 기록합니다. 롤백 작업을 수행하면 데이터 수정 사항이 Redo Log에 기록됩니다. 롤백 작업을 수행하면 기본적으로 데이터도 수정되기 때문입니다.

롤백된 트랜잭션의 Redo 로그는 다음과 같습니다.

레코드 1:

레코드 2: insert A
&hellip ;> 레코드 3: > 레코드 4: update B
…> 레코드 5: > 레코드 6: delete C
…> 레코드 7: insert C
> 레코드 8: update B 오래된 가치 섹스에.

위 내용은 mysql 로그 파일 실행 취소 로그 및 다시 실행 로그를 설정하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!