MySQL 로그의 redo 로그 및 undo 로그에 대한 지식 포인트는 무엇입니까?

Redo 로그

REDO LOG는 MySQL 서버가 예기치 않게 충돌하거나 다운될 때 제출된 트랜잭션이 디스크에 유지되도록 합니다(지속성).

InnoDB는 페이지 단위로 레코드를 연산하며, 추가, 삭제, 수정 및 쿼리를 수행하면 전체 페이지가 버퍼 풀(디스크 -> 메모리)에 로드됩니다. 트랜잭션의 수정 작업은 디스크의 데이터를 직접 수정하지 않습니다. 먼저 메모리의 버퍼 풀에 있는 데이터가 정기적인 간격으로 백그라운드 스레드에 의해 디스크에 비동기적으로 새로 고쳐집니다.

버퍼 풀: 인덱스와 데이터를 저장하고, 읽기 및 쓰기 속도를 높이고, 메모리에서 데이터 페이지를 직접 조작할 수 있으며, 버퍼 풀의 더티 페이지를 디스크에 쓰는 전용 스레드가 있습니다.

디스크의 데이터를 직접 수정하면 어떨까요?

디스크 데이터를 직접 수정하는 경우에는 랜덤 IO이기 때문에 수정된 데이터는 디스크의 여러 위치에 분산되어 있어 앞뒤로 검색해야 하기 때문에 적중률이 낮고 게다가 소모량이 높습니다. , 약간의 수정으로 전체 페이지를 교체해야 합니다. 디스크에 플러시하면 활용도가 낮습니다.

이에 비해 순차 IO는 디스크 데이터가 디스크 한 부분에 분산되므로 검색 프로세스가 생략되고 탐색 시간이 걸립니다. 저장되었습니다.

백그라운드 스레드를 사용하여 특정 빈도로 디스크를 새로 고치면 임의 IO의 빈도를 줄이고 처리량을 늘릴 수 있습니다. 이것이 버퍼 풀을 사용하는 근본적인 이유입니다.

메모리를 수정한 후 디스크에 비동기적으로 동기화하는 문제:

버퍼 풀은 메모리의 영역이므로 시스템이 예기치 않게 충돌하면 일부 더티 데이터가 새로 고쳐지지 않을 수 있습니다. 제때에 디스크가 삭제되고 거래의 내구성이 보장되지 않습니다. 따라서 리두 로그가 도입되었습니다. 데이터 수정 시 xx 페이지의 xx 오프셋이 xx만큼 변경되었음을 알리는 추가 로그가 기록됩니다. 시스템 충돌 시 로그 내용을 기반으로 복구할 수 있습니다.

로그 쓰기와 디스크 새로 고침의 차이점은 다음과 같습니다. 로그 쓰기는 추가 쓰기, 순차 IO, 속도가 더 빠르고 쓰기 내용이 상대적으로 작습니다.

redo 로그는 두 부분으로 구성됩니다.

1. redo 로그 버퍼(메모리 레벨, 기본값은 16M, innodb_log_buffer_size 매개변수를 통해 수정 가능)

2. redo 로그 파일(영구, 디스크 레벨)

수정 작업의 일반적인 프로세스:

1단계: 먼저 원본 변환 데이터 디스크에서 메모리로 읽어 데이터의 메모리 복사본을 수정하고 더티 데이터를 생성합니다

2단계: 리두 로그를 생성하고 이를 리두 로그 버퍼에 쓰고 수정된 데이터 값을 기록합니다

3단계 : 기본적으로 트랜잭션이 제출된 후 리두 로그 버퍼의 내용이 리두 로그 파일로 플러시되고 리두 로그 파일이 파일에 추가됩니다.

4단계: 메모리의 수정된 데이터를 정기적으로 새로 고칩니다. (여기서 말하는 것은 백그라운드 스레드에 의해 적시에 플러시되지 않은 더티 데이터입니다)

일반적으로 Write-Ahead Log(사전 로그 지속성)라고 하는 것은 해당 로그 페이지를 이전에 메모리에 유지하는 것을 의미합니다. 데이터 페이지를 유지합니다.

