MySQL 트랜잭션 로그를 함께 분석해보자

이 기사는 mysql 트랜잭션과 관련된 문제를 주로 소개하는 mysql에 대한 관련 지식을 제공합니다. 트랜잭션은 MySQL을 NoSQL과 구별하는 중요한 기능이며 관계형 데이터베이스의 데이터 일관성을 보장하는 핵심 기술입니다.

추천 학습: mysql 학습 동영상 튜토리얼

1. MySQL 트랜잭션

트랜잭션은 MySQL과 NoSQL을 구별하는 중요한 기능이며 관계형 데이터베이스에서 데이터 일관성을 보장하는 핵심 기술입니다. 트랜잭션은 하나 이상의 SQL 문을 포함할 수 있는 데이터베이스 작업의 기본 실행 단위로 간주될 수 있습니다. 이러한 명령문이 실행되면 모두 실행되거나 아무것도 실행되지 않습니다.

트랜잭션 실행에는 주로 커밋과 롤백이라는 두 가지 작업이 포함됩니다.

제출: 커밋, 트랜잭션 실행 결과를 데이터베이스에 씁니다.

롤백: 실행된 모든 문을 롤백하고 롤백하고 수정 전의 데이터를 반환합니다.

MySQL 트랜잭션에는 4가지 ACID 왕으로 알려진 4가지 특성이 포함됩니다.

원자성: 명령문은 완전히 실행되거나 전혀 실행되지 않습니다. 이는 트랜잭션 자체가 원자성에 의해 정의됩니다. 구현은 주로 실행 취소 로그를 기반으로 합니다.

내구성: 트랜잭션 제출 후 다운타임 및 기타 이유로 인해 데이터가 손실되지 않도록 보장합니다. 구현은 주로 리두 로그를 기반으로 합니다.

격리성: 트랜잭션 실행이 가능한 한 다른 트랜잭션의 영향을 받지 않도록 합니다. 기본 격리 수준은 RR입니다. RR의 구현은 주로 잠금 메커니즘, 데이터의 숨겨진 열, 실행 취소 로그 및 다음 키 잠금 메커니즘을 기반으로 합니다.

일관성: 일관성을 실현하려면 두 가지가 모두 필요합니다. 데이터베이스 및 데이터베이스의 보장에는 애플리케이션 수준의 보장도 필요합니다.

Atomicity

트랜잭션의 원자성은 트랜잭션이 더 이상 분할될 수 없음을 의미합니다. 트랜잭션이 수행되지 않거나 수행되지 않은 경우 SQL 문이 실행되지 않으면 실행된 문도 롤백되어야 하며 데이터베이스는 트랜잭션 이전 상태로 반환됩니다. 0과 1만 있습니다. 트랜잭션의 원자성은 트랜잭션이 전체임을 나타냅니다. 트랜잭션이 실행되는 동안 트랜잭션에서 실행된 모든 문을 롤백해야 데이터베이스가 트랜잭션이 발생한 상태로 돌아갑니다.

트랜잭션을 롤백해야 할 때 트랜잭션의 원자성은 실행 취소 로그를 통해 달성됩니다. InnoDB 엔진은 실행 취소 로그를 호출하여 SQL 문을 실행 취소하고 데이터 롤백을 구현합니다.

트랜잭션의 지속성은 트랜잭션이 제출된 후 데이터베이스 변경 사항이 일시적이지 않아야 함을 의미합니다. 즉, 트랜잭션이 커밋된 후에는 다른 작업이나 시스템 오류도 실행 결과에 영향을 미치지 않습니다.

트랜잭션의 지속성은 InnoDB 스토리지 엔진을 통해 이루어집니다. Redo 로그는 구현됩니다. 구체적인 구현 아이디어는 아래를 참조하세요.

원자성과 내구성은 단일 트랜잭션 자체의 속성입니다. 트랜잭션 간에 유지되어야 하는 격리 요구 사항을 의미합니다. 서로 다른 트랜잭션의 효과는 서로 간섭하지 않으며 한 트랜잭션의 작업은 다른 트랜잭션과 격리됩니다.

