MySQL 트랜잭션의 다시 실행 및 실행 취소 분석(그림 및 텍스트)

이 기사의 내용은 MySQL 트랜잭션에서 다시 실행 및 실행 취소에 대한 분석(그림 및 텍스트)에 대한 내용입니다. 필요한 친구가 참고할 수 있기를 바랍니다.

우리 모두는 트랜잭션에 원자성, 일관성, 격리성, 내구성이라는 4가지 특성이 있다는 것을 알고 있습니다. 트랜잭션의 모든 작업은 수행되거나 전혀 수행되지 않습니다. 트랜잭션의 격리는 잠금 메커니즘을 통해 이루어지며, 트랜잭션의 리두 로그와 언두 로그를 통해 원자성, 일관성, 내구성이 보장됩니다. 따라서 이 문서에서는 트랜잭션의 다시 실행 및 실행 취소에 대한 몇 가지 문제에 대해 설명합니다.

• 다시 실행 로그와 실행 취소 로그란 각각 무엇입니까?

• 리두는 어떻게 트랜잭션의 내구성을 보장하나요?

• Undo 로그는 Redo 로그의 역과정인가요?

redo log

Redo 유형

리두 로그(redo log)는 트랜잭션의 내구성을 보장하기 위해 사용되며 트랜잭션 ACID의 D이다. 실제로 다음 두 가지 유형으로 나눌 수 있습니다.

• Physical Redo 로그

• Logical Redo 로그

InnoDB 스토리지 엔진에서 대부분의 경우 Redo는 기록하는 물리적 로그입니다. 데이터 페이지의 물리적 변화. 논리적 리두 로그는 페이지의 실제 수정 사항을 기록하지 않지만, 페이지를 수정하는 작업 유형을 기록합니다. 예를 들어 새 데이터 페이지를 생성할 때 논리적 로그가 기록되어야 합니다. 논리적 Redo 로그의 경우 더 낮은 수준의 콘텐츠가 포함됩니다. 여기서 Redo는 대부분의 경우 페이지의 DML 수정 작업이 Redo를 기록해야 한다는 점만 기억하면 됩니다.

Redo의 역할

Redo 로그 주요 기능은 데이터베이스 충돌 복구를 위한 것입니다

Redo의 구성

Redo 로그는 간단히 다음 두 부분으로 나눌 수 있습니다.

• 첫 번째는 인메모리 리두 로그 버퍼(리두 로그 버퍼), 메모리에 휘발성

• 두 번째는 Redo 로그 파일로, 디스크에 영구 저장되며

Redo를 언제 써야 할까요?

위 그림은 단순히 Redo 쓰기를 반영한 ​​과정을 입력하고, Redo를 작성하는 시점에 대한 자세한 설명은 다음과 같습니다.

• 데이터 페이지 수정이 완료된 후 더티 페이지가 디스크에서 플러시되기 전에 Redo 로그가 기록됩니다. 데이터가 먼저 수정되고 로그는 나중에 기록됩니다

• 리두 로그는 데이터 페이지보다 먼저 디스크에 다시 기록됩니다

• 클러스터 인덱스, 보조 인덱스, 실행 취소 페이지 수정이 모두 필요합니다. Redo 로그에 기록됩니다.

Redo의 전반적인 프로세스

다음은 아래 그림과 같이 Redo 로그 흐름 프로세스를 매크로 수준에서 파악하기 위해 업데이트 트랜잭션을 예로 들어 보겠습니다.

• 1단계 : 먼저 디스크의 원본 데이터를 메모리로 읽어와 데이터의 메모리 복사본을 수정합니다

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

• 3단계: 트랜잭션이 커밋되면 리두 로그 버퍼의 내용이 리두 로그 파일로 새로 고쳐지고 리두 로그 파일이 쓰기 메서드에 추가됩니다.

• 4단계: 수정된 내용을 정기적으로 새로 고칩니다. 메모리의 데이터를 디스크로

redo 트랜잭션 내구성을 보장하는 방법은 무엇입니까?

InnoDB는 트랜잭션용 스토리지 엔진으로 Force Log at Commit 메커니즘을 통해 트랜잭션의 지속성을 달성합니다. 즉, 트랜잭션이 제출되면 지속성을 위해 먼저 리두 로그 버퍼가 리두 로그 파일에 기록됩니다. 트랜잭션의 커밋 작업이 보류 중입니다. 완료될 때까지 완료되지 않습니다. 이 접근 방식을 Write-Ahead Log(사전 로그 지속성)이라고도 합니다. 데이터 페이지를 유지하기 전에 해당 로그 페이지가 메모리에 유지됩니다.

