MySQL 교차 행 트랜잭션 모델(자세한 그래픽 설명)

MySQL 트랜잭션 모델에 대한 소개는 인터넷에 많이 있습니다. 이 글을 쓰기 전에 저도 참고용으로 많은 정보를 읽어서 좀 더 깊이 있고 포괄적으로 이해할 수 있기를 바랍니다. 대부분의 소개 기사를 읽은 후 일부는 불완전하다는 사실을 발견했습니다. 예를 들어 일부는 여러 격리 수준에서 MySQL의 성능을 소개하고 기술적 관점에서 설명하지 않습니다. 일부 기사는 매우 포괄적이지만 구성이 부족하고 이해하기 쉽지 않습니다. 이것이 저자가 여러분에게 뭔가 색다른 것을 가져다 주고, 기술적인 관점에서 설명하고, 이해를 돕기를 바라는 것입니다.

MySQL 트랜잭션 원자성 보장

트랜잭션 원자성은 트랜잭션의 일련의 작업을 완전히 완료하거나 작업을 수행해서는 안 되며 절반만 수행할 수 없도록 요구합니다. HBase에서 행 수준 트랜잭션의 원자성 구현이 상대적으로 간단한 것처럼 원자성은 원자성 작업에 대해 구현하기 쉽습니다. 하지만 여러 문으로 구성된 트랜잭션의 경우 트랜잭션 실행 중 예외가 발생하면 원자성을 보장해야 하는 경우 트랜잭션이 한 번도 발생하지 않았던 것처럼 트랜잭션이 시작되기 전 상태로 롤백하는 방법밖에 없습니다. 모두. 이것을 달성하는 방법은 무엇입니까?

MySQL의 롤백 작업 구현은 전적으로 실행 취소 로그에 의존합니다. 한 가지 더, 실행 취소 로그는 MySQL에서 원자성 보장을 달성하는 것 외에도 MVCC를 구현하는 데 사용됩니다. 이에 대해서도 아래에서 설명합니다. 실행 취소를 사용하면 데이터를 조작하기 전에 수정 전의 데이터가 먼저 실행 취소 로그에 기록되고 실제 수정이 이루어집니다. 예외가 발생하고 롤백이 필요한 경우 시스템은 실행 취소의 백업을 사용하여 트랜잭션이 시작되기 전의 상태로 데이터를 복원할 수 있습니다. 다음 그림은 MySQL에서 트랜잭션을 나타내는 기본 데이터 구조입니다. 실행 취소와 관련된 필드는 각각 이 트랜잭션에 의해 생성된 실행 취소 로그를 가리키는 insert_undo 및 update_undo입니다.

트랜잭션 롤백은 update_undo(또는 insert_undo)를 기반으로 해당 undo 로그를 찾아 역방향 작업을 수행합니다. 삭제 표시된 데이터의 경우 표시를 정리 및 삭제하고 업데이트된 데이터에 대한 업데이트를 직접 롤백합니다. 삽입 작업은 데이터를 삭제해야 할 뿐만 아니라 관련 항목도 삭제해야 하기 때문에 약간 더 복잡합니다. 클러스터형 인덱스 및 보조 인덱스 레코드.

실행 취소 로그는 MySQL 커널에서 매우 중요한 콘텐츠이며 다음과 같이 복잡합니다.

1 실행 취소 로그는 데이터가 수정되기 전에 유지되어야 합니다. 비정상적인 다운타임을 방지하기 위해 로그에 다시 실행을 기록할 필요가 없나요? 필요한 경우 다운타임 복구도 포함됩니다...

2. 실행 취소 로그를 통해 MVCC를 구현하는 방법은 무엇입니까?

3. 어떤 경우에 실행 취소 로그를 재활용하고 정리할 수 있나요? 그것을 청소하는 방법?

MySQL 트랜잭션 일관성 보장: 강력한 일관성 트랜잭션 보장

MySQL 트랜잭션 격리 수준

---

Read Uncommitted(RU 기술 해석: X 잠금을 사용하여 쓰기-쓰기 동시성을 달성함)

