MySQL 트랜잭션 로그의 특징은 무엇입니까?

1. MySQL 트랜잭션

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

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

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

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

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

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

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

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

Consistency(일관성): 트랜잭션이 추구하는 궁극적인 목표, 실현 일관성을 보장하려면 데이터베이스와 데이터베이스가 모두 필요합니다.

Atomicity

트랜잭션의 원자성은 트랜잭션을 세분화할 수 없음을 의미합니다. , 모든 작업이 수행되거나 모든 작업이 수행되지 않습니다. 트랜잭션이 실행되지 않으면 실행된 문도 롤백되어야 하며 데이터베이스는 트랜잭션 이전 상태로 돌아갑니다. 0과 1만 있습니다. , 다른 값은 없습니다. 트랜잭션의 원자성은 트랜잭션이 전체임을 나타냅니다. 트랜잭션이 실행되는 동안 트랜잭션에서 실행된 모든 문을 롤백해야 데이터베이스가 상태로 돌아갑니다.

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

지속성

트랜잭션의 내구성이란 트랜잭션이 제출된 후 데이터베이스의 변경 사항이 영구적으로 저장되어야 함을 의미하며, 이는 어떤 작업이나 시스템 다운타임이 발생하더라도 일시적이지 않습니다.

트랜잭션의 내구성은 InnoDB 스토리지 엔진의 리두 로그를 통해 달성됩니다.

격리

원자성과 내구성은 다음과 같습니다. 단일 트랜잭션 자체 수준의 속성인 반면 격리는 서로 격리되어야 하는 트랜잭션 간의 관계를 나타냅니다. 작업은 다른 트랜잭션을 방해해서는 안 됩니다.

트랜잭션에는 하나의 SQL 문만 포함될 수 없으므로 따라서 여러 트랜잭션이 동시에 실행되려면 작업이 서로 격리되어야 합니다. 이는 여러 스레드 간의 데이터 동기화 개념과 다소 유사합니다. 트랜잭션 간 격리는 잠금 메커니즘을 통해 이루어집니다. 특정 데이터 행이 수정되면 데이터를 먼저 잠가야 합니다. 다른 트랜잭션은 잠긴 데이터에 대해 작업을 실행하지 않고 현재 트랜잭션이 커밋되거나 롤될 때까지만 기다릴 수 있습니다.

다양한 잠금이 데이터를 보호하고 동기화하는 데 사용되므로 잠금 메커니즘은 익숙하지 않은 개념입니다. MySQL에서는 잠금을 여러 부문에 따라 여러 유형으로 나눌 수도 있습니다. 기준: 행 잠금, 테이블 잠금, 페이지 잠금

사용 방법에 따라 구분: 공유 잠금, 독점 잠금

아이디어에 따라 구분: 비관적 잠금, 낙관적 잠금

잠금 메커니즘에 대한 많은 지식 포인트가 있습니다. .. 지면이 부족해서 모두 설명하겠습니다. 다음은 세분화에 따라 구분된 잠금에 대한 간략한 소개입니다.

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

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

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

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

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

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

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

테이블 잠금은 데이터 연산 시 테이블 전체를 잠그므로 동시성 성능이 떨어집니다.

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

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

동시 읽기 및 쓰기 문제

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

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

위의 예시 시나리오에서 트랜잭션 A가 기사의 독서량을 읽으면 트랜잭션 B가 아직 제출하지 않은 데이터를 얻습니다. 결국 트랜잭션 B가 성공적으로 제출되지 않아 트랜잭션이 롤백되는 경우 실제로 읽은 양은 성공적으로 수정되지 않았으나 트랜잭션 A가 수정된 값을 읽는 것은 명백히 무리한 일입니다.

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

예를 들어 트랜잭션 A가 기사 열람량 데이터를 순차적으로 읽으면 다른 결과가 나옵니다. 이는 트랜잭션 A가 실행되는 동안 다른 트랜잭션에 의해 읽기 볼륨의 값이 수정되었음을 의미합니다. 이로 인해 데이터 쿼리 결과는 더 이상 신뢰할 수 없고 비현실적입니다.

재작성 후: 트랜잭션 A에서 특정 조건에 따라 두 개의 데이터베이스 쿼리를 수행하면 쿼리 결과의 행 수가 달라져 팬텀 읽기 현상이 발생합니다. 원래 단어는 다음과 같이 다시 작성할 수 있습니다. 팬텀 읽기와 비교할 때 반복 불가능 읽기는 데이터 행 수의 변경인 데이터 변경과 비슷합니다.

위 사진을 예로 들면, 0

격리 수준

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

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

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

MVCC

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

MVCC라고도 하는 다중 버전 동시성 제어는 여러 버전의 데이터를 지원할 수 있는 동시성 제어 프로토콜입니다.

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

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

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

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

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

다음 키 잠금은 실제로 행 잠금 유형이지만 현재 행 레코드 자체를 잠글 뿐만 아니라 범위도 잠급니다. 예를 들어 위의 팬텀 리딩 예시에서 0

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 로깅)입니다. 이 기술은 IO 작업 빈도를 크게 줄이고 데이터 새로 고침 효율성을 향상시킬 수 있습니다.

더티 데이터 플러싱

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

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

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

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

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

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

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

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

더티 로그 플러싱

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

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

작성할 때 운영 체제 커널 공간의 캐시도 통과해야 합니다. 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 log와 binlog의 특성을 비교합니다.

redo log와 binlog의 특성 비교

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

MySQL update 문의 실행 과정

위 그림에서 볼 수 있듯이 MySQL이 update 문을 실행하면 서비스에서 해당 문장을 파싱하여 실행하게 됩니다. 계층 및 엔진 계층에서는 데이터 추출 및 저장과 동시에 서비스 계층에 binlog가 기록되고 InnoDB에 redo 로그가 기록됩니다.

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

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

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

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

리두 로그를 먼저 쓰고 그 다음에 binlog를 쓰는 문제

binlog를 먼저 쓰고 그 다음에 redo 로그를 쓰는 문제:

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

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

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

롤백 로그(실행 취소 로그)

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 트랜잭션 로그의 특징은 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!