로그가 리두 로그 파일에 기록될 때마다 리두 버퍼가 리두 로그 파일에 기록될 때마다 기본적으로 InnoDB 스토리지 엔진은 fsync 작업을 한 번 호출해야 하기 때문입니다. 리두 로그는 O_DIRECT 옵션으로 열리지 않으므로 리두 로그는 파일 시스템 캐시에 먼저 기록됩니다. Redo 로그가 디스크에 기록되도록 하려면 fsync 작업을 수행해야 합니다. fsync는 시스템 호출 작업입니다. fsync의 효율성은 디스크 성능에 따라 달라집니다. 따라서 디스크 성능은 트랜잭션 제출 성능, 즉 데이터베이스 성능에도 영향을 미칩니다.
(O_DIRECT 옵션은 Linux 시스템의 옵션입니다. 이 옵션을 사용한 후에는 파일 시스템 캐시를 거치지 않고 파일이 직접 IO 작동되고 디스크에 직접 기록됩니다.)

The Force Log at Commit 메커니즘 위에서 언급한 InnoDB 스토리지 엔진에서 제공하는 innodb_flush_log_at_trx_commit 매개변수에 의해 제어됩니다. 이 매개변수는 디스크에 대한 리두 로그 플러시 전략을 제어할 수 있습니다. 이 매개변수 값을 설정하면 사용자가 비지속성을 설정할 수도 있습니다. innodb_flush_log_at_trx_commit来控制的，该参数可以控制 redo log刷新到磁盘的策略，设置该参数值也可以允许用户设置非持久性的情况发生，具体如下：

• 当设置参数为1时，（默认为1），表示事务提交时必须调用一次 fsync

  🎜🎜매개변수를 1로 설정하면(기본값은 1) 트랜잭션이 커밋될 때 fsync 작업을 한 번 호출해야 한다는 의미이며, 이것이 가장 안전한 구성입니다. 내구성을 보장합니다🎜

• 매개변수를 2로 설정하면 트랜잭션이 제출될 때 write 작업만 수행되며 리두 로그 버퍼가 시스템의 페이지 캐시에 기록되는 것만 확인하고 fsync 작업은 수행되지 않습니다. MySQL 데이터베이스가 다운되면 트랜잭션이 손실되지 않지만 운영 체제가 다운되면 트랜잭션이 손실될 수 있습니다

• 파라미터가 0으로 설정되면 리두 로그 작업이 기록되지 않는다는 의미입니다. 이 작업은 마스터 스레드에서만 완료되며, 마스터 스레드에서 매번 redo 로그의 fsync 작업이 1초에 한 번 수행되므로 인스턴스 크래시가 발생하면 최대 1초 이내에 트랜잭션이 손실됩니다. (마스터 스레드는 데이터 일관성을 보장하기 위해 버퍼 풀의 데이터를 디스크에 비동기식으로 새로 고치는 역할을 담당합니다.) 작업은 데이터를 시스템의 페이지 캐시에 쓰고 즉시 반환한 다음 시스템의 스케줄링 메커니즘을 사용하여 캐시된 데이터를 새로 고칩니다. . 디스크의 경우 사용자 버퍼 -> 페이지 캐시 -> 디스크 순서입니다.

fsync和write操作实际上是系统调用函数，在很多持久化场景都有使用到，比如 Redis 的AOF持久化中也使用到两个函数。fsync操作 将数据提交到硬盘中，强制硬盘同步，将一直阻塞到写入硬盘完成后返回，大量进行fsync操作就有性能瓶颈，而write

트랜잭션의 내구성을 보장하기 위해 위에서 언급한 Force Log at Commit 메커니즘 외에도 리두 로그의 실제 구현도 미니 트랜잭션에 따라 달라집니다.

InnoDB에서 Redo는 어떻게 구현되나요? 미니 거래에 연결되나요?

