MySQL 로그에 대한 종합 가이드

이 기사에서는 주로 로그와 관련된 문제를 소개하는 mysql에 대한 관련 지식을 제공합니다. MySQL의 로그 시스템은 MySQL이 충돌하더라도 데이터가 손실되지 않도록 하는 핵심입니다. 모두에게 도움이 되기를 바랍니다.

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

Mysql의 로깅 시스템은 충돌이 발생하더라도 데이터가 손실되지 않도록 보장하는 Mysql의 핵심입니다.

우리 모두 알고 있듯이 Mysql은 영구 데이터베이스이며 모든 데이터는 하드 디스크에 영구적으로 저장되므로 데이터가 손실되지 않습니다.

Mysql은 다음 두 가지 측면에서 데이터가 손실되지 않음을 보장합니다.

• 언제든지 데이터 상태를 복원할 수 있습니다

• 아니요 트랜잭션 제출 전후의 문제 크래시가 발생하더라도 데이터는 손실되지 않습니다

트랜잭션 중 크래시가 발생해도 트랜잭션이 제출되기 전 상태로 복원될 수 있습니다

트랜잭션이 제출된 후 제출된 데이터는 충돌 후에도 손실되지 않습니다

위 두 가지 사항을 보장하는 MySQL의 핵심은 undo 로그, redo 로그 및 binlog를 세 가지 로그로 구현하는 것입니다. 다음으로

undo 로그 롤백 로그

undo를 하나씩 소개하겠습니다. log는 이전 버전의 데이터를 저장하는 Mysql의 롤백 로그입니다

주요 기능

이전 버전의 데이터 저장

읽기 보기 및 숨겨진 필드와 함께 작동하여 Mysql 스냅샷 읽기를 구현합니다

롤링하는 데 사용됩니다. 트랜잭션 실행이 실패하면 트랜잭션이 시작되기 전 버전으로 돌아갑니다

Undo 로그에는 어떤 종류가 있나요?

undo 로그에는 두 가지 유형이 있습니다

insert 명령의 경우 undo 로그에는 새로 생성된 기본 키가 기록됩니다. 추가된 레코드를 롤백하는 동안 실행 취소 로그의 기본 키에 따라 해당 레코드를 삭제할 수 있습니다

업데이트/삭제 명령의 경우 실행 취소 로그는 수정된 레코드의 이전 데이터를 기록합니다

Mysql의 각 데이터 행에는 두 개의 필드가 있습니다. : 최근 수정된 현재 데이터 행의 트랜잭션 ID 및 롤백 포인터 데이터 행이 수정된 후 실행 취소 로그 포인터는 이전 데이터 행을 가리키고 새로 생성된 데이터 행의 롤백 포인터는 실행 취소 로그 포인터가 현재 가리키는 이전 데이터 행을 가리킵니다.

• Mysql은 실행 취소 로그 포인터가 가리키는 내용을 수정하는 것을 방지합니다. 동시성 문제가 발생하면 수정하기 전에 실행 취소 로그 포인터에 배타적 잠금이 추가됩니다. undo 로그의 올바른 작성

undo 로그 삭제 시기

undo 로그는 트랜잭션이 제출되지 않았는지 확인하는 데 사용됩니다. 제출되지 않은 상태로 원활하게 롤백될 수 있습니다. 트랜잭션이 시작되기 전에 실행 취소 로그는 해당 기능을 잃어 삭제해야 합니다. 실행 취소 로그는 Mysql의 Purage 스레드에 의해 삭제됩니다. Purage는 실행 취소 로그에서 delete_bit 플래그를 확인합니다. 트랜잭션이 커밋된 후 true로 설정됩니다. 삭제 스레드가 true인 레코드를 찾으면 이를 삭제하는 책임을 집니다.

redo 로그 redo 로그

redo 로그는 Mysql의 물리적 로그입니다. 의 작업은 특정 데이터 페이지에서 수행됩니다

리두 로그의 역할

기록된 내용은 아마도 x 테이블 An의 페이지 y의 z 오프셋일 것입니다. 업데이트가 이루어졌습니다
Mysql은 트랜잭션을 커밋할 때 데이터 지속성 디스크를 기다릴 필요가 없고 리두 로그만 디스크에 유지하면 됩니다
삭제되지 않은 리두 로그의 수는 디스크가 플러시되지 않았습니다. 더티 페이지 수
트랜잭션을 제출할 때 데이터를 디스크에 유지하는 대신 리두 로그를 유지하도록 선택하는 이유는 무엇입니까?