Read Uncommitted는 쓰기-쓰기만 구현합니다. 동시성 제어에는 효과적인 읽기 및 쓰기 동시성 제어가 없으므로 현재 트랜잭션이 다른 트랜잭션에서 커밋되지 않은 수정된 데이터를 읽을 수 있으므로 이러한 데이터의 정확성은 신뢰할 수 없으므로(롤백될 수 있음) 이를 기반으로 한 모든 가정은 신뢰할 수 없습니다. . 실제 시나리오에서는 이 격리 수준을 선택하는 기업이 거의 없습니다.

쓰기-쓰기 동시성 구현 메커니즘은 HBase와 다르지 않습니다. 둘 다 2단계 잠금 프로토콜을 사용하여 구현되어 해당 레코드에 행 잠금을 추가합니다. 그러나 MySQL의 행 잠금 메커니즘은 행 레코드가 기본 키 인덱스인지, 고유 인덱스인지, 고유하지 않은 인덱스인지, 인덱스가 없는지에 따라 다양한 잠금 상황이 있습니다.

1. id 열이 기본 키 인덱스인 경우 MySQL은 클러스터형 인덱스 레코드만 잠급니다.

2. id 열이 유일한 보조 인덱스인 경우 MySQL은 보조 인덱스 리프 노드와 클러스터형 인덱스 레코드를 잠급니다.

3. id 열이 고유하지 않은 인덱스인 경우 MySQL은 조건(id = 15)을 충족하는 모든 보조 인덱스 리프 노드와 해당 클러스터형 인덱스 레코드를 잠급니다.

4. id 열이 인덱싱되지 않은 경우 SQL은 클러스터형 인덱스 전체 테이블 검색을 수행하고 필터링을 위해 검색 결과를 SQL Server 계층에 로드합니다. 따라서 SQL Server 계층 필터링이 수행되지 않으면 InnoDB는 먼저 검색된 모든 레코드를 잠급니다. 조건을 충족하면 InnoDB가 잠금을 해제합니다. 따라서 InnoDB는 스캔된 모든 레코드를 잠급니다.

다음으로 RC, RR 또는 직렬화 여부에 관계없이 쓰기 동시성 제어는 위의 메커니즘을 사용하므로 자세히 설명하지 않겠습니다. 다음으로 RC 및 RR 격리 수준에서 읽기 및 쓰기 동시성 제어 메커니즘을 분석하는 데 중점을 둘 것입니다.

RC와 RR을 자세히 소개하기 전에 먼저 MySQL에 MVCC 메커니즘을 도입해야 합니다. 왜냐하면 RC와 RR 모두 MVCC 메커니즘을 사용하여 트랜잭션 간 읽기 및 쓰기 동시성을 달성하기 때문입니다. 구현 세부 사항에 있어서 둘 사이에는 약간의 차이점이 있을 뿐입니다. 구체적인 차이점은 다음에 설명하겠습니다.

MySQL의 MVCC

MySQL의 MVCC 메커니즘은 HBase보다 훨씬 복잡하고 관련된 데이터 구조도 더 복잡합니다. 좀 더 명확하게 설명하기 위해 밤나무를 설명용 템플릿으로 사용했습니다. 예를 들어 현재 아래와 같은 레코드 행이 있습니다.

처음 4개 열은 행에 기록된 실제 열 값입니다. 여기서 주목해야 할 것은 숨겨진 두 열인 DB_TRX_ID와 DB_ROLL_PTR(사용자에게 보이지 않음)입니다. 이 중 DB_TRX_ID는 행을 수정하는 트랜잭션의 트랜잭션 ID를 나타내고, DB_ROLL_PTR은 행의 롤백 세그먼트에 대한 포인터를 나타냅니다. 이 값은 이 행에 기록된 모든 버전 데이터를 연결 목록 형태로 구성합니다. 실제로는 실행 취소된 행의 기록을 가리킵니다.

이제 데이터 행을 수정하는 트랜잭션 trx2가 있다고 가정합니다. 행 레코드는 다음 그림으로 변경됩니다. DB_TRX_ID는 최근 행을 수정한 트랜잭션의 ID(trx2)입니다. 레코드 연결 목록:

MySQL 행 레코드를 이해한 후 트랜잭션의 기본 구조를 살펴보겠습니다. 다음 그림은 위에서 언급한 MySQL의 트랜잭션 데이터 구조를 보여줍니다. 트랜잭션이 시작된 후에는 트랜잭션 관련 정보, 잠금 정보, Undo 로그 및 매우 중요한 read_view 정보를 저장하는 데이터 구조가 생성됩니다.

