면접관: MySQL의 2단계 제출 메커니즘에 대해 이야기해 보겠습니다.

이 기사에서는 MySQL의 2단계 제출 메커니즘을 이해하고, redo 로그와 bin 로그를 소개하고, 2단계 제출을 완료하기 위해 어떻게 협력하는지 살펴보겠습니다.

MySQL은 2단계 제출 메커니즘을 통해 redo 로그와 bin 로그의 논리적 일관성을 보장하므로 데이터가 손실되지 않고 마스터-슬레이브 데이터베이스의 데이터가 일관성을 유지합니다.

2단계 제출이라고 하면 먼저 redo 로그와 bin 로그를 소개해야 합니다.

redo log

redo log는 redo log로, InnoDB 엔진 고유의 로그입니다(일부 면접관들이 이에 대해 자주 질문합니다).

리두로그는 주로 어떤 일을 하나요?

데이터 업데이트를 예로 들면, MySQL 데이터가 디스크에 저장되어 있다는 것을 알고 있습니다. 데이터가 업데이트될 때마다 업데이트할 데이터를 찾기 위해 디스크를 검색하면 IO 비용이 발생합니다. 매우 높을 것입니다.

솔리드 스테이트 드라이브라면 괜찮지만, 기계식 하드 드라이브라면 MySQL의 업데이트 성능이 우리의 비즈니스 요구를 전혀 충족할 수 없습니다.

그래서 MySQL은 WAL(Write-Ahead Logging)이라는 기술을 사용합니다.

데이터를 업데이트할 때 업데이트 작업(즉, 특정 데이터 페이지에서 어떤 수정이 이루어졌는지)이 먼저 리두 로그에 기록된 다음 메모리가 업데이트됩니다. MySQL은 데이터 일관성을 유지하기 위해 서버가 유휴 상태일 때 리두 로그 작업 기록을 디스크에 플러시합니다.

주의할 점은 REDO 로그도 디스크에 있는 파일이지만 순차적 쓰기이기 때문에 성능이 매우 높다는 점입니다.

물론 REDO 로그에도 크기 제한이 있어 무제한 쓰기는 불가능합니다.

위 사진을 예로 들어보겠습니다. 4개의 Redo 로그가 구성되어 있습니다. 쓰기 pos는 현재 레코드가 기록되는 위치를 나타내고, 체크 포인트는 데이터를 삭제하기 위해 계속 전진합니다. . 리두 로그가 지속적으로 기록될 수 있도록 보장하는 작업입니다.

물론, 데이터를 삭제하기 전에 리두 로그 기록이 디스크에 플러시됩니다.

리두 로그를 통해 MySQL이 비정상적으로 재시작되더라도 데이터가 손실되지 않도록 할 수 있습니다. (리두 로그는 물리적 로그이므로 재생할 수 있기 때문입니다.) 이 기능을 크래시 세이프(crash-safe)라고 합니다.

bin log

bin log는 MySQL Server에서 제공하는 로그로 archive log라고 합니다. 모든 엔진에서 bin log를 사용할 수 있습니다.

bin 로그와 redo 로그의 차이점은 무엇인가요?

1. 이 두 로그의 공급자는 다릅니다. bin 로그는 MySQL 서버에서 제공되고 redo 로그는 InnoDB 엔진에 고유합니다.

2. 리두 로그는 주로 특정 데이터 페이지에 대한 수정 사항을 기록합니다. 예를 들어 특정 행의 특정 필드를 업데이트하는 경우입니다.

3. 리두 로그는 반복적으로 작성되며 데이터가 덮어쓰여집니다. Bin 로그가 추가됩니다. 한 파일이 가득 차면 다음 파일이 기록됩니다.

2단계 제출

리두 로그와 빈 로그를 소개한 후, 두 가지가 어떻게 협력하여 2단계 제출을 완료하는지 살펴보겠습니다.

위 그림은 데이터를 업데이트하기 전에 MySQL이 먼저 데이터를 메모리에 로드한 다음 메모리를 업데이트하고 리두 로그를 작성하기 시작하는 것을 볼 수 있습니다.

이때 Redo 로그는 준비 상태입니다. bin 로그 쓰기가 완료된 후 트랜잭션이 제출되면 이 레코드의 업데이트 작업이 완료됩니다.

redo 로그 준비 -> bin 로그 작성 -> redo 로그 커밋, 이 프로세스를 2단계 커밋이라고 합니다.

2단계 제출 사용의 이점을 분석해 보겠습니다.

시나리오 1: Redo 로그가 준비 상태일 때 bin 로그에 쓰기가 실패하면 업데이트가 실패합니다. 이때 redo 로그에는 커밋이 없고 bin 로그에는 기록이 없습니다. 일관성이 있고 문제가 없습니다.

시나리오 2: redo 로그가 준비 상태일 때 bin 로그는 성공적으로 기록되지만 컴퓨터가 다운되어 커밋이 실패합니다. 이때 bin 로그에 기록이 생성되고 redo 로그가 성공적으로 기록되지 않았으며 데이터가 일시적으로 불일치했습니다.

하지만 걱정하지 마세요. MySQL이 다시 시작되면 Redo 로그에서 준비 상태의 레코드를 확인할 것입니다. Redo 로그에는 실제로 작성에 실패하면 제출이 포기된다는 필드가 있습니다.

이 메커니즘을 통해 redo 로그와 bin 로그의 일관성이 보장됩니다.

Summary

MySQL에 redo 로그와 bin 로그가 모두 있는 이유는 bin 로그는 MySQL Server에서 제공하는 아카이브 로그이고 자체적으로 충돌 방지 기능이 없기 때문입니다. Redo 로그 자체에는 보관 기능이 없습니다. 루프로 작성된 로그입니다.

MySQL은 이 두 로그를 통합하고 2단계 제출 메커니즘을 사용하여 데이터 일관성을 보장합니다.

글쓰기가 쉽지 않은데 많은 좋아요와 관심 부탁드립니다.

【관련 추천: mysql 비디오 튜토리얼】

위 내용은 면접관: MySQL의 2단계 제출 메커니즘에 대해 이야기해 보겠습니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!