디스크에 데이터를 유지하는 것은 무작위 IO 프로세스이므로 Mysql은 캐시를 선택합니다. IO를 줄이기 위해 데이터를 디스크에 한 번에 기록합니다

그러나 메모리의 데이터 캐시 손실 위험이 있기 때문에 Mysql은 redo log 유지를 선택합니다

redo 로그는 순차적으로 기록되므로 효율성이 높습니다. Random Write보다 지속성이 높으며, Redo 로그는 데이터의 변경 사항을 기록합니다. Redo 로그가 있는 한 MySQL을 다시 시작한 후에도 데이터를 복원할 수 있습니다.

InnoDB에서는 Redo 로그가 고정되어 있습니다. -크기의 원형 큐와 같은 존재이며, 각각의 쓰기는 뒤에서부터 이루어짐 쓰기 pos의 위치는 데이터를 지속시킬 때 앞으로 읽기 위해 체크 포인트를 이동

이 디자인의 이유는 redo 로그가 존재하기 때문입니다. Mysql 충돌 후 캐시된 더티 페이지 데이터가 손실되는 것을 방지합니다

Mysql의 데이터가 디스크에 유지된 후 리두 로그의 지속된 부분은 실제로 쓸모가 없으며 새로운 데이터를 기록할 공간을 만들 수 있습니다

실행 취소 로그와 다시 실행 로그의 차이점

undo 로그는 트랜잭션 실행 중 오래된 데이터의 상태를 기록하고, redo 로그는 데이터 업데이트 후의 상태를 기록합니다.

redo 로그는 실제로 트랜잭션의 내구성과 일관성을 보장하는 반면, undo 로그는 트랜잭션의 원자성을 보장합니다. 특징

binlog 아카이브 로그

binlog는 Mysql 서버 레이어에서 구현한 로그입니다.

Function

binlog는 MySQL의 원래 문장 로직을 기록하므로, 추가 작성이 가능합니다. 언제든지 mysql의 데이터베이스 데이터 상태를 복원하는 데 사용됩니다

그래서 binlog는 아카이브 로그라고 합니다

동시에 binlog는 마스터-슬레이브 복제를 구현하는 Mysql의 종속성이기도 합니다. 슬레이브 라이브러리는 메인을 동기화합니다. 메인 라이브러리에서 binlog 재생을 복사하여 라이브러리. 데이터 상태

정의

먼저 디스크에 로그를 쓴 다음 디스크에 데이터를 씁니다. Mysql의 쓰기 작업은 디스크에 기록되지 않습니다. 즉시 실행되지만 redo 로그와 binlog가 모두 디스크에 지속성인지 확인하기 위해 로그가 먼저 기록되고 그런 다음 백그라운드 스레드가 데이터를 하드 디스크에 유지할 시간을 선택합니다.

로그를 기록해야 하는 이유 디스크 먼저

더티 페이지를 플러시하는 것은 임의 읽기 및 쓰기 프로세스이므로 디스크에 유지됩니다. 속도는 확실히 redo log | 나중에 디스크에 비동기적으로 유지할 수 있는 기회를 선택하세요

더티 페이지가 디스크에 플러시되기 전에 이 기간 동안 redo log | binlog는 데이터의 지속성을 보장하고 정전 시 메모리의 데이터 손실을 방지합니다. 더티 페이지가 가득 차면 더티 페이지를 모두 제거한 다음 다음에 사용할 때 다시 실행 로그를 통해 복원해야 합니다. 성능상, 디스크에서 메모리로 데이터를 읽을 때마다 데이터를 리두 로그와 비교하고 업데이트해야 한다면 효율성이 매우 낮습니다.

MySQL 브러시 더티 페이지를 디스크에 쓰면 데이터 페이지가 메모리에 최신 데이터가 반환될 수 있습니다. 메모리에 데이터가 없으면 동일한 페이지로 다시 이동할 필요 없이 디스크에서 읽어서 최신의 올바른 데이터를 확실히 얻을 수 있습니다

binlog 및 redo 로그 작성 프로세스 - WAL 메커니즘의 기본 보장

binlog 및 redo 로그 모두 로그 쓰기를 캐시 쓰기, 쓰기 및 동기화의 세 가지 프로세스로 나눕니다

