MySQL 리두 로그의 개념은 무엇입니까?

트랜잭션의 ACID 특성 중 원자성(A), 일관성(C), 지속성(D)은 undo log, redo log로 구현하고 격리(I)는 lock + MVCC

undo log로 구현합니다.: transaction still 커밋이 없고 실행 중에 예외가 발생하면 undo 로그를 사용하여 트랜잭션 실행 전 상태로 데이터를 복원하여 트랜잭션의 원자성을 보장할 수 있습니다.

redo 로그: 트랜잭션 커밋이 성공합니다. 잠시 동안 디스크 데이터를 업데이트하는데, 이때 예외가 발생하면 redo 로그를 사용하여 이 트랜잭션의 SQL을 다시 실행하여 트랜잭션의 내구성을 보장할 수 있습니다. 어떤 비정상적인 이벤트가 발생하더라도 다음번에는 MySQL 서비스가 정상적으로 실행되기만 하면 마지막 커밋의 데이터를 복원해야 합니다)

1. 리두 로그의 개념

리두 로그: 물리적 로그라고 합니다. 페이지별로 저장된 최종 수정 데이터 페이지입니다. 데이터의 최종 상태를 직접 저장하며 트랜잭션의 내구성을 보장하는 데 사용됩니다.

논리 로그는 실행 취소 로그라고도 하며 해당 SQL 문의 구체적인 내용을 기록합니다. 지금 insert를 실행하면 롤백 시 삭제가 실행되고, 지금 업데이트를 실행하면 원래의 이전 값이 다시 업데이트됩니다

redo 로그는 기본적으로

에 위치합니다/var/lib/mysql

redo 로그는 트랜잭션에 포함됩니다. 시작할 때 기록 시작 (트랜잭션이 커밋되면 기록되지 않습니다. 전체 트랜잭션이 여러 작업을 수행할 수 있기 때문입니다. 커밋할 때 리두 로그를 작성한다면 이때 예외가 발생하면 리두 로그가 기록되지 않습니다. 너무 늦어서 트랜잭션의 내구성을 보장할 수 없음) 예외가 발생하면(예: 데이터 지속성 프로세스 중 정전) 트랜잭션의 제출 여부와 상관없이 기록됩니다. 데이터의 무결성을 보장하기 위해 리두 로그를 사용하여 데이터 무결성을 보장합니다. 성능

innodb_log_buffer_size는 트랜잭션이 시작되면 리두 로그 버퍼의 크기인 16M으로 설정됩니다. 트랜잭션이 상대적으로 크기 때문에 트랜잭션 실행 중에 디스크 IO가 너무 많이 소비되는 것을 방지하기 위해 Redo 로그 캐시가 디스크 IO를 절약하는 더 큰 값을 설정할 수 있습니다. 디스크에 플러시할 때 새로 고치는 시간이 있습니다. 해당 시간에 도달하면 디스크 IO가 소비됩니다. 버퍼가 상대적으로 크면 새로 고치는 시간이 더 느리게 도달하고 효율성이 높아집니다.

InnoDB는 디스크의 데이터를 직접 수정하는 것이 아니라, 실제로는 버퍼 풀의 데이터만 수정하는 방식으로 작업 데이터를 수정합니다. InnoDB는 항상 충돌 후 데이터 복구를 위해 먼저 버퍼 풀의 데이터 변경 사항을 리두 로그에 기록합니다. 먼저 redo 로그를 기록한 다음 버퍼 풀의 더티 데이터를 디스크에 천천히 새로 고칠 수 있는 기회를 찾으세요.

innodb_log_group_home_dir이 지정한 디렉터리에 있는 두 개의 파일: ib_logfile0, ib_logfile1, 이 파일을 리두 로그라고 합니다.

버퍼 풀 캐시 풀: 인덱스 캐시, 데이터 캐시 등을 저장할 수 있으며 읽기 및 쓰기 속도를 높일 수 있으며 데이터 페이지를 직접 조작하고, 리두 로그 수정이 완료되더라도 버퍼 풀의 더티 페이지를 디스크에 쓰는 전용 스레드가 있습니다