트랜잭션에는 하나의 SQL 문만 포함될 수 없기 때문에 트랜잭션 실행 중에 다른 트랜잭션이 시작될 가능성이 매우 높습니다. 따라서 여러 트랜잭션의 동시성을 위해서는 트랜잭션 간의 작업이 서로 격리되어야 합니다. 이는 다중 스레드 간의 데이터 동기화 개념과 다소 유사합니다. 트랜잭션 간의 격리는

잠금 메커니즘을 통해 구현됩니다. 트랜잭션이 데이터베이스의 특정 데이터 행을 수정해야 하는 경우 다른 트랜잭션이 먼저 실행되지 않습니다. 잠긴 데이터에 대한 작업을 수행하며 현재 트랜잭션이 커밋되거나 롤백될 때까지만 기다릴 수 있습니다. 잠금 메커니즘은 많은 시나리오에서 데이터를 보호하고 동기화하는 데 사용되는 개념입니다. . MySQL에서는 다양한 분할 기준에 따라 잠금을 여러 범주로 나눌 수도 있습니다.

세분성에 따라 구분: 행 잠금, 테이블 잠금, 페이지 잠금

사용에 따라 구분: 공유 잠금, 배타적 잠금

아이디어에 따라 나누기: 비관적 잠금, 낙관적 잠금

잠금 메커니즘에 대한 지식 많은 점이 있지만 지면이 부족하여 모두 논의하겠습니다. 다음은 세분성(granularity)에 따라 분류된 잠금에 대한 간략한 소개입니다.

세분성: 데이터 웨어하우스의 데이터 단위에 저장된 데이터의 세분화 또는 포괄성 수준을 나타냅니다. 세분화 정도가 높을수록 세분성 수준은 작아지고, 세분화 정도가 낮을수록 세분성 수준은 커집니다.

MySQL은 잠금 단위에 따라 행 잠금, 테이블 잠금, 페이지 잠금으로 나눌 수 있습니다.

Row 잠금: 가장 작은 단위의 잠금. 이는 현재 작업의 행만 잠긴다는 의미입니다.

테이블 잠금: 가장 큰 단위의 잠금. 이는 현재 작업이 전체 테이블을 잠그는 것을 의미합니다.

페이지 잠금: 행 수준 잠금과 테이블 수준 잠금 사이에 세분화된 잠금으로, 페이지 잠금을 의미합니다.

세분화된 데이터베이스 분할

이 세 가지 유형의 잠금은 서로 다른 수준에서 데이터를 잠급니다. 서로 다른 장점과 단점이 있습니다.

테이블 잠금은 데이터 연산 시 테이블 전체를 잠그므로 동시성 성능이 좋지 않습니다.

행 잠금은 연산이 필요한 데이터만 잠그므로 동시성 성능이 좋습니다. 그러나 잠금 자체는 리소스를 소모하므로(잠금 획득, 잠금 확인, 잠금 해제 등 모두 리소스 소모) 테이블 잠금을 사용하면 잠긴 데이터가 많을 때 많은 리소스를 절약할 수 있다.

MySQL의 다양한 스토리지 엔진은 다양한 잠금을 지원합니다. MyIsam은 테이블 잠금만 지원하는 반면, InnoDB는 성능상의 이유로 대부분의 경우 행 잠금을 사용합니다.

동시 읽기 및 쓰기 문제

동시 상황에서 MySQL을 동시에 읽고 쓰면 더티 읽기(dirty reads), 반복 불가능성 및 팬텀 읽기(phantom reads)라는 세 가지 유형의 문제가 발생할 수 있습니다.

(1) 더티 읽기: 현재 트랜잭션이 다른 트랜잭션에서 커밋되지 않은 데이터, 즉 더티 데이터를 읽습니다.

위 그림을 예로 들면, 트랜잭션 A가 기사의 읽기 량을 읽으면 트랜잭션 B가 제출한 데이터를 읽습니다. 결국 트랜잭션 B가 성공적으로 제출되지 않아 트랜잭션이 롤백되는 경우 실제로 읽은 양은 성공적으로 수정되지 않았지만 트랜잭션 A는 수정된 값을 읽게 되는데 이는 분명히 무리한 일입니다.