트랜잭션 실행 중 프로세스 중에 binlog 및 redo 로그는 해당 할당된 캐시에 기록되므로 트랜잭션이 제출될 때 한 번에 디스크에 쓸 수 있습니다. 트랜잭션이 제출되면 캐시에 데이터를 쓰기 위해 쓰기가 먼저 수행됩니다. 이때 데이터가 실제로 파일에 기록되지는 않았지만 보관을 위해 운영 체제의 캐시에 넘겨졌습니다. 이때 Mysql 프로세스가 충돌하더라도 기록된 데이터 중 이 부분은 손실되지 않습니다. 운영 체제의 커널 스레드가 캐시에 있는 데이터의 이 부분을 디스크에 기록합니다

그러나 운영 체제가 충돌하면 데이터의 이 부분이 손실됩니다

마지막으로 mysql 페이지 캐시에 기록된 데이터를 하드 디스크에 유지하기 위해 수동으로 동기화를 호출합니다. 쓰기가 완료된 후 데이터는 성공적으로 유지됩니다

마지막 쓰기 및 동기화 단계에서는 mysql이 쓰기 전략을 제어하기 위해 해당 매개변수를 제공합니다

• redo 로그는 innodb_flush_log_at_trx_commit에 의해 제어됩니다

0으로 설정하면 트랜잭션이 제출될 때마다 리두 로그가 리두 로그 캐시에만 남게 됩니다. 1로 설정하면 손실 위험이 가장 커집니다. 트랜잭션이 제출될 때마다 리두 로그가 디스크에 직접 유지된다는 의미

손실 위험은 최소화되지만 IO 사용량이 큽니다

2로 설정하면 트랜잭션이 발생할 때마다 커밋되면 redo 로그는 페이지 캐시에만 기록됩니다
IO 사용량이 중앙에 있고 쓰기는 디스크에서 가장 많은 IO를 소비하는 프로세스는 운영 체제에 맡겨집니다. binlog는 매개변수에 의해 제어됩니다. sync_binlog.sync_binlog=0이면 트랜잭션이 제출될 때마다 쓰기만 수행되고 fsync가 수행되지 않는다는 의미입니다.

sync_binlog= 1이면 트랜잭션이 제출될 때마다 fsync가 실행된다는 의미입니다. =N(N>1)은 트랜잭션이 제출될 때마다 쓰기가 수행되지만 N개의 트랜잭션이 누적된 후에 fsync가 실행된다는 의미입니다.
• 리두 로그 제출 과정은 준비와 커밋 두 단계로 나누어집니다. Binlog 로그 제출은 이 두 단계의 중간에 있습니다.
  트랜잭션이 제출되면 리두 로그가 먼저 오고 제출 후 준비 상태로 진입합니다. binlog 제출이 완료된 후 리두 로그는 제출된 커밋으로 로그 상태를 변경할 수 있습니다

2단계 로그 제출이 필요한 이유