read_view는 아래 그림과 같이 현재 트랜잭션이 시작될 때 전체 MySQL의 모든 활성 트랜잭션 목록을 저장합니다. 현재 트랜잭션이 시작되면 시스템의 활성 트랜잭션에는 trx4, trx6, trx7 및 trx10이 포함됩니다. 또한, up_trx_id는 현재 트랜잭션이 시작될 때 현재 트랜잭션 목록에서 가장 작은 트랜잭션 ID를 나타내고, low_trx_id는 현재 트랜잭션이 시작될 때 현재 트랜잭션 목록에서 가장 큰 트랜잭션 ID를 나타냅니다.

read_view는 MVCC 구현의 핵심 포인트이며 현재 트랜잭션에 표시되는 레코드 버전을 결정하는 데 사용됩니다. 현재 트랜잭션이 특정 레코드 행을 읽으려고 하고 행 레코드의 버전 번호(트랜잭션 ID)가 trxid인 경우:

1 trxid

2. trxid > low_trx_id이면 현재 트랜잭션이 생성된 후에 해당 행이 위치한 트랜잭션이 열렸으므로 해당 행 레코드가 현재 트랜잭션에 표시되지 않음을 의미합니다.

3. up_trx_id

다음 행 레코드를 예로 들어 보겠습니다. 이 행 레코드에는 여러 버전(trx2, trx5, trx7 및 trx12)이 있으며 그중 trx12가 최신 버전입니다. 현재 트랜잭션에 표시되는 행의 버전을 확인하세요.

1. 이 행에 기록된 최신 버전은 trx12입니다. 현재 트랜잭션 read_view와 비교하면 trx12가 현재 활성 트랜잭션 목록에서 가장 큰 트랜잭션 trx10보다 큰 것으로 확인됩니다. 이는 trx12가 현재 트랜잭션 이후에 열렸음을 의미합니다. 트랜잭션이 생성되었으므로 표시되지 않습니다.

2. 행 레코드의 두 번째 최신 버전이 trx7인지 확인합니다. 현재 트랜잭션 read_view와 비교하면 trx7이 현재 활성 트랜잭션 목록의 최소 트랜잭션 ID와 최대 트랜잭션 ID 사이에 있는 것으로 확인됩니다. 행 레코드가 있는 위치는 현재입니다. 트랜잭션이 생성될 때 활성 상태였습니다. 활성 목록을 탐색하면 trx7이 존재하는 것으로 나타났습니다. 이는 트랜잭션이 아직 제출되지 않았으므로 현재 트랜잭션에 표시되지 않음을 나타냅니다.