(2) 반복 불가능 읽기: 트랜잭션 A에서 동일한 데이터를 두 번 읽었지만 두 읽기의 결과가 다릅니다. 더티 읽기와 반복 불가능 읽기의 차이점은 전자는 다른 트랜잭션에서 커밋되지 않은 데이터를 읽는 반면, 후자는 다른 트랜잭션에서 제출한 데이터를 읽는다는 것입니다.

위 그림을 예로 들면, 트랜잭션 A가 기사 열람량 데이터를 차례로 읽어오면 결과가 달라집니다. 이는 트랜잭션 A가 실행되는 동안 다른 트랜잭션에 의해 읽기 볼륨의 값이 수정되었음을 의미합니다. 이는 데이터 쿼리 결과를 더 이상 신뢰할 수 없고 비현실적으로 만듭니다.

(3) 팬텀 읽기: 트랜잭션 A에서는 특정 조건에 따라 데이터베이스를 두 번 쿼리합니다. 두 쿼리 결과의 행 수가 다른 현상을 팬텀 읽기라고 합니다. 비반복 읽기와 팬텀 읽기의 차이점은 전자는 데이터가 변경되었음을 의미하고 후자는 데이터 행 수가 변경되었음을 의미하므로 쉽게 이해할 수 있습니다.

위 사진을 예로 들면, 0<읽은 양<100인 기사를 쿼리했을 때, 한 개의 결과가 먼저 발견되었고, 그 다음 두 개의 결과가 발견되었습니다. 이는 동일한 트랜잭션에 대한 쿼리 결과가 서로 다른 번호와 행 번호를 가지고 있음을 나타냅니다. 이러한 문제로 인해 특정 조건에 따라 데이터를 필터링할 때 사전 및 사후 필터링 결과를 신뢰할 수 없게 됩니다.

격리 수준

위의 세 가지 문제를 기반으로 4가지 격리 수준이 생성되어 데이터베이스의 격리 속성 수준이 서로 다름을 나타냅니다.

실제 데이터베이스 설계에서는 격리 수준이 높을수록 데이터베이스의 동시성 효율성이 낮아지며, 격리 수준이 너무 낮으면 읽기 및 쓰기 프로세스 중에 데이터베이스가 여러 가지 지저분한 문제에 직면하게 됩니다.

따라서 대부분의 데이터베이스 시스템에서 기본 격리 수준은 커밋된 읽기(예: Oracle) 또는 반복 가능한 읽기 RR(MySQL의 InnoDB 엔진)입니다.

MVCC

씹기 힘든 또 하나의 큰 덩어리. MVCC는 RR을 반복적으로 읽을 수 있는 위의 세 번째 격리 수준을 구현하는 데 사용됩니다.

MVCC: 다중 버전 동시성 제어 프로토콜인 다중 버전 동시성 제어입니다.

MVCC의 특징은 동시에 서로 다른 트랜잭션이 서로 다른 버전의 데이터를 읽을 수 있어 더티 읽기 및 반복 불가능 읽기 문제를 해결할 수 있다는 것입니다.

MVCC는 실제로 숨겨진 데이터 열과 롤백 로그(실행 취소 로그)를 통해 여러 버전의 데이터 공존을 실현합니다. 이것의 장점은 MVCC를 사용하여 데이터를 읽을 때 잠글 필요가 없으므로 동시 읽기 및 쓰기 충돌을 피할 수 있다는 것입니다.

MVCC를 구현할 때 버전 번호, 현재 행이 생성된 삭제 시간, 실행 취소 로그에 대한 롤백 포인터 등 데이터의 각 행에 여러 개의 숨겨진 열이 추가로 저장됩니다. 여기서 버전 번호는 실제 시간 값이 아니라 시스템 버전 번호입니다. 새로운 트랜잭션이 시작될 때마다 시스템 버전 번호가 자동으로 증가됩니다. 트랜잭션 시작 부분의 시스템 버전 번호는 트랜잭션의 버전 번호로 사용되며, 이는 쿼리에 있는 각 레코드 행의 버전 번호와 비교하는 데 사용됩니다.

각 트랜잭션에는 고유한 버전 번호가 있습니다. 이와 같이 트랜잭션 내에서 데이터 작업이 수행될 때 버전 번호 비교를 통해 데이터 버전 제어의 목적이 달성됩니다.