• InnoDB 엔진의 리두 로그 롤백 메커니즘과 관련이 있습니다. submit되었습니다. 트랜잭션을 롤백할 수 없습니다. redo 로그가 제출된 후 binlog가 기록되지 않으면 두 가지 불일치가 발생합니다. 이때 데이터베이스가 비정상적으로 다시 시작되면 어떤 것을 사용해야 하는지 생각해 볼 가치가 있습니다. 데이터를 복원하므로 로그 제출은 두 단계만 필요합니다

  binlog가 작성되지 않았고 redo 로그가 제출되지 않았기 때문에 A 시간에 데이터베이스가 충돌하여 다시 시작한 후 트랜잭션이 롤백되고 두 로그가 여전히 동일한 상태에 있다고 가정합니다. B 구간이면 수정이 필요하며, REDO 로그의 커밋 플래그가 있는지 확인하여 커밋 플래그가 있으면 바로 제출한다. Redo 로그에 해당 트랜잭션의 커밋 플래그가 없으면 binlog를 확인합니다.

  binlog가 완료되고 커밋 플래그가 있으면 트랜잭션이 제출되고 커밋 플래그가 Redo 로그 뒤에 추가됩니다. .binlog가 불완전하면 트랜잭션이 롤백됩니다
  여기에서 2단계 로그 제출 중에 충돌이 발생한 것을 확인할 수 있습니다. 그 이유는 binlog를 기반으로 하기 때문입니다. binlog 기반으로 두 로그의 무결성을 확인해야 하는 경우 마스터 라이브러리가 중단되면 슬레이브 라이브러리로 전환하는 시간이 길어집니다. Binlog 벤치마크로 기본 데이터베이스가 다운된 경우 binlog를 사용하면 됩니다. 슬레이브 데이터베이스에서 데이터를 복원하려면 리두 로그의 무결성을 확인할 필요가 없습니다

  • 또한 binlog는 MySQL 서버 계층의 공통 로그이므로 binlog가 벤치마크로 선택된 이유이기도 합니다

  스테이지 로그 제출의 두 가지 단점

  디스크 IO 횟수가 높음

  로그를 제출할 때 redo 로그 및 binlog에 해당하는 플러시 작업이 발생합니다. IO 수가 높습니다

  • 잠금 경쟁이 치열합니다.

  여러 트랜잭션이 제출될 때 로그 레코드가 트랜잭션 제출 순서와 일치하는지 확인하기 위해 로그 제출의 상대적 순서를 보장하기 위해 잠금이 사용됩니다.

  그러나 동시성이 다음과 같으면 성능이 저하됩니다. Large
  그룹 제출 메커니즘
  그룹 제출 메커니즘의 역할

  제출을 벗어난 트랜잭션이 있는 경우 여러 트랜잭션의 로그를 병합하여 기록하므로 디스크 IO 작업이 줄어듭니다

  그룹 제출 메커니즘 구현

  그룹 제출 메커니즘은 커밋 프로세스를 세 개의 프로세스로 나누고 각 프로세스에 대한 대기열을 유지하며 잠금을 사용하여 트랜잭션 쓰기 순서를 보장합니다

  잠금을 세 단계로 나누면 트랜잭션의 전체 제출 프로세스를 잠그지 않고 세분성 잠금

  큐가 비어 있으면 큐에 들어가는 첫 번째 트랜잭션이 후속 트랜잭션의 리더가 되어 후속 트랜잭션이 다음 작업 단계를 완료하도록 유도합니다

  1단계 : flush 단계: 여러 트랜잭션이 항목 순서대로 캐시의 binlog를 파일에 기록합니다(디스크를 플러시하지 않음)

  • 플러시 단계에 들어가는 첫 번째 트랜잭션이 선두의 리더 역할을 합니다. 후속 트랜잭션

  리더십 트랜잭션은 모든 트랜잭션이 리두 로그에 + fsync를 쓰도록 유도합니다. 즉, 리두 로그를 디스크에 쓰고 리두 로그의 제안 단계를 완료합니다.

  Mysql이 이 단계에서 충돌하면 이 다시 시작한 후 트랜잭션 세트가 롤백됩니다.

  2단계: sync: binlog 파일에서 fsync 작업을 수행합니다(여러 트랜잭션의 binlog를 병합하고 디스크를 함께 플러시합니다)flush阶段 : 多个事务按进入的顺序将binlog从cache中写入文件 (不刷盘)

  第一个进入flush阶段的事务会作为领导者领导后面进入的事务

  领导者事务会带领所有的事务对 redo log 进行一次 write + fsync, 也就是将redo log 写入磁盘, 完成redo log 的propare阶段

  如果在这个阶段Mysql崩溃了, 会在重启后回滚这组事务

  阶段二 : sync : 对binlog文件做fsync操作 (将多个事务的binlog合并一起刷盘)

  在flush阶段将binlog写入到binlog文件后, 会等待一段时间再进行刷盘, 目的是组合更多事务的binlog一起刷盘减少消耗

  等待会有时间限制和最大事务限制, 满足其中一个条件就会立刻对binlog进行刷盘

  sync阶段主要负责binlog的组提交, 如果当前阶段Mysql崩溃的话, 在重启后可以通过redo log的刷盘记录继续完成事务提交

  • 因为此时binlog已经完成提交了, 所以可以根据redo log来继续提交事务

  阶段三 : commit

  binlog를 작성한 후 플러시 단계의 binlog 파일은 일정 시간 동안 대기합니다. 그런 다음 디스크를 플러시합니다. 목적은 더 많은 트랜잭션의 binlog를 결합하고 디스크를 함께 플러시하여 소비를 줄이는 것입니다

  시간 제한과 최대 트랜잭션이 있습니다. 대기 제한 중 하나가 충족되면 binlog가 즉시 플러시됩니다

  동기화 단계는 주로 binlog 그룹 제출을 담당하며, 현재 단계에서 MySQL이 충돌하면 다음을 통해 트랜잭션 제출을 계속 완료할 수 있습니다. 재시작 후 redo 로그 플러시 기록🎜🎜🎜🎜이 시점에서 binlog 제출이 완료되었으므로 계속해서 redo 로그에 따라 트랜잭션을 제출할 수 있습니다🎜🎜🎜 🎜3단계: commit: InnoDB 수행 각 트랜잭션에 대한 작업 커밋🎜🎜권장 학습: 🎜mysql 비디오 튜토리얼🎜🎜

위 내용은 MySQL 로그에 대한 종합 가이드의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!