MySQL 로깅 모듈 로깅-MySQL 튜토리얼-php.cn

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

1. 소개

2. Binlog

MySql 학습 칼럼

1. MySQL 인프라에 대한 자세한 설명

2. MySQL 인덱스 기반 데이터 구조 및 알고리즘

3. MySQL5.7에서 binlog 로그를 활성화하고, 데이터 복구에 대한 간단한 예

1. 소개

MySQL에는

redo 로그(다시 실행 로그)
와 binlog(아카이브 로그)라는 두 가지 중요한 로그 모듈이 있습니다. redo 로그는 InnoDB 스토리지 엔진 계층의 로그이고, binlog는 MySQL 서버 계층에서 기록하는 로그입니다. 둘 다 특정 작업을 기록하는 로그이지만 기록 형식이 다릅니다.

2. redo log

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 설정 로그 다시 실행

작성 시 innodb_log_buffer_size 크기: (기본값 8M)
innodb_log_file_size 리두 로그 파일의 크기.
innodb_log_files_in_group은 리두 로그 파일 그룹의 파일 수를 지정하며 기본값은 2입니다.
innodb_mirrored_log_groups는 로그 미러 파일 그룹의 수를 지정하며 기본값은 1
innodb_log_group_home_dir은 로그 파일 그룹이 있는 경로를 지정합니다. 기본값은 ./이며 데이터베이스 디렉터리의 데이터를 나타냅니다.
innodb_flush_log_at_trx_commit 커밋을 설정할 때 로그 버퍼의 로그를 로그 파일로 플러시하는 방법(값 0, 1, 2) 기본값 1

3. binlog

redo 로그는 InnoDB 엔진 고유 로그이며, 서버 계층에도 binlog(보관된 로그)라는 자체 로그가 있습니다.

왜 로그가 2개인가요?

처음에는 MySQL에 InnoDB 엔진이 없었거든요. MySQL의 자체 엔진은 MyISAM이지만 MyISAM에는 충돌 방지 기능이 없으며 binlog 로그는 보관에만 사용할 수 있습니다.

InnoDB는 다른 회사에서 플러그인 형태로 MySQL에 도입했습니다. binlog에만 의존하면 충돌 방지 기능이 없기 때문에 InnoDB는 충돌을 달성하기 위해 다른 로그 시스템, 즉 redo 로그를 사용합니다. safe 기능.

이 두 로그에는 다음 세 가지 차이점이 있습니다.

redo 로그는 InnoDB 엔진에 고유합니다. binlog는 MySQL의 서버 계층에서 구현되며 모든 엔진에서 사용할 수 있습니다.
redo 로그는 "특정 데이터 페이지에서 어떤 수정이 이루어졌는지"를 기록하는 물리적 로그입니다. binlog는 "give ID=와 같이 이 문의 원래 논리를 기록합니다. 2 이 줄의 c 필드에 1"을 추가합니다.
redo 로그는 루프로 작성되며 공간은 항상 소모됩니다. binlog를 추가로 작성할 수 있습니다. "쓰기 추가"는 binlog 파일이 특정 크기에 도달한 후 다음 파일로 전환하고 이전 로그를 덮어쓰지 않음을 의미합니다.

4. 내부 워크플로

실행기와 InnoDB 엔진의 내부 워크플로를 살펴보려면 테이블의 업데이트 문을 예로 들어보세요.

mysql> update T set c=c+1 where ID=2;

로그인 후 복사

아래 그림과 같이 라이트 박스 InnoDB 실행 내부에 있음을 나타냅니다. 어두운 상자는 실행기에서 실행됨을 나타냅니다.

실행기는 먼저 라인 ID=2를 얻기 위해 엔진을 찾습니다. ID는 기본 키이며 엔진은 이 행을 찾기 위해 트리 검색을 직접 사용합니다. ID=2인 행이 있는 데이터 페이지가 이미 메모리에 있으면 실행기로 직접 반환됩니다. 그렇지 않으면 먼저 디스크에서 메모리로 읽어온 다음 반환해야 합니다.
실행자는 엔진에서 제공한 행 데이터를 가져오고 이 값에 1을 더합니다. 예를 들어 이전에는 N이었지만 지금은 N+1이며 새 데이터 행을 가져온 다음 엔진 인터페이스를 호출하여 이 새로운 데이터 행을 작성하십시오.
엔진은 이 새로운 데이터 행을 메모리에 업데이트하고 업데이트 작업을 리두 로그에 기록합니다. 이때 리두 로그는 준비 상태입니다. 그런 다음 실행이 완료되었으며 언제든지 트랜잭션을 제출할 수 있음을 실행자에게 알립니다.
실행자는 이 작업의 binlog를 생성하고 binlog를 디스크에 씁니다.
Executor는 엔진의 커밋 트랜잭션 인터페이스를 호출하고, 엔진은 방금 작성된 Redo 로그를 커밋 상태로 변경하며 업데이트가 완료됩니다.

마지막 세 단계는 약간 "원형"처럼 보입니다. 리두 로그 작성은 준비와 커밋의 두 단계로 나누어집니다. 실제로는 "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 중국어 웹사이트의 기타 관련 기사를 참조하세요!