또한 InnoDB에서 구현한 격리 수준 RR은 다음 키 잠금 메커니즘을 통해 달성되는 팬텀 읽기 현상을 방지할 수 있습니다.

next-key 잠금은 실제로 행 잠금 유형이지만 현재 행 레코드 자체를 잠글 뿐만 아니라 범위도 잠급니다. 예를 들어, 위의 팬텀 독서 예시에서 0<읽기량<100인 기사를 조회하기 시작하면 결과가 하나만 검색됩니다. 다음 키 잠금은 쿼리된 행을 잠그고 0<읽기 볼륨<100 범위도 잠급니다. 이는 실제로 간격 잠금입니다. 간격 잠금은 이 간격 동안 다른 트랜잭션이 레코드를 수정하거나 삽입하는 것을 방지합니다. 이러한 방식으로, 0<판독량<100의 갭에서는 원래의 데이터 행만 존재하여 가상 판독을 방지하는 것이 보장됩니다.

Gap 잠금: 인덱스 레코드의 블록 간격

InnoDB는 팬텀 읽기 문제를 피하기 위해 다음 키 잠금을 사용하지만 이는 진정한 직렬화 격리가 아닙니다. 또 다른 예를 살펴보겠습니다.

먼저 질문 하나 하겠습니다.

T6 시점, 트랜잭션 A가 트랜잭션을 커밋한 후 기사 A와 기사 B의 독서량이 얼마나 되는지 추측해 보세요.

답은 AB글의 읽기량이 10,000으로 수정되었다는 것입니다. 이는 트랜잭션 B의 제출이 실제로 트랜잭션 A의 실행에 영향을 미치며 두 트랜잭션이 완전히 격리되지 않았음을 나타냅니다. 팬텀리딩(phantom reading) 현상을 피할 수는 있지만, 직렬화 수준에는 도달하지 못한다.

이는 또한 더티 읽기, 반복 불가능한 읽기 및 팬텀 읽기를 피하는 것이 직렬화 가능 격리 수준을 달성하기 위한 필요조건이지만 충분조건은 아니라는 것을 보여줍니다. 직렬화 가능성은 더티 읽기, 반복 불가능 읽기 및 팬텀 읽기를 방지할 수 있지만 더티 읽기, 반복 불가능 읽기 및 팬텀 읽기를 방지한다고 해서 반드시 직렬화 가능성이 달성되는 것은 아닙니다.

일관성

일관성이란 트랜잭션이 실행된 후 데이터베이스의 무결성 제약 조건이 파괴되지 않고 트랜잭션 실행 전후의 데이터 상태가 적법하다는 것을 의미합니다.

일관성은 트랜잭션이 추구하는 궁극적인 목표입니다. 원자성, 내구성 및 격리성은 실제로 데이터베이스 상태의 일관성을 보장하기 위해 존재합니다.

더 이상 할 말이 없습니다. 주의깊게 맛보시죠.

2. MySQL 로깅 시스템

MySQL의 기본 아키텍처를 이해하면 일반적으로 MySQL의 실행 프로세스를 보다 명확하게 이해할 수 있습니다. 다음으로 로깅 시스템을 소개하겠습니다.

MySQL 로깅 시스템은 데이터베이스의 중요한 구성 요소이며 데이터베이스에 대한 업데이트 및 수정 사항을 기록하는 데 사용됩니다. 데이터베이스에 장애가 발생한 경우, 다른 로그 기록을 통해 데이터베이스의 원본 데이터를 복원할 수 있습니다. 따라서 실제로 로그 시스템은 MySQL 운영의 견고성과 견고성을 직접적으로 결정합니다.

MySQL에는 바이너리 로그(binlog), 오류 로그, 쿼리 로그, 느린 쿼리 로그 등 다양한 종류의 로그가 있습니다. 또한 InnoDB 스토리지 엔진은 리두 로그(redo log)와 두 가지 종류의 로그도 제공합니다. 실행 취소 로그(롤 로그). 여기서는 InnoDB 엔진을 중심으로 redo 로그, 롤백 로그, 바이너리 로그의 세 가지 유형을 분석하겠습니다.

리두 로그(redo log)