3. 현재 활성 트랜잭션 목록의 최소 트랜잭션 ID와 최대 트랜잭션 ID 사이에 있는 세 번째 최신 버전의 레코드인 trx5를 계속 봅니다. 이는 행 레코드가 위치한 트랜잭션이 활성이었음을 나타냅니다. 현재 트랜잭션이 생성되었을 때 순회 중에 이 버전이 활성 트랜잭션 목록에 없는 것으로 발견되어 trx5에 해당하는 트랜잭션이 제출되었음을 나타냅니다. (참고: 트랜잭션 제출 시간과 트랜잭션 번호 사이에는 상관 관계가 없습니다. 더 큰 트랜잭션 번호가 있는 트랜잭션이 먼저 제출되고 더 작은 트랜잭션 번호가 있는 트랜잭션이 나중에 제출될 수 있습니다. 따라서 trx5 버전 행 레코드는 현재 트랜잭션에 표시되며 직접 반환됩니다. Committed Sex를 읽으려면 핵심 사항도 알아야 합니다. RC 격리 수준 아래의 트랜잭션은 선택이 실행될 때마다 원래 read_view를 대체하기 위해 최신 read_view를 생성합니다.

---

위 그림과 같이 왼쪽이 거래번호 1번이고, id=1인 기록이 서로 다른 시점에 3번 조회되었습니다. 오른쪽에는 id=1로 레코드를 업데이트하는 트랜잭션 번호 2가 있습니다. 업데이트 전에는 한 가지 버전의 음반만 있었는데, 업데이트 후에는 두 가지 버전이 되었습니다.

트랜잭션 1번은 RC 격리 수준에서 선택 요청을 실행할 때마다 최신 read_view를 생성합니다. 처음 두 쿼리에 의해 생성된 전역 트랜잭션 활성 목록에는 trx2가 포함되어 있으므로 MVCC 규정에 따라 발견된 레코드는 이전 버전입니다. ; 마지막으로 쿼리 시점은 2번 트랜잭션이 제출된 이후이므로 생성된 글로벌 활성 트랜잭션 목록에는 trx2가 포함되지 않습니다. 이때 MVCC 규정에 따라 발견된 레코드는 최신 버전의 레코드입니다.

반복 읽기(기술적 해석: X 잠금은 동시 쓰기 및 쓰기에 사용되며, MVCC는 동시 읽기 및 쓰기에 사용되어 반복 불가능한 읽기를 방지합니다. Gap 잠금은 현재 읽기에 사용되어 팬텀 읽기를 방지합니다.)

RC 모드와 달리, RR 모드의 트랜잭션은 매번 실행되지 않습니다. 선택 시 최신 read_view가 생성되지만, 트랜잭션이 처음 선택될 때 read_view가 생성되며 현재 트랜잭션이 끝날 때까지 다시 변경되지 않습니다. 이렇게 하면 반복 불가능한 읽기를 효과적으로 방지하고 전체 트랜잭션 동안 현재 트랜잭션에서 읽은 데이터를 일관되게 만들 수 있습니다. 개략적인 다이어그램은 다음과 같습니다.

세 쿼리에 사용된 전역 활성 트랜잭션 목록은 모두 동일하며 처음으로 생성된 read_view입니다. 첫 번째 쿼리와 동일해야 합니다. 도착한 레코드는 일관됩니다.

RR 격리 수준으로 팬텀 읽기를 방지할 수 있나요?

팬텀리딩에 대해 모르신다면 이 시리즈의 첫 번째 글을 참고하시면 됩니다. 아래 그림과 같이 1번 트랜잭션은 id>1에 대한 필터 조건에 대해 3개의 질의를 수행하였고, 2번 트랜잭션은 삽입된 레코드가 id>1의 조건을 만족하였을 때 삽입을 수행하였다. 세 가지 쿼리를 통해 얻은 데이터는 일관성이 있으며 이는 RR 격리 수준의 MVCC 메커니즘에 의해 보장됩니다. 이러한 관점에서 볼 때, 팬텀 읽기는 방지됩니다. 그러나 마지막 트랜잭션 1번이 id=2에 레코드를 삽입하면 MySQL은 중복 항목 오류를 반환합니다. 팬텀 읽기를 피하는 것은 환상임을 알 수 있습니다.

팬텀 읽기를 엄격히 피하세요(기술적 해석: 현재 읽기는 팬텀 읽기를 피하기 위해 Gap 잠금을 사용합니다)

앞서 언급한 모든 RR 수준의 선택 문을 스냅샷 읽기라고 부르지만 반복 불가능한 읽기를 보장할 수 있습니다. 팬텀 독서는 피할 수 없습니다. 그래서 MySQL은 "현재 읽기"라는 개념을 제안했습니다. 일반적인 현재 읽기 문은 다음과 같습니다:

1 RR 수준의 현재 읽기 문은 레코드에 특수 잠금을 추가한다고 규정되어 있습니다. 간격 잠금이 수행됩니다. 특정 레코드를 잠그지는 않지만 새로운 추가 레코드가 삽입되지 않도록 레코드 사이의 간격을 잠급니다. 다음 그림은 도식적 다이어그램입니다.

위 그림에서 트랜잭션 번호 1은 먼저 현재 읽은 select 문을 실행합니다. 이 문은 id > 0인 모든 간격에 Gap 잠금을 추가합니다. 다음으로 트랜잭션 번호 2입니다. id = 3인 모든 간격에 Gap 잠금을 추가합니다. 시스템은 잠금 대기 시간 초과 실행 예외를 반환합니다. 물론, 다른 트랜잭션은 id

직렬화 가능(기술적 해석: S 잠금(읽기) + 쓰기 잠금 추가. 물론 이 격리 수준의 성능은 잠금 오버헤드로 인해 상대적으로 열악합니다.

MySQL 트랜잭션 지속성 보장

MySQL 트랜잭션 지속성 전략은 기본적으로 HBase와 동일하지만 주로 doublewrite, redo log 및 binlog와 같은 비교적 많은 구성 요소를 포함합니다.

1 MySQL 데이터 지속성(DoubleWrite)

실제로 MySQL의 실제 데이터 쓰기는 두 번의 쓰기로 나누어져 있는데, 하나는 DoubleWrite라는 곳에 쓰고, 쓰기가 성공한 후에는 데이터가 위치한 디스크에 실제 데이터가 쓰여진다. 왜 두 번 쓰나요? 이는 MySQL 데이터 페이지 크기가 디스크의 원자성 작업 크기와 일치하지 않아 부분 쓰기가 발생할 수 있기 때문입니다. 예를 들어 기본 InnoDB 데이터 페이지 크기는 16K이고 디스크의 원자성 쓰기 크기는 512바이트(섹터 크기), 이러한 데이터 페이지를 작성하려면 여러 번의 IO가 필요하므로 중간에 예외가 발생하면 데이터 손실이 발생합니다. 또한 DoubleWrite에 쓰는 작업은 순차 쓰기이므로 성능에 큰 영향을 미치지 않으므로 DoubleWrite 성능에는 큰 영향을 미치지 않는다는 점에 유의해야 합니다.

2. redolog 지속성 전략(innodb_flush_log_at_trx_commit)

redolog는 InnoDB의 WAL입니다. 데이터는 먼저 redolog에 기록되고 디스크에 삭제된 다음 버퍼 풀에 기록되고 업데이트됩니다. redolog의 지속성 전략은 HBase의 hlog 지속성 전략과 일치합니다. 기본값은 1입니다. 이는 각 트랜잭션이 제출된 후 로그가 디스크에 지속된다는 것을 의미합니다. 값이 0이면 비동기 스레드가 이를 지속한다는 의미입니다. 1초마다 디스크에 저장됩니다. 이 경우 MySQL이 다운되고 일부 데이터가 손실될 수 있습니다. 이 값은 2입니다. 이는 각 트랜잭션이 제출된 후 로그가 운영 체제 버퍼로 플러시되고 운영 체제가 이를 디스크로 비동기적으로 플러시한다는 것을 의미합니다. 이 경우 MySQL은 데이터가 손실되지 않습니다. 하지만 기기가 다운되면 일부 데이터가 손실될 수 있습니다.

3. Binlog 지속성 전략(sync_binlog)

Binlog는 서버 계층의 로그 시스템으로 주로 데이터베이스의 다양한 작업을 이벤트 형식으로 순차적으로 기록하며, 각 작업에 소요된 시간도 기록할 수 있습니다. MySQL 공식 문서에서는 주로 Binlog의 가장 기본적인 두 가지 핵심 기능인 백업과 복제를 소개합니다. 따라서 Binlog의 지속성은 데이터 백업 및 복제의 무결성에 어느 정도 영향을 미칩니다. Redo Persistence 전략과 마찬가지로 가능한 값은 0, 1, N이다. 기본값은 0입니다. 이는 운영 체제 버퍼에 쓰고 비동기적으로 디스크에 플러시하는 것을 의미합니다. 값 1은 디스크에 대한 동기 쓰기를 나타냅니다. N이면 운영체제 버퍼를 N번 쓸 때마다 리프레시 동작을 수행한다는 뜻이다.

요약하자면, 이 기사는 데이터베이스 트랜잭션 기사 시리즈 중 세 번째입니다. MySQL의 단일 머신 교차 행 트랜잭션 모델의 핵심을 소개하고 격리와 관련된 잠금 기술 및 MVCC 메커니즘에 대해 더 자세히 설명합니다. 트랜잭션 원자성, 내구성 등 관련 기능도 간략하게 분석하고 설명합니다. 다음으로 저자는 분산 트랜잭션 모델에 대해 이야기하고 독립형 트랜잭션 모델과 어떻게 다른지 살펴보겠습니다.

추천 학습: MySQL 튜토리얼

위 내용은 MySQL 교차 행 트랜잭션 모델(자세한 그래픽 설명)의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!