리두 로그의 이점:

• 디스크 새로 고침 빈도 감소

• redo 로그는 작은 공간을 차지함

• redo 로그는 빠르게 쓰기

리두 로그가 트랜잭션의 내구성을 확실히 보장할 수 있나요?

반드시 그런 것은 아니지만 이는 리두 로그 버퍼도 메모리에 있기 때문에 리두 로그 플러시 전략에 따라 다릅니다. 트랜잭션이 제출된 후 리두 로그 버퍼가 지속성을 위해 리두 로그 파일에 데이터를 새로 고칠 시간이 없습니다. . 현재로서는 가동 중지 시간이 발생해도 데이터가 손실됩니다. 어떻게 해결하나요? 스윕 전략.

redo 로그 플러시 전략

InnoDB는 리두 로그 버퍼가 리두 로그 파일로 플러시되는 시기를 제어하기 위해 innodb_flush_log_at_trx_commit 매개변수에 대한 세 가지 전략을 제공합니다.

• 값은 0: 백그라운드 스레드를 시작하고 매 디스크로 플러시합니다. 1s, 트랜잭션을 제출할 때 새로 고칠 필요가 없습니다

• 값이 1: 커밋 시 동기 새로 고침이 수행되어(기본값) 데이터의 내구성이 실제로 보장됩니다

• 값이 2: 언제 커밋하면 그냥 새로 고침 os의 커널 버퍼를 입력합니다. 구체적인 플러시 시간은 불확실합니다.

값이 0인 경우:

1초, 1초의 데이터 간격이 있기 때문입니다. 최악의 경우 패하게 됩니다.

값이 1인 상황:

커밋할 때 리두 로그 버퍼를 리두 로그 파일에 적극적으로 새로 고쳐야 합니다. 중간에 다운되면 트랜잭션이 실패하게 됩니다. 손실이 발생하면 거래의 지속성이 보장될 수 있습니다. 하지만 효율성은 최악이다.

값이 2인 경우: OS에 따라 결정됩니다.

거래 성능을 향상시키기 위해 0 또는 2로 조정할 수 있지만 ACID 특성을 잃습니다

기타 매개변수

• innodb_log_group_home_dir: 리두 로그 파일 그룹이 위치한 경로를 지정합니다. 기본값은 ./이며 이는 데이터베이스의 데이터 디렉터리에 있음을 의미합니다. MySQL의 기본 데이터 디렉터리에는 ib_logfile0과 ib_logfile1이라는 두 개의 파일이 있습니다. 로그 버퍼의 로그는 기본적으로 이 두 디스크 파일로 플러시됩니다.

• innodb_log_files_in_group: 리두 로그 파일 수를 지정합니다. 이름 지정 방법은 다음과 같습니다: ib_logfile0, iblogfile1... iblogfilen. 기본값은 2이고 최대값은 100입니다.

• 기본적으로 innodb_log_file_size의 크기는 48M로 설정되어 있으며, 이는 단일 리두 로그 파일의 크기 설정에 사용됩니다.

Undo Log

undo 로그는 트랜잭션의 원자성과 일관성을 보장하는 데 사용됩니다. 두 가지 기능을 가지고 있습니다. ① 롤백 작업 제공 ② 다중 버전 제어 MVVC

Rollback 작업

앞서 Redo 로그에서 언급했듯이 백그라운드 스레드는 버퍼 풀에 있는 데이터를 수시로 디스크에 새로 고치지만, 이 기간 동안 다양한 오류(다운타임)가 발생하거나 롤백 문이 실행된 다음 이전에 브러싱된 작업을 롤백하여 원자성을 보장해야 합니다. 실행 취소 로그는 트랜잭션 롤백을 제공합니다.

MVVC

읽기 행이 다른 트랜잭션에 의해 잠긴 경우 실행 취소 로그에서 해당 행에 기록된 이전 데이터 버전을 분석할 수 있으므로 사용자는 현재 트랜잭션 작업 이전에 데이터를 읽을 수 있습니다. — —스냅샷 읽기.