리두 로그(redo log)는 InnoDB 엔진 계층의 로그로 트랜잭션 작업으로 인한 데이터 변경 사항을 기록하고 데이터 페이지의 물리적 변경을 기록하는 데 사용됩니다.

다시 실행 일기의 기능은 실제로 이해하기 쉽기 때문에 비유를 들어 보겠습니다. 데이터베이스의 데이터를 수정하는 것은 자신이 작성한 논문과 같습니다. 어느 날 논문이 분실되면 어떻게 될까요? 이러한 불행한 일을 방지하기 위해 논문을 작성할 때 모든 수정 사항을 기록하기 위해 작은 노트를 보관하고 특정 페이지에 언제 어떤 종류의 수정이 이루어졌는지 기록할 수 있습니다. 이것이 재실행 로그입니다.

InnoDB 엔진은 먼저 업데이트 기록을 리두 로그에 기록한 다음, 시스템이 유휴 상태일 때 또는 설정된 업데이트 전략에 따라 로그 내용을 디스크에 업데이트하는 방식으로 데이터를 업데이트합니다. 이것이 소위 미리 쓰기 기술(Write Ahead Logging)입니다. 이 기술은 IO 작업 빈도를 크게 줄이고 데이터 새로 고침 효율성을 향상시킬 수 있습니다.

더티 데이터 플러싱

리두 로그의 크기가 고정되어 있다는 점은 주목할 가치가 있습니다. 업데이트 레코드를 지속적으로 쓰기 위해 리두 로그에는 checkpoint와 write_pos라는 두 개의 플래그 위치가 각각 설정됩니다. 삭제가 기록되고, 쓰기가 기록되는 위치가 기록됩니다. 리두 로그의 데이터 쓰기 다이어그램은 아래 그림에서 볼 수 있습니다.

write_pos 플래그가 로그 끝에 도달하면 재순환 쓰기를 위해 끝에서 로그 헤드로 점프합니다. 따라서 리두로그의 논리적 구조는 선형적이지 않고 순환운동으로 볼 수 있다. write_pos와 체크포인트 사이의 공간은 새로운 데이터를 쓰는 데 사용될 수 있습니다. 쓰기와 지우기는 한 주기로 앞뒤로 수행됩니다.

write_pos가 체크포인트를 따라잡으면 redo 로그가 꽉 찼다는 뜻입니다. 현재로서는 새 데이터베이스 업데이트 문을 계속 실행할 수 없습니다. 먼저 일부 레코드를 중지하고 삭제한 다음 체크포인트 규칙을 실행하여 쓰기 가능한 공간을 확보해야 합니다.

체크포인트 규칙: 체크포인트가 트리거된 후 버퍼의 더티 데이터 페이지와 더티 로그 페이지가 모두 디스크로 플러시됩니다.

더티 데이터: 디스크에 플러시되지 않은 메모리의 데이터를 말합니다.

리두 로그에서 가장 중요한 개념은 버퍼 풀입니다. 이는 메모리에 할당된 영역으로, 디스크의 일부 데이터 페이지에 대한 매핑을 포함하고 데이터베이스에 액세스하기 위한 버퍼 역할을 합니다.

데이터 읽기 요청이 발생하면 먼저 버퍼 풀에 적중이 있는지 확인합니다. 누락이 있으면 디스크에서 검색하여 버퍼 풀에 넣습니다. 데이터 쓰기 요청이 들어오면 먼저 버퍼 풀에 쓰이고, 버퍼 풀에 있는 수정된 데이터는 주기적으로 디스크에 플러시됩니다. 이 과정을 브러싱이라고도 합니다.

따라서 데이터가 수정되면 버퍼 풀의 데이터를 수정하는 것 외에도 트랜잭션이 제출될 때 해당 작업이 리두 로그에 기록되고 리두 로그 기록을 기반으로 데이터가 플러시됩니다. . MySQL이 다운되면 다시 시작할 때 리두 로그의 데이터를 읽고 데이터베이스를 복원할 수 있으므로 트랜잭션의 내구성이 보장되고 데이터베이스가 충돌 방지 기능을 얻을 수 있습니다.

더티 로그 플러싱