Redo의 구현은 실제로 미니 트랜잭션과 밀접한 관련이 있습니다. 미니 트랜잭션은 InnoDB에서 내부적으로 사용하는 메커니즘으로 동시 트랜잭션 작업 시 및 데이터베이스가 작동할 때 데이터 페이지의 데이터 일관성을 보장하는 데 사용됩니다. 그러나 이는 거래의 일부가 아닙니다.

미니 트랜잭션이 데이터 페이지 데이터의 일관성을 보장하려면 미니 트랜잭션은 다음 세 가지 프로토콜을 따라야 합니다

:

The FIX Rules

Write-Ahead Log

• Force- log-at-commit
FIX 규칙

• 데이터 페이지를 수정할 때 해당 페이지의 x-latch(독점 잠금)를 획득해야 합니다. 데이터 페이지를 획득할 때 s-latch가 필요합니다. (페이지의 읽기 잠금) 또는 x-래치는 페이지 수정 또는 액세스 작업이 완료될 때까지 페이지에 대한 잠금을 유지합니다.

Write-Ahead Log

Write-Ahead Log는 이전 설명에서 언급한 바 있습니다. 데이터 페이지를 유지하기 전에 먼저 메모리의 해당 로그 페이지를 유지해야 합니다. 각 페이지에는 로그 시퀀스 번호를 나타내는 LSN(로그 시퀀스 번호)이 있습니다(LSN은 8바이트를 차지하고 단조롭게 증가함). 데이터 페이지를 영구 장치에 기록해야 하는 경우 페이지의 LSN보다 적게 필요합니다. 로그는 영속성 장치에 먼저 기록됩니다

그렇다면 왜 로그를 먼저 작성해야 할까요? 로그를 작성하지 않고 디스크에 직접 데이터를 쓸 수 있습니까? 원칙적으로는 가능하지만 약간의 문제가 발생할 수 있습니다. 데이터 수정 시 랜덤 IO가 발생하지만 로그는 순차 IO이므로 디스크의 성능을 최대한 발휘할 수 있는 직렬 방식입니다. 활용.

Force-log-at-commit

위에서 언급한 트랜잭션의 내구성을 보장하는 방법에 대한 내용입니다. 위 내용을 다시 요약하면 다음과 같습니다. 트랜잭션에서 여러 페이지를 수정할 수 있습니다. Write-Ahead Log는 단일 데이터 페이지의 일관성을 보장할 수 있지만 트랜잭션의 내구성을 보장할 수는 없습니다. mini - 트랜잭션 로그를 디스크로 플러시해야 합니다. 로그 플러시가 완료된 후 버퍼 풀의 페이지가 영구 저장 장치로 플러시되기 전에 데이터베이스가 충돌하면 데이터베이스가 다시 시작될 때 데이터 무결성이 손상될 수 있습니다. 로그를 통해 확인하세요.

Redo 로그 작성 프로세스

위 그림은 각 미니 트랜잭션이 업데이트 문과 같은 각 DML 작업에 해당하며 이를 보장하기 위한 미니 트랜잭션으로 구성됩니다. 데이터가 수정된 후 redo1이 생성되고, 이는 먼저 미니 트랜잭션 프라이빗 버퍼에 기록됩니다. 업데이트 문이 끝난 후 redo1은 프라이빗 버퍼에서 퍼블릭 로그 버퍼로 복사됩니다. 전체 외부 트랜잭션이 커밋되면 리두 로그 버퍼가 리두 로그 파일로 플러시됩니다.

undo 로그

undo 로그 정의

undo 로그는 주로 데이터의 논리적 변경 사항을 기록합니다. 오류 발생 시 이전 작업을 롤백하려면 모든 이전 작업을 기록해야 하며, 이후에는 오류 발생 오류가 발생한 경우에만 롤백할 수 있습니다.

실행 취소 로그의 역할

실행 취소는 두 가지 기능을 가진 논리적 로그입니다:

트랜잭션 롤백용

MVCC

여기서는 MVCC(다중 버전 동시성 제어)에 대해 많이 언급하지 않겠습니다. 이 글에서는 트랜잭션 롤백을 위한 실행 취소 로그에 중점을 둡니다.

undo 로그는 데이터베이스를 원래 상태로 논리적으로 복원합니다. 예를 들어 INSERT는 DELETE에 해당하고, 각 UPDATE에 대해 반대 UPDATE를 다시 수행합니다. 수정 전 줄. 실행 취소 로그는 트랜잭션의 원자성을 보장하기 위해 트랜잭션 롤백 작업에 사용됩니다.