스냅샷 읽기: SQL에서 읽은 데이터는 기록 버전이며 잠금이 필요하지 않으며 일반 SELECT는 스냅샷 읽기입니다.

실행 취소 로그 구성 요소:

• 레코드 삽입 시 롤백 시 데이터가 삭제될 수 있도록 레코드의 기본 키 값을 기록해야 합니다.

• 기록 업데이트 시 수정된 이전 값을 모두 기록하고, 롤백 시 이전 값으로 업데이트해야 합니다.

• 삭제 시 모든 기록을 기록해야 하며, 롤백 시 해당 내용의 기록을 다시 삽입해야 합니다.

select 작업은 실행 취소 로그를 생성하지 않습니다

롤백 세그먼트 및 실행 취소 페이지

InnoDB 스토리지 엔진에서 실행 취소 로그는 롤백 세그먼트 롤백 세그먼트를 사용하여 저장하며 각 롤백 세그먼트에는 1024개의 실행 취소 로그 세그먼트가 포함됩니다. MySQL5.5 이후에는 총 128개의 롤백 세그먼트가 있습니다. 즉, 총 128*1024번의 실행 취소 작업을 기록할 수 있습니다.

각 트랜잭션은 하나의 롤백 세그먼트만 사용하며 하나의 롤백 세그먼트는 동시에 여러 트랜잭션을 제공할 수 있습니다.

일부 트랜잭션에서는 이전 데이터 버전(스냅샷 읽기)을 읽으려고 할 수 있으므로 실행 취소 로그 삭제는 트랜잭션 커밋 직후에 수행할 수 없습니다. 따라서 트랜잭션이 커밋되면 실행 취소 로그는 버전 체인이라는 연결된 목록에 저장됩니다. 실행 취소 로그의 삭제 여부는 제거라는 스레드에 의해 판단됩니다.

Undo 유형

undo 로그는 다음과 같이 구분됩니다.

insert undo log

삽입 작업 기록은 트랜잭션 자체에만 표시되고 다른 트랜잭션에는 표시되지 않기 때문에(트랜잭션 격리의 요구 사항) undo는 로그는 트랜잭션이 커밋된 후 직접 삭제할 수 있습니다. 퍼지 작업이 필요하지 않습니다.

update undo log

Undo 로그는 삭제 및 업데이트 작업에 대한 변경 사항을 기록합니다. MVCC 메커니즘을 지원하기 위해 트랜잭션이 커밋되는 즉시 실행 취소 로그를 삭제할 수 없습니다. 제출 시 실행 취소 로그 목록에 추가하고 정리 스레드가 최종 삭제를 수행할 때까지 기다립니다.

실행 취소 로그의 수명 주기

A=1, B=2라는 2개의 값이 있고 트랜잭션이 A를 3으로, B를 4로 수정한다고 가정합니다. 수정 프로세스는 다음과 같이 단순화될 수 있습니다.

1 . 시작
2.A=1을 기록해 로그를 취소
3.업데이트 A=3
4.A=3을 기록해 로그를 다시 실행
5.B=2를 기록해 로그
6.업데이트 B=4
7.B를 기록 =4 - 재실행 로그
8. 디스크에 재실행 로그 새로 고침
9.commit

• 1~8단계 중 시스템이 다운되고 트랜잭션이 제출되지 않으면 트랜잭션은 데이터에 영향을 미치지 않습니다. 디스크에 영향을 주지 마십시오.

• 8~9시 사이에 다운되면 복구 후 롤백을 선택하거나, 현재 redo 로그가 유지되었기 때문에 트랜잭션 제출을 계속 완료하도록 선택할 수 있습니다.

• 9 이후 시스템이 다운되고 메모리 맵에서 변경된 데이터가 디스크로 다시 플러시될 시간이 없다면 시스템이 복원된 후 데이터는 다음 지침에 따라 디스크로 다시 플러시될 수 있습니다. 다시 실행 로그.

자세한 생성 프로세스

InnoDB 엔진의 경우 레코드 자체의 데이터 외에도 각 행 레코드에는 여러 개의 숨겨진 열이 있습니다.