위에서 언급한 더티 데이터 플러싱 외에도 실제로 리두 로그를 기록할 때 로그 파일의 지속성을 보장하기 위해 로그 기록도 작성해야 합니다. 메모리에서 디스크 프로세스까지. Redo 로그 로그는 휘발성 메모리에 존재하는 캐시 로그 Redo 로그 버프와 디스크에 저장되는 Redo 로그 파일로 크게 두 부분으로 나눌 수 있다. 각 레코드가 디스크의 로그에 기록될 수 있도록 하기 위해 리두 로그 버퍼의 로그가 리두 로그 파일에 기록될 때마다 운영 체제의 fsync 작업이 호출됩니다.

fsync 함수: UNIX 시스템 헤더 파일 #include에 포함되어 있으며 메모리에 있는 모든 수정된 파일 데이터를 저장 장치에 동기화하는 데 사용됩니다.

작성 과정 중에 운영 체제 커널 공간의 OS 버퍼도 통과해야 합니다. Redo Log가 작성되는 과정은 아래 그림과 같다.

redo 로그 플러시 프로세스

바이너리 로그(binlog)

바이너리 로그 binlog는 서비스 계층의 로그로 아카이브 로그라고도 합니다. Binlog는 주로 데이터베이스의 모든 업데이트 작업을 포함하여 데이터베이스의 변경 사항을 기록합니다. 데이터 변경과 관련된 모든 작업은 바이너리 로그에 기록되어야 합니다. 따라서 binlog는 데이터를 쉽게 복사하고 백업할 수 있어 마스터-슬레이브 라이브러리의 동기화에 자주 사용됩니다. 여기서 binlog에 저장된 내용은 redo log와 매우 유사한 것 같지만 그렇지 않습니다. 리두 로그는 특정 데이터에 대한 실제 수정 사항을 기록하는 물리적 로그인 반면, binlog는 "ID=2인 행의 필드를 제공합니다."와 같은 SQL 문의 원래 논리를 기록하는 논리적 로그입니다. 1"을 추가하세요. binlog 로그의 내용은 로그 형식 매개변수에 따라 SQL 문, 데이터 자체 또는 이 둘의 혼합을 기반으로 할 수 있습니다. 일반적으로 일반적으로 사용되는 레코드는 SQL 문입니다.

여기서 물리학과 논리의 개념에 대한 개인적인 이해는 다음과 같습니다.

물리적 로그는 실제 데이터베이스의 데이터 페이지에 있는 변경 정보로 간주할 수 있으며 결과에만 관심이 있습니다.

논리 로그는 특정 방법이나 작업으로 인해 발생한 데이터의 변경으로 볼 수 있으며 논리 연산이 저장됩니다.

동시에 redo 로그는 MySQL 충돌 후 데이터 복구를 보장하는 충돌 복구를 기반으로 하며, binlog는 특정 시점 복구를 기반으로 하여 서버가 시점에 따라 데이터를 복구하거나 데이터를 백업할 수 있도록 합니다. .

사실 MySQL에는 처음에는 Redo 로그가 없었습니다. 처음에는 MySQL에 InnoDB 엔진이 없었기 때문에 내장 엔진은 MyISAM이었습니다. Binlog는 서비스 계층 로그이므로 모든 엔진에서 사용할 수 있습니다. 그러나 binlog 로그만으로는 보관 기능만 제공할 수 있으며 충돌 방지 기능을 제공할 수 없습니다. 따라서 InnoDB 엔진은 충돌 방지 기능을 달성하기 위해 Oracle에서 배운 기술, 즉 리두 로그를 사용합니다. 다음은 각각 redo 로그와 binlog 로그의 특성을 비교한 것입니다.

redo 로그와 binlog 특성 비교

MySQL이 업데이트 문을 실행할 때 redo 로그와 binlog 로그를 읽고 쓰는 작업이 포함됩니다. 업데이트 문의 실행 과정은 다음과 같습니다.

MySQL 업데이트 문 실행 과정

위 그림에서 볼 수 있듯이 MySQL은 업데이트 문을 실행할 때 서비스 계층에서 해당 문을 구문 분석 및 실행하고, 엔진 계층에서 데이터를 추출하여 저장합니다. 동시에 서비스에서 계층은 binlog를 작성하고 InnoDB에 리두 로그를 작성합니다.