Undo 로그 작성 시점

• DML 작업이 클러스터형 인덱스를 수정하기 전에 Undo 로그가 기록됩니다.

• 2차 인덱스 레코드의 수정 사항은 Undo 로그에 기록되지 않습니다

페이지에 대한 실행 취소 수정 사항도 다시 실행 로그에 기록되어야 한다는 점에 유의해야 합니다.

Undo 저장 위치

InnoDB 스토리지 엔진에서 Undo는 롤백 세그먼트(Rollback 세그먼트), 각 롤백 세그먼트는 1024개의 실행 취소 로그 세그먼트를 기록하며, 실행 취소는 각 실행 취소 로그 세그먼트에서 수행됩니다. 페이지를 신청하려면 5.6 이전에는 공유 테이블스페이스에 Rollback Segment를 두었습니다. 5.6.3 이후에는 사용할 수 있습니다. innodb_undo_tablespace는 실행 취소 저장소의 위치를 ​​설정합니다.

Undo 유형

InnoDB 스토리지 엔진에서 undo 로그는 다음과 같이 구분됩니다.

• insert undo log

• update undo log

insert undo log는 insert에서 생성된 undo를 의미합니다. 작업 로그. 삽입 작업의 기록은 트랜잭션 자체에만 표시되고 다른 트랜잭션에는 표시되지 않기 때문입니다. 따라서 트랜잭션이 제출된 후 실행 취소 로그를 직접 삭제할 수 있으며 제거 작업이 필요하지 않습니다.

업데이트 실행 취소 로그는 삭제 및 업데이트 작업으로 생성된 실행 취소 로그를 기록합니다. 실행 취소 로그는 MVCC 메커니즘을 제공해야 할 수 있으므로 트랜잭션이 커밋될 때 삭제할 수 없습니다. 제출할 때 실행 취소 로그 목록에 넣고 퍼지 스레드가 최종 삭제를 수행할 때까지 기다립니다.

보충 사항: 제거 스레드의 두 가지 주요 기능은 실행 취소 페이지를 정리하고 페이지에서 Delete_Bit 플래그를 사용하여 데이터 행을 지우는 것입니다. InnoDB에서 트랜잭션의 삭제 작업은 실제로 데이터 행을 삭제하는 것이 아니라 레코드를 삭제하지 않고 레코드에 Delete_Bit를 표시하는 삭제 표시 작업입니다. 일종의 '가짜 삭제'로 표시만 한 것인데 실제 삭제 작업은 백그라운드 퍼지 스레드에서 완료해야 한다.

Undo 로그는 Redo 로그의 역과정인가요?

undo 다시 실행 여부를 기록합니다. 로그의 역과정? 실제로 그 답은 이전 기사에서 도출할 수 있습니다. Undo 로그는 트랜잭션을 롤백할 때 데이터베이스를 논리적으로만 원래 상태로 복원하는 반면, Redo 로그는 논리적 로그입니다. 로그는 데이터 페이지의 물리적 변경 사항을 기록하는 물리적 로그입니다. 분명히 undo 로그는 redo 로그의 역 프로세스가 아닙니다.

redo & undo 요약

다음은 두 가지 로그 프로세스에 대한 이해를 돕기 위해 redo 로그 + undo 로그의 단순화된 프로세스입니다.

假设有A、B两个数据，值分别为1,2.
1. 事务开始
2. 记录A=1到undo log
3. 修改A=3
4. 记录A=3到 redo log
5. 记录B=2到 undo log
6. 修改B=4
7. 记录B=4到redo log
8. 将redo log写入磁盘
9. 事务提交

실제로 삽입/업데이트/삭제 작업에서 redo와 undo는 따로 기록하는 내용도 다르고 수량도 다릅니다. InnoDB 메모리의 일반적인 순서는 다음과 같습니다.

• Write undo redo

• Write undo

• Modify the data page

• Write Redo

요약

이 기사는 다음을 분석합니다. 업무 redo 및 undo 로그인은 일부 정보 서적을 참조하여 정리되었으며, 일부 장소는 명확하게 명시되지 않을 수 있습니다. 잘못된 점이 있으면 지적해 주시기 바랍니다.

위 내용은 MySQL 트랜잭션의 다시 실행 및 실행 취소 분석(그림 및 텍스트)의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!