• DB_ROW_ID∶레코드의 기본 키 ID입니다.

• DB_TRX_ID: 기록이 수정되면 해당 거래의 ID가 기록됩니다.

• DB_ROLL_PTR: 롤백 포인터, 버전 체인의 포인터.

INSERT를 실행할 때:

begin;
INSERT INTO user (name) VALUES ('tom');

데이터가 삽입될 때마다 삽입 작업에 대한 실행 취소 로그가 생성되고 데이터의 롤백 포인터가 이 로그를 가리킵니다. Undo 로그에는 Undo 로그의 일련번호, 삽입된 기본 키의 열과 값이 기록됩니다. 그러면 롤백 수행 시 기본 키를 통해 해당 데이터를 직접 삭제할 수 있습니다.

UPDATE 실행 시:

업데이트 작업을 수행할 때 기본 키를 업데이트하는 경우와 기본 키를 업데이트하지 않는 경우의 두 가지 경우를 포함하여 업데이트 실행 취소 로그가 생성됩니다. 이제 업데이트 작업이 수행된다고 가정합니다.

UPDATE user SET name='Sun' WHERE id=1;

이 때 새 실행 취소 로그 레코드가 버전 체인에 추가되고 해당 실행 취소 번호는 1이며 새 실행 취소 로그의 롤백 포인터는 다음을 가리킵니다. 이전 실행 취소 로그(실행 취소 번호=0)

지금 실행한다고 가정해 보겠습니다.

UPDATE user SET id=2 WHERE id=1;

기본 키 업데이트 작업의 경우 원본 데이터 deletemark 플래그가 먼저 열립니다. 이때 데이터는 실제로 삭제되지 않습니다. 나중에 새로운 데이터가 삽입되면 새 데이터도 실행 취소 로그를 생성하고 실행 취소 로그의 시퀀스 번호가 증가합니다.

데이터가 변경될 때마다 실행 취소 로그가 생성되는 것을 확인할 수 있습니다. 레코드가 여러 번 변경되면 실행 취소 로그가 여러 개 생성되며, 실행 취소 로그는 변경 전의 로그를 기록하며, 각 실행 취소 로그의 시퀀스 번호는 증가합니다. , 롤백하고 싶을 때 시퀀스 번호에 따라 앞으로 밀어서 원본 데이터를 찾으세요.

Undo 로그를 롤백하는 방법

위의 예에서 롤백이 수행되었다고 가정하면 해당 프로세스는 다음과 같습니다.

1 undo no=3의 로그를 통해 id=2인 데이터를 삭제합니다

2 . undo no=2의 로그를 통해 id=1인 데이터의 deletemark를 0으로 복원합니다. 3. undo no=1의 로그를 통해 id=1인 데이터의 이름을 Tom에게 복원합니다. 0의 로그는 id=1

MySQL MVVC 다중 버전 동시성 제어

Extension

bin log

바이너리 로그(업데이트라고도 함)를 사용하여 데이터를 삭제합니다. 로그는 데이터베이스에 대한 변경 사항을 기록하는 바이너리 형식의 로그 파일 유형입니다. 데이터베이스에서 실행된 모든 업데이트 문을 기록합니다.

binlog의 주요 응용 시나리오:

데이터 복구: MySQL이 예기치 않게 중지되면 복구 및 백업에 이 로그를 사용할 수 있습니다.

• 데이터 복제: 마스터는 바이너리 로그를 슬레이브에 전달하여 마스터-슬레이브 데이터를 얻습니다. 일관성

• show variables like '%log_bin%';

  bin 로그 로그 보기:

  mysqlbinlog -v "/var/lib/mysql/binlog/xxx.000002"

로그를 사용하여 데이터 복구:

mysqlbinlog [option] filename|mysql –uuser -ppass;

바이너리 로그 삭제:

PURGE {MASTER | BINARY} LOGS TO ‘指定日志文件名'
PURGE {MASTER | BINARY} LOGS BEFORE ‘指定日期'

쓰기 타이밍

