소개 MySQL 로그 다시 실행 로그 및 binlog

ㅋㅋㅋ 리두 로그(무거운) 로깅) 및 binlog(아카이브 로그). 오늘은 이 두 로그의 용도와 차이점을 공유해 보겠습니다.

간단히 말하면 redo 로그는 InnoDB 고유의 로그입니다. 다른 스토리지 엔진을 사용하면 redo 로그는 없고 binlog만 있습니다. Binlog는 MySQL의 서버 계층의 로그입니다. 어떤 스토리지 엔진을 사용하든 binlog가 있습니다. 그렇다면 왜 redo log와 binlog가 필요한가요? 하나의 binlog로 모든 것을 해결할 수는 없을까? 다음으로 redo log와 binlog의 차이점을 자세히 살펴보겠습니다.

redo logMySQL에서 명령문을 업데이트하려면 업데이트 조건을 가져와야 합니다. 예: update T set name = 'god-jiang' 여기서 id=6, 일반적으로 id= 먼저 쿼리 6 문을 선택한 다음 업데이트 작업을 수행합니다.

업데이트 수가 100, 1,000 또는 10,000인 경우 각 업데이트를 디스크에 기록해야 합니다. 그런 다음 해당 레코드를 디스크에서 찾아 업데이트해야 합니다. 이 문제를 해결하기 위해 MySQL 설계자는 이를 해결하기 위해 IO 비용과 검색 비용이 너무 높습니다. WAL의 전체 이름은

Write Ahead Logging

이며, 이는 로그를 먼저 쓴 다음 디스크에 쓰는 것을 의미합니다. 특정 작업: 레코드를 업데이트해야 할 경우 InnoDB 엔진은 먼저 해당 레코드를 리두 로그에 기록하고 메모리를 업데이트합니다. 이때 업데이트가 완료됩니다. 동시에 InnoDB 엔진은 적절한 시간(시스템이 유휴 상태일 때)에 디스크에 작업 기록을 업데이트합니다. 이 업데이트는 시스템이 상대적으로 유휴 상태일 때 자주 발생합니다.

하지만 redo 로그의 크기는 고정되어 있어 항상 무한히 쓸 수는 없습니다. MySQL이 어떻게 하는지 살펴보겠습니다.

write pos는 현재 레코드의 위치이며, 쓰는 동안 뒤로 이동합니다. 체크포인트는 현재 삭제될 위치로, 기록을 삭제하기 전에 기록을 데이터 파일로 업데이트해야 합니다.

쓰기 위치와 체크 포인트 사이의 녹색 부분은 새로운 작업을 기록할 수 있음을 나타냅니다. 쓰기 pos가 체크포인트를 따라잡는다면 redo 로그가 꽉 찼다는 뜻이며, 이때는 새로운 작업을 계속할 수 없다는 뜻입니다. 일부 레코드 삭제를 중단하고 체크포인트를 다시 푸시해야 합니다. 리두 로그를 사용하면 InnoDB는 데이터베이스가 예외를 감지하고 다시 시작하더라도 이전에 제출된 트랜잭션이 손실되지 않도록 보장할 수 있습니다. 이 기능을

crash-safe

라고도 합니다. 위 내용은 redo log에 대한 소개입니다. 이 글을 읽고 나면 회사의 DBA 동료에게 MySQL을 반달 안에 어느 순간의 상태로 복원할 수 있는지 물어볼 수 있습니다. 재실행 로그 덕분에.

binlog

MySQL을 전체적으로 보면 실제로 두 개의 레이어로 나누어져 있는데, 하나는 서버 레이어이고 다른 하나는 스토리지 엔진 레이어입니다. 위에서 설명한 redo 로그는 InnoDB 엔진 고유의 로그인 반면, binlog는 서버 계층에 속하는 로그로 아카이브 로그라고도 합니다.

리두 로그와 binlog의 차이점

redo 로그는 InnoDB 엔진에 고유합니다. binlog는 MySQL의 서버 계층에서 구현되며 모든 엔진에서 사용할 수 있습니다.

redo 로그는 기록을 남기는 물리적 로그입니다. "XXX 데이터 "XXX 수정이 페이지에서 이루어졌습니다"; binlog는 원래 논리를 기록하는 논리 로그이며 해당 기록은 해당 SQL 문입니다.

redo 로그는 루프로 작성되며 공간은 확실히 부족하므로 pos 작성 및 체크포인트가 필요합니다. 특정 크기로 작성하면 다음 로그로 전환되며 이전 로그를 덮어쓰지 않습니다.

간단한 update 문을 통해 executor와 InnoDB 엔진

update T set name = 'god-jiang' where id = 6

InnoDB 엔진에서 executor를 통해 id=6인 레코드를 꺼내 메모리에 로드

executor는 엔진이 반환한 결과를 받아, 'god-jiang'이라는 이름을 지정한 다음 스토리지 엔진 인터페이스를 다시 호출하여 새 데이터를 씁니다

엔진은 새 데이터 업데이트를 메모리에 쓰는 동시에 업데이트 작업을 리두 로그에 씁니다. , 리두 로그는 준비 상태입니다. 실행자는 이 작업의 binlog를 생성하고 binlog를 디스크에 기록합니다. 실행자는 트랜잭션을 제출하기 위해 엔진의 인터페이스를 호출하고 커밋에 방금 기록된 리두 로그를 변경합니다. 상태, 업데이트 완료

• 해당 흐름도
• 마지막으로 왜 redo 로그는 prepare 상태에 쓰고, binlog는 commit 상태에 쓰는 걸까요? 실제로 이 과정을 "2단계 제출"이라고 합니다.

2단계 커밋

실제로 redo 로그와 binlog는 모두 트랜잭션 제출 상태를 나타내는 데 사용될 수 있으며, 2단계 커밋은 두 상태를 논리적으로 일관되게 유지하는 것입니다.

1. 예: update T 세트 이름 = 'god-jiang' 여기서 id = 62단계 커밋이 없으면 어떻게 되나요?

   다시 실행 로그를 먼저 작성한 다음 binlog를 작성하세요. Redo 로그를 작성한 후 아직 binlog가 작성되지 않았는데 이때 MySQL이 비정상적으로 재시작한다고 가정해보자. Redo 로그가 기록되었기 때문에 시스템 복구 시 이름='god-jiang' 입니다. 하지만, binlog가 작성되지 않았기 때문에 binlog에는 이 문장이 기록되지 않는다. 이때 binlog를 사용하여 데이터를 복원하면 복원된 이름은 redo log와는 다른 원래 값이다.

   마찬가지로 binlog를 먼저 작성한 다음 redo log를 작성해 보면 두 로그에서 복구한 데이터가 다르다는 것도 알 수 있습니다. 이러한 불일치는 온라인에서 마스터-슬레이브 불일치로 이어집니다.

   요약

   • redo 로그는 충돌 방지 기능을 저장하고 MySQL이 비정상적으로 다시 시작될 때 데이터가 손실되지 않도록 보장할 수 있습니다.
   • binlog는 해당 SQL 문을 기록하고 MySQL이 비정상적으로 다시 시작될 때 데이터가 손실되지 않도록 보장할 수 있습니다. . 스테이지 제출은 데이터 논리적 일관성을 유지할 수 있습니다

   관련 무료 학습 권장 사항:

   mysql 데이터베이스(동영상)

위 내용은 소개 MySQL 로그 다시 실행 로그 및 binlog의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!