집 >데이터 베이스 >MySQL 튜토리얼 >MySQL 로깅 모듈 로깅
추천 무료 학습: mysql 비디오 튜토리얼
목차
1. 소개
2. Binlog
4.
1. MySQL 인프라에 대한 자세한 설명
2. MySQL 인덱스 기반 데이터 구조 및 알고리즘
3. MySQL5.7에서 binlog 로그를 활성화하고, 데이터 복구에 대한 간단한 예
4.
1. 소개MySQL에는
redo 로그(다시 실행 로그)2. redo log와 binlog(아카이브 로그)라는 두 가지 중요한 로그 모듈이 있습니다. redo 로그는 InnoDB 스토리지 엔진 계층의 로그이고, binlog는 MySQL 서버 계층에서 기록하는 로그입니다. 둘 다 특정 작업을 기록하는 로그이지만 기록 형식이 다릅니다.
redo log: (redo log) 파일이라고도 하며, 트랜잭션 작업의 변경 사항을 기록하는 데 사용되는 것은 데이터 수정 여부와 관계없이 기록됩니다. 거래가 제출되었습니다
. 미디어 오류가 발생하는 경우 리두 로그 파일이 유용할 수 있습니다. 데이터베이스 전원이 꺼진 경우 InnoDB 스토리지 엔진은 리두 로그를 사용하여 전원이 꺼지기 전 순간으로 복원하여 데이터 무결성을 보장합니다. . 레코드를 업데이트해야 할 경우 InnoDB 엔진은 먼저 해당 레코드를 리두 로그에 기록하고 메모리를 업데이트합니다. 이때 업데이트가 완료됩니다.
InnoDB 엔진은 적절한 시점에 이 작업 기록을 디스크에 업데이트하며, 이 업데이트는 업데이트 효율성을 높이기 위해 일반적으로 시스템이 상대적으로 유휴 상태일 때 완료됩니다.
여기에는
WAL즉, Write-Ahead Logging기술이 포함됩니다. 핵심은 로그를 먼저 쓴 다음 디스크에 쓰는 것입니다. InnoDB의 redo 로그는 고정된 크기를 가지고 있습니다. 예를 들어 4개의 파일로 구성할 수 있으며 각 파일의 크기는 1GB입니다. 그러면 총 4GB 작업을 기록할 수 있습니다. 리두 로그는 처음부터 쓰기 시작하고 끝에 도달하면 아래 그림과 같이 처음으로 돌아가서 루프를 작성합니다.
write pos는 현재 레코드의 위치입니다. 3번 파일 끝까지 쓴 후 0번 파일의 처음으로 돌아갑니다.
체크포인트는 현재 지워질 위치이며, 뒤로 이동하며 순환하기도 합니다. 기록을 삭제하기 전에 기록을 데이터 파일로 업데이트해야 합니다.
write pos와
check point사이의 사용되지 않은 부분은 새로운 작업을 기록하는 데 사용될 수 있습니다. write pos가
체크포인트를 따라잡으면, 이는 redo log 기록이 가득 차서 새로운 업데이트를 수행할 수 없다는 뜻입니다. 체크포인트를 진행하려면 먼저 일부 기록을 중지하고 삭제해야 합니다. . 리두 로그를 사용하면 InnoDB는 데이터베이스가 비정상적으로 다시 시작되더라도 이전에 제출된 레코드가 손실되지 않도록 보장할 수 있습니다. 이 기능을 crash-safe라고 합니다.
리두 로그를 사용하는 이유는 무엇인가요?
데이터베이스에 대해 DML 작업을 수행하고 실행된 SQL을 디스크에 직접 쓰는 경우 쓰기 동시성이 크면 디스크에 데이터를 쓰는 데 따른 압력이 작업을 삽입할 때 영향을 미칩니다. , 우리는 현재 비-리프 노드의 한 페이지에 있는 데이터 양이 충분하지 않은 경우 페이징 알고리즘을 사용해야 하며 이는 덜 효율적입니다.
리두 로그를 사용할 때 먼저 DML 작업을 작성합니다. 로그에 넣고 "전송 스테이션"을 통과한 다음 여유 있을 때 전달하세요.
체크 포인트디스크에 기록하면 효율성이 훨씬 높아집니다.
MySQL 설정 로그 다시 실행
3. binlog
redo 로그는 InnoDB 엔진 고유 로그이며, 서버 계층에도 binlog(보관된 로그)라는 자체 로그가 있습니다.
왜 로그가 2개인가요?
처음에는 MySQL에 InnoDB 엔진이 없었거든요. MySQL의 자체 엔진은 MyISAM이지만 MyISAM에는 충돌 방지 기능이 없으며 binlog 로그는 보관에만 사용할 수 있습니다.
InnoDB는 다른 회사에서 플러그인 형태로 MySQL에 도입했습니다. binlog에만 의존하면 충돌 방지 기능이 없기 때문에 InnoDB는 충돌을 달성하기 위해 다른 로그 시스템, 즉 redo 로그를 사용합니다. safe 기능.
이 두 로그에는 다음 세 가지 차이점이 있습니다.
4. 내부 워크플로
실행기와 InnoDB 엔진의 내부 워크플로를 살펴보려면 테이블의 업데이트 문을 예로 들어보세요.
mysql> update T set c=c+1 where ID=2;
아래 그림과 같이 라이트 박스 InnoDB 실행 내부에 있음을 나타냅니다. 어두운 상자는 실행기에서 실행됨을 나타냅니다.
마지막 세 단계는 약간 "원형"처럼 보입니다. 리두 로그 작성은 준비와 커밋의 두 단계로 나누어집니다. 실제로는 "2단계 커밋"입니다.
로그에 "2단계 커밋"이 필요한 이유는 무엇인가요? 이는 모순에 의한 증명으로 설명될 수 있다.
리두 로그와 binlog는 두 개의 독립적인 로직이므로 2단계 제출이 필요하지 않은 경우 리두 로그를 먼저 작성한 다음 binlog를 작성하거나 역순으로 사용해야 합니다. 이전 업데이트 문을 예로 들어 이 두 가지 방법에 어떤 문제가 있는지 살펴보겠습니다.
ID=2인 현재 행의 c 필드 값이 0이라고 가정하고, 또한 업데이트 문 실행 중에 첫 번째 로그가 작성된 후 두 번째 로그가 작성되기 전에 충돌이 발생한다고 가정합니다. 모직이 될까요?
1. 리두로그를 먼저 쓰고 그다음에 빈로그를 작성하세요. redo 로그가 기록될 때 binlog가 기록되기 전에 MySQL 프로세스가 비정상적으로 다시 시작된다고 가정해 보겠습니다. 리두 로그가 작성된 후 시스템이 충돌하더라도 데이터는 여전히 복원될 수 있으므로 복구 후 이 줄의 c 값은 1입니다.
하지만 binlog가 완료되기 전에 충돌이 발생했기 때문에 현재 이 명령문은 binlog에 기록되지 않았습니다. 따라서 나중에 로그를 백업할 때 저장된 binlog에는 이 문장이 포함되지 않습니다.
그러면 이 binlog를 사용하여 임시 라이브러리를 복원해야 하는 경우 이 문의 binlog가 손실되므로 이번에는 임시 라이브러리가 업데이트되지 않으며 복원된 줄의 c 값이 0이라는 것을 알 수 있습니다. 원래 라이브러리와 동일하지만 값이 다릅니다.
2.binlog를 먼저 작성하고 log를 다시 실행하세요. binlog를 작성한 후 충돌이 발생하면 redo 로그가 아직 작성되지 않았으므로 충돌 복구 후 트랜잭션이 무효화되므로 이 줄의 c 값은 0입니다.
하지만 binlog에는 "C를 0에서 1로 변경"이라는 로그가 기록되었습니다. 따라서 나중에 binlog를 사용하여 복원하면 트랜잭션이 하나 더 나오게 되는데, 복원된 행의 c 값은 1로 원래 데이터베이스의 값과 다릅니다.
"2단계 커밋"을 사용하지 않으면 데이터베이스 상태가 로그를 사용하여 복원된 라이브러리의 상태와 일치하지 않을 수 있음을 알 수 있습니다.
관련 무료 학습 권장 사항: mysql 데이터베이스(동영상)
위 내용은 MySQL 로깅 모듈 로깅의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!