트랜잭션 실행 중에 로그가 먼저 bin 로그에 기록됩니다. 캐시 및 트랜잭션 제출 시 binlog 캐시를 binlog 파일에 씁니다. 트랜잭션의 binlog는 분할할 수 없기 때문에 트랜잭션의 크기에 관계없이 한 번만 작성해야 하므로 시스템은 각 스레드에 메모리 블록을 binlog 캐시로 할당합니다.

binlog와 redo 로그 비교

InnoDB 스토리지 엔진 레이어에서 생성된 redo 로그는 "어떤 데이터 페이지가 어떤 수정을 받았는지" 기록하는 데 사용되는 물리적 로그입니다.

• binlog는 논리적 로그이며, 기록된 내용은 문의 원본 논리이며, 이는 서비스 레이어에 속하는 ID=2인 줄의 c 필드에 1을 추가하는 것과 유사합니다.

• 두 가지 초점도 다릅니다. Redo 로그는 InnoDB에 충돌 복구 기능을 제공하고 binlog는 MySQL 클러스터 아키텍처의 데이터 일관성을 보장합니다.

2단계 커밋

업데이트 문이 실행되는 동안 redo 로그와 binlog 두 개의 로그가 기록됩니다. 기본 트랜잭션을 기반으로 redo 로그는 트랜잭션 실행 중에 지속적으로 기록될 수 있지만 binlog는 로그만 기록됩니다. 트랜잭션이 제출될 때 기록되므로 redo 로그와 binlog의 작성 시점이 다릅니다.

리두 로그와 binlog 사이의 논리가 일치하지 않습니다. 어떤 문제가 발생하나요?

업데이트 문을 예로 들어 보겠습니다. id=2인 레코드의 경우 필드 c 값이 0이라고 가정합니다. 필드 c 값을 1로 업데이트합니다. SQL 문은 update T set c=1 where id=2입니다.

실행 중 redo 로그를 작성한 후 binlog 로그를 작성하는 중에 예외가 발생한다고 가정하면 어떻게 될까요?

binlog 예외로 인해 쓰기가 중단되므로 해당 수정 기록이 없습니다. 따라서 binlog 로그를 사용하여 데이터를 복원하거나 슬레이브가 마스터의 binlog를 읽을 때 이 업데이트는 생략됩니다. 복원된 라인의 c 값은 0이고 원본 데이터베이스의 이 라인의 c 값은 1입니다. 리두 로그 복구의 최종 데이터가 일치하지 않습니다.

InnoDB 스토리지 엔진은 두 로그 간의 논리적 일관성 문제를 처리하기 위해 2단계 커밋 방식을 채택합니다. 2단계 제출은 리두 로그를 준비와 커밋의 두 단계로 나누는 것을 의미합니다.

최종 제출된 리두 로그와 bin 로그를 함께 바인딩하도록 합니다. 앞서 언급한 것처럼 트랜잭션이 커밋되면 기본적으로 커밋이 성공하기 전에 리두 로그를 동기화해야 하므로 함께 바인딩하면 bin 로그에도 이 기능이 있어 데이터가 손실되지 않도록 보장합니다.

2단계 커밋을 사용한 후, binlog에 쓸 때 예외가 발생하더라도 아무런 영향이 없습니다. MySQL이 리두 로그를 기반으로 데이터를 복원할 때 리두 로그가 여전히 준비 단계에 있음을 발견하기 때문입니다. 해당 binlog 로그가 없으므로 제출이 실패하면 데이터를 롤백합니다.

또 다른 시나리오에서는 다시 실행 로그의 커밋 단계 중에 예외가 발생합니다. 트랜잭션이 롤백되나요?

트랜잭션을 롤백하지 않고 위 그림에 표시된 로직을 실행합니다. 비록 리두 로그가 준비 단계에 있지만 해당 binlog 로그는 트랜잭션 ID를 통해 찾을 수 있으므로 MySQL에서는 이를 다음과 같이 간주합니다. 데이터를 복원하려면 트랜잭션을 커밋하세요.

위 내용은 MySQL 로그의 redo 로그 및 undo 로그에 대한 지식 포인트는 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!