그뿐만 아니라 Redo 로그를 작성할 때 제출 단계에는 두 가지 단계가 있습니다. 하나는 binlog가 작성되기 전 준비 상태를 작성하는 것이고, 두 번째는 binlog가 작성된 후 커밋 상태를 작성하는 것입니다.

이런 2단계 제출이 마련되는 이유는 당연합니다. 이제 우리는 2단계 제출을 사용하는 대신 "단일 단계" 제출을 채택한다고 가정할 수 있습니다. 즉, 먼저 리두 로그를 작성한 다음 binlog를 작성하거나 먼저 binlog를 작성한 다음 리두 로그를 작성합니다. 이 두 가지 방법으로 제출하면 원본 데이터베이스의 상태가 복원된 데이터베이스의 상태와 일치하지 않게 됩니다.

리두 로그를 먼저 작성한 다음 binlog를 작성하세요.

리두 로그를 작성한 후 이때 데이터에는 충돌 방지 기능이 있으므로 시스템이 충돌하고 데이터는 트랜잭션이 시작되기 전 상태로 복원됩니다. 그러나 redo 로그가 완료되고 binlog가 기록되기 전에 시스템이 충돌하면 시스템이 충돌합니다. 이때 binlog는 위의 업데이트 문을 저장하지 않으므로, binlog를 사용하여 데이터베이스를 백업하거나 복원할 때 위의 업데이트 문이 누락됩니다. 결과적으로 id=2 행의 데이터는 업데이트되지 않습니다.

redo 로그를 먼저 작성한 후 binlog를 작성하는 문제

binlog를 먼저 작성하고 redo 로그를 작성하는 문제:

binlog를 작성하고 나면 모든 문이 저장되므로 binlog를 통해 복사하거나 복원할 수 있습니다. 데이터베이스의 행 id=2는 a=1로 업데이트됩니다. 그러나 Redo 로그가 기록되기 전에 시스템이 Crash되면 Redo 로그에 기록된 트랜잭션이 유효하지 않게 되어 실제 데이터베이스의 id=2 행에 있는 데이터가 업데이트되지 않게 된다.

binlog를 먼저 작성한 후 redo log를 작성하는 문제

2단계 제출은 위의 문제를 피하고 binlog와 redo log에 저장된 정보를 일관되게 만들기 위한 것임을 알 수 있다.

롤백 로그(undo 로그)

롤백 로그도 InnoDB 엔진에서 제공하는 로그인데 이름에서 알 수 있듯이 롤백 로그의 기능은 데이터를 롤백하는 것입니다. 트랜잭션이 데이터베이스를 수정하면 InnoDB 엔진은 다시 실행 로그를 기록할 뿐만 아니라 해당 실행 취소 로그도 생성합니다. 트랜잭션 실행이 실패하거나 롤백이 호출되어 트랜잭션이 롤백되는 경우 실행 취소 로그의 정보 수정 전의 모습으로 스크롤하여 데이터를 복원할 수 있습니다.

하지만 실행 취소 로그는 다시 실행 로그와 다릅니다. 논리적 로그입니다. SQL문의 실행과 관련된 정보를 기록합니다. 롤백이 발생하면 InnoDB 엔진은 실행 취소 로그의 기록을 기반으로 이전 작업과 반대되는 작업을 수행합니다. 예를 들어, 각 데이터 삽입 작업(삽입)의 경우 롤백 중에 데이터 삭제 작업(삭제)이 수행되고, 각 데이터 삭제 작업(삭제)에 대해 각 데이터에 대한 데이터 삽입 작업(삽입)이 수행됩니다. 업데이트(update) 작업(update), 롤백 시 역방향 데이터 업데이트 작업(update)을 수행하여 데이터를 다시 변경합니다. Undo 로그에는 두 가지 기능이 있습니다. 하나는 롤백을 제공하는 것이고 다른 하나는 MVCC를 구현하는 것입니다.

3. 마스터-슬레이브 복제

마스터-슬레이브 복제의 개념은 매우 간단합니다. 즉, 원본 데이터베이스를 마스터 데이터베이스라고 하고, 복사된 데이터베이스를 호출합니다. 슬레이브 데이터베이스. 슬레이브 데이터베이스는 마스터 데이터베이스와 데이터를 동기화하여 둘 사이의 데이터 일관성을 유지합니다.