버퍼 풀의 기본 크기는 134M입니다(MySQL 5.7)

일반적인 구조는 그림과 같습니다.

트랜잭션 읽기 및 수정은 모두 캐시 풀의 데이터에 우선순위를 둡니다. 실제 프로젝트에서 mysqld는 CRUD 속도를 높이기 위해 특별히 InnoDB의 버퍼 풀에 많은 양의 메모리를 할당할 수 있는 별도의 시스템에서 실행됩니다. 2. 트랜잭션이 커밋되면 관계에서 작업이 수행됩니다. 그림은 InnoDB 로그 버퍼의 내용을 디스크에 쓰는 것입니다. 쓰기가 성공하면 디스크의 리두 로그에 상태(쓰기가 성공하지 못하거나 완료되면 준비)가 기록됩니다.

디스크에 로그를 쓰는 과정에서 이상 현상, 정전, 기타 문제가 발생하여 리두 로그 쓰기가 완료되지 않을 수도 있습니다(이는 트랜잭션이 성공적으로 커밋되지 않는 것과 같습니다). 이때 MySQL은 다음 복원 시 실패할 것입니다. 상태가 커밋이 아니기 때문에 이 트랜잭션의 무결성을 고려할 필요가 없습니다. 디스크에 모든 것이 기록된 경우에만 리두 로그가 성공적으로 기록되었음을 나타냅니다. 상태는 커밋이 됩니다. 상태가 커밋으로 변경된 후에도 트랜잭션의 ACID 특성을 유지해야 합니다.

버퍼 폴의 더티 데이터(데이터가 수정됨)는 커밋할 때만 디스크에 기록된다는 것이 사실인가요?

커밋이 시작될 때까지 기다릴 필요가 없습니다. 트랜잭션이 수정할 수 있는 데이터의 양은 상대적으로 크고 캐시 용량은 제한되어 있습니다. 버퍼 폴링으로 캐시된 데이터의 경우 적절한 시간에 디스크의 데이터를 새로 고치는 전용 스레드가 있습니다. 정전이 발생하면 다음에 MySQL이 시작될 때 redo에 따라 새로 고쳐집니다. 로그에 기록된 데이터가 복원됩니다.

undo 로그 자체도 redo 로그에 기록됩니다

undo 로그는 트랜잭션 롤백을 지원하며, 즉시 완료될 수 없습니다. 롤백 과정에서 예외가 발생하지 않도록 디스크의 데이터는 결국 수정됩니다. 최하위 계층의 경우 작업이 리두 로그에 성공적으로 기록된 후 트랜잭션이 성공적으로 커밋(commit)되거나 성공적으로 롤백(rollback)되었는지 여부에 관계없이 성공한 것으로 간주됩니다.

실제 트랜잭션 커밋 성공이란 무엇인가요?

모든 데이터를 디스크에 플러시하는 대신 트랜잭션의 전체 작업을 기록하는 Redo 로그를 로그 버퍼에서 디스크에 기록한 다음 수정된 데이터의 상태를 커밋으로 설정하여 성공적인 트랜잭션을 달성합니다. 저지르다. 현재 데이터는 여전히 버퍼 폴에 있지만 리두 로그가 그대로 유지되는 한 데이터를 복원할 수 있습니다. 버퍼 폴의 데이터를 디스크에 쓰는 작업을 담당하는 전용 스레드가 있습니다

트랜잭션이 실행되면 항상 Redo 로그를 먼저 쓰고 버퍼 풀을 작성하며, 트랜잭션이 성공적으로 커밋되면 Redo 로그가 디스크에 완전히 기록되는지 확인해야 합니다. 테이블 데이터를 사용하는 경우 버퍼 풀의 더티 데이터 페이지를 디스크로 새로 고칠 필요가 전혀 없습니다. 리두 로그가 디스크에 완전히 기록되는 한 성공적으로 커밋된 트랜잭션의 데이터 상태를 복원할 수 있습니다. 언제든 redo log를 통해 (

데이터베이스에서 가장 중요한 것은 데이터가 아닌 로그

)

위 내용은 MySQL 리두 로그의 개념은 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!