마스터-슬레이브 복제 원리는 실제로 bin 로그를 통해 구현됩니다. bin 로그 로그는 모든 SQL 문을 데이터베이스에 저장하며, bin 로그 로그에 있는 SQL 문을 복사하여 실행함으로써 슬레이브 데이터베이스와 마스터 데이터베이스를 동기화할 수 있다.

마스터-슬레이브 복제 과정은 아래 그림에서 볼 수 있습니다. 마스터-슬레이브 복제 프로세스는 주로 3개의 스레드에 의해 수행됩니다. 송신 스레드는 마스터 서버에서 실행되며 binlog 로그를 슬레이브 서버로 보내는 데 사용됩니다. 슬레이브 서버에서는 두 개의 추가 I/O 스레드와 SQL 스레드가 실행됩니다. I/O 스레드는 메인 서버에서 보낸 binlog 로그 내용을 읽고 이를 로컬 릴레이 로그에 복사하는 데 사용됩니다. SQL 스레드는 릴레이 로그의 데이터 업데이트에 대한 SQL 문을 읽고 이를 실행하여 마스터 라이브러리와 슬레이브 라이브러리 간의 데이터 일관성을 유지하는 데 사용됩니다.

마스터-슬레이브 복제의 원리

마스터-슬레이브 복제를 구현해야 하는 이유는 실제로 실제 적용 시나리오에 따라 결정됩니다. 마스터-슬레이브 복제가 가져올 수 있는 이점은 다음과 같습니다.

1. 복제를 통해 데이터의 오프사이트 백업을 실현합니다. 마스터 데이터베이스에 장애가 발생하면 데이터 손실을 방지하기 위해 슬레이브 데이터베이스를 전환할 수 있습니다.

2. 비즈니스 규모가 커지고 I/O 액세스 빈도가 너무 높은 경우 다중 데이터베이스 스토리지를 사용하여 디스크 I/O 액세스 빈도를 줄이고 I/O 성능을 향상시킬 수 있습니다. 단일 기계의.

3. 읽기와 쓰기의 분리를 실현하여 데이터베이스가 더 큰 동시성을 지원할 수 있습니다.

4. 고객 쿼리의 부하를 마스터 서버와 슬레이브 서버로 나누어 서버 부하 분산을 구현합니다.

요약

MySQL 데이터베이스는 프로그래머가 반드시 마스터해야 할 기술 중 하나로 여겨져야 합니다. 프로젝트 진행 중이든, 인터뷰 중이든, MySQL은 매우 중요한 기본 지식입니다. 하지만 MySQL에는 정말 할 일이 너무 많습니다. 이 글을 쓰면서 많은 정보를 참고했는데, 이해가 안 될수록 이해가 안 된다는 걸 깨달았습니다.

더 많이 알수록, 모르는 것도 더 많아집니다.

이 글은 MySQL의 기본 트랜잭션과 로깅 시스템의 기본 원리를 이론적 관점에서 분석하는 데 초점을 맞췄습니다. 설명할 때 실제 코드를 사용하는 것을 피하려고 합니다. 거의 10,000개의 단어와 거의 20개의 손으로 그린 ​​그림이 포함된 이 기사조차도 MySQL의 폭과 깊이를 완전히 분석할 수는 없습니다.

하지만 저는 이러한 이론이 초보자에게 MySQL에 대한 전반적인 인식을 제공하고 "관계형 데이터베이스란 무엇인가"라는 질문에 대한 더 명확한 이해를 제공할 수 있다고 믿습니다. 그리고 MySQL에 능숙한 사람들에게는 아마도 그럴 것입니다. 이 기사는 또한 오랫동안 잃어버렸던 근본적인 이론적 기초를 깨울 수 있으며, 후속 인터뷰에도 도움이 될 것입니다.

기술에는 절대적인 옳고 그름이 없습니다. 기사에 실수가 있으면 용서해 주시고 토론을 환영합니다. 독립적인 사고는 수동적인 수용보다 항상 더 효과적입니다.

추천 학습: mysql 비디오 튜토리얼

위 내용은 MySQL 트랜잭션 로그를 함께 분석해보자의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!