MySQL의 세 가지 주요 로그: 실행 취소 로그, 다시 실행 로그, binlog

SQL 실행 프로세스

실행 취소 로그가 필요한 이유는 무엇입니까?

실행 취소 로그 플러시는 어떻게 수행됩니까(디스크에 지속)?

버퍼 풀이 필요한 이유는 무엇입니까?

버퍼 풀은 무엇을 캐시합니까?

실행 취소 페이지에는 무엇을 기록하나요?

레코드를 쿼리할 때 하나의 레코드만 버퍼링하면 되나요?

왜 리두 로그가 필요한가요?

리두 로그란 무엇인가요?

Undo 페이지가 수정되면 해당 Redo 로그를 기록해야 하나요?

재실행 로그와 실행 취소 로그의 차이점은 무엇입니까?

Redo 로그를 디스크에 기록해야 하고, 데이터도 디스크에 기록해야 하는데, 왜 귀찮을까요?

리두 로그는 언제 플러시되나요?

왜 binlog가 필요한가요?

binlog가 있는데 왜 redo 로그가 필요한가요?

리두 로그와 빈 로그의 차이점은 무엇입니까?

실수로 데이터베이스 데이터 전체를 삭제한 경우, 리두 로그 파일을 이용하여 데이터를 복구할 수 있나요?

SQL 실행 프로세스

우리는 쿼리문이 거치는 과정, 즉 레코드를 "읽는" 과정을 아래와 같이 알고 있습니다.

UPDATE t_user SET name = 'xiaolin' WHERE id = 1;

쿼리 문과 업데이트 문에 대한 일련의 프로세스도 동일한 프로세스를 거칩니다.

클라이언트는 먼저 커넥터를 통해 연결을 설정하고 커넥터는 자동으로 사용자의 신원을 확인합니다.
업데이트 문이므로 쿼리 캐시를 거치지 않아도 되지만, 테이블에 업데이트 문이 있으면 테이블 전체의 쿼리 캐시가 지워지므로 쿼리 캐시는 쓸모가 없게 되며, 이 기능은 MySQL 8.0에서 제거되었습니다.
파서는 어휘 분석을 통해 키워드 업데이트, 테이블 이름 등을 식별하고 구문 트리를 구축한 다음 구문 분석을 수행하여 입력 문이 MySQL 구문을 준수하는지 확인합니다.
전처리기는 테이블과 필드가 존재하는지 여부를 결정합니다.
옵티마이저는 실행 계획을 결정하는데, where 조건의 id가 기본 키 인덱스이므로 id 인덱스를 사용하기로 결정합니다.
실행자는 특정 실행을 담당하고 이 행을 찾아 업데이트합니다.

그러나 명령문 업데이트 프로세스에는 실행 취소 로그(롤백 로그), 다시 실행 로그(다시 실행 로그) 및 binlog(아카이브 로그)의 세 가지 유형의 로그가 포함됩니다.

undo log(롤백 로그) : Innodb 스토리지 엔진 계층에서 생성되는 로그로 트랜잭션의 원자성을 구현하며 주로 트랜잭션 롤백 및 MVCC에 사용 됩니다 .
리두 로그(redo log) : Innodb 스토리지 엔진 계층에서 생성되는 로그로 트랜잭션의 지속성을 구현하며 주로 정전 등 장애 복구에 사용됩니다 .
binlog (아카이브 로그) : 서버 계층에서 생성되는 로그로 주로 데이터 백업 및 마스터-슬레이브 복제에 사용됩니다 .

실행 취소 로그가 필요한 이유는 무엇입니까?

"추가, 삭제 및 수정" 문을 실행할 때 트랜잭션을 시작하기 위해 시작하고 트랜잭션을 제출하기 위해 커밋을 입력하지 않더라도 MySQL은 " 추가, 삭제 및 수정" 문을 실행하기 위해 암시적으로 트랜잭션을 시작합니다 . 실행 후 자동으로 트랜잭션을 커밋합니다. 이렇게 하면 "추가, 삭제, 수정" 문을 실행한 후 시간에 맞춰 데이터베이스 테이블에서 "추가, 삭제, 수정" 결과를 볼 수 있다는 것이 보장됩니다.

명령문 실행 시 트랜잭션을 자동으로 커밋할지 여부는 autocommit 매개변수에 따라 결정되며 기본적으로 활성화됩니다. 따라서 업데이트 문을 실행하면 트랜잭션도 사용됩니다.

그렇다면 질문 하나를 생각해 보십시오. 트랜잭션 실행 중에 트랜잭션이 커밋되기 전에 MySQL이 충돌하는 경우 트랜잭션 이전의 데이터로 롤백하는 방법은 무엇입니까?

트랜잭션이 실행되는 동안 롤백에 필요한 정보를 매번 로그에 기록해 두면 트랜잭션 실행 도중에 MySQL이 충돌하더라도 트랜잭션 이전의 데이터로 롤백하지 못할까 봐 걱정할 필요가 없습니다. 로그는 트랜잭션 이전의 데이터로 롤백됩니다.

이를 구현하는 메커니즘은 트랜잭션의 ACID에서 원자성(원자성)을 보장하는 실행 취소 로그(롤백 로그) 입니다 .

실행 취소 로그는 실행 취소 롤백에 사용되는 로그입니다. 트랜잭션이 커밋되기 전에 MySQL은 먼저 업데이트된 데이터를 실행 취소 로그 파일에 기록하며, 트랜잭션이 롤백되면 실행 취소 로그를 사용하여 롤백할 수 있습니다. 아래 그림과 같이:

InnoDB 엔진은 레코드(수정, 삭제, 추가)에 대해 작동할 때마다 다음과 같이 롤백에 필요한 모든 정보를 실행 취소 로그에 기록해야 합니다.

레코드를 삽입할 때 이 레코드의 기본 키 값을 적어야 나중에 롤백할 때 이 기본 키 값에 해당하는 레코드만 삭제하면 됩니다 .
레코드를 삭제할 때에는 레코드의 내용을 모두 적어두어야 나중에 롤백할 때 이러한 내용으로 구성된 레코드를 테이블에 삽입 할 수 있다.
레코드를 업데이트할 때 업데이트된 열의 이전 값을 기록하여 롤백 시 해당 열이 이전 값으로 업데이트 될 수 있도록 합니다.

롤백이 발생하면 Undo 로그에 있는 데이터를 읽어 역방향 작업을 수행합니다. 예를 들어, 레코드가 삭제되면 해당 레코드의 내용이 Undo 로그에 기록되고, 이후 롤백 작업이 수행되면 Undo 로그에 있는 데이터를 읽어서 삽입 작업이 수행됩니다.

작업마다 기록해야 하는 내용이 다르기 때문에 작업 유형(수정, 삭제, 추가)에 따라 생성되는 실행 취소 로그의 형식도 다릅니다. 각 작업의 구체적인 실행 취소 로그 형식에 대해서는 자세히 소개하지 않겠습니다. 네, 관심이 있으시면 직접 확인해 보실 수 있습니다.

레코드의 각 업데이트 작업으로 생성된 실행 취소 로그 형식에는 Roll_pointer 포인터와 trx_id 트랜잭션 ID가 있습니다.

trx_id를 통해 어떤 트랜잭션이 레코드를 수정했는지 알 수 있습니다.
이러한 실행 취소 로그는 Roll_pointer 포인터를 통해 연결된 목록에 연결될 수 있습니다. 이 연결된 목록을 버전 체인이라고 합니다.

버전 체인은 아래와 같습니다.

또한 undo log에는 ReadView + undo log를 통해 MVCC(다중 버전 동시성 제어)를 구현하는 기능도 있습니다 .

"읽기 커밋" 및 "반복 읽기" 격리 수준이 있는 트랜잭션의 경우 해당 스냅샷 읽기(일반 select 문)는 읽기 보기 + 실행 취소 로그를 통해 구현됩니다. 차이점은 읽기 보기 생성 시점에 있습니다.

"읽기 커밋" 격리 수준은 각 선택에 대해 새로운 읽기 보기를 생성합니다. 이는 또한 트랜잭션 중에 동일한 데이터를 여러 번 읽는 경우 도중에 다른 데이터가 있을 수 있으므로 전후에 두 번 읽은 데이터가 일치하지 않을 수 있음을 의미합니다. 이 기간 트랜잭션이 레코드를 수정하고 트랜잭션을 커밋했습니다.
"반복 읽기" 격리 수준은 트랜잭션 시작 시 읽기 보기를 생성하고 전체 트랜잭션 동안 이 읽기 보기를 사용합니다. 이렇게 하면 트랜잭션 중에 읽은 데이터가 트랜잭션이 시작되기 전의 모든 레코드임을 보장합니다.

이 두 가지 격리 수준은 "트랜잭션의 읽기 보기에 있는 필드"와 "레코드에 있는 두 개의 숨겨진 열(trx_id 및 Roll_pointer)"의 비교를 통해 구현됩니다. 표시되는 행이 만족되지 않으면 실행 취소 로그 버전 체인이 가시성을 만족하는 레코드를 찾아 동일한 레코드에 접근할 때 동시 트랜잭션의 동작을 제어하는 것을 MVCC(Multiple Version Concurrency Control)라고 합니다.

따라서 실행 취소 로그에는 두 가지 주요 기능이 있습니다.

트랜잭션 롤백을 구현하고 트랜잭션의 원자성을 보장합니다 . 트랜잭션 처리 중에 오류가 발생하거나 사용자가 ROLLBACK 문을 실행하면 MySQL은 실행 취소 로그의 기록 데이터를 사용하여 트랜잭션이 시작되기 전의 상태로 데이터를 복원할 수 있습니다.
MVCC(다중 버전 동시성 제어) 구현의 핵심 요소 중 하나입니다 . MVCC는 ReadView + undo log를 통해 구현됩니다. 실행 취소 로그는 각 레코드에 대한 기록 데이터의 여러 복사본을 저장합니다. MySQL이 스냅샷 읽기(일반적인 select 문)를 실행할 때 실행 취소 로그의 버전 체인을 따라 트랜잭션의 읽기 정보에 있는 정보를 기반으로 가시성을 충족하는 레코드를 찾습니다. 보다.

실행 취소 로그 플러시는 어떻게 수행됩니까(디스크에 지속)?

실행 취소 로그와 데이터 페이지의 플러시 전략은 동일하며 둘 다 지속성을 보장하기 위해 다시 실행 로그가 필요합니다.

버퍼 풀에는 Undo 페이지가 있으며, Undo 페이지에 대한 수정 사항도 Redo 로그에 기록됩니다. 다시 실행 로그는 매초마다 디스크를 플러시하고 트랜잭션이 제출될 때도 디스크를 플러시합니다. 데이터 페이지와 실행 취소 페이지는 지속성을 보장하기 위해 이 메커니즘을 사용합니다.

버퍼 풀이 필요한 이유는 무엇입니까?

MySQL 데이터는 디스크에 저장되므로 레코드를 업데이트하려면 먼저 디스크에서 레코드를 읽은 다음 메모리에서 레코드를 수정해야 합니다. 이 레코드를 수정한 후 디스크에 직접 다시 쓰도록 선택해야 합니까, 아니면 캐시하도록 선택해야 합니까?

물론 캐시하는 것이 더 좋습니다. 그러면 다음에 쿼리 문이 이 레코드에 도달할 때 디스크에서 데이터를 가져올 필요 없이 캐시에 있는 레코드를 직접 읽을 수 있습니다.

이를 위해 Innodb 스토리지 엔진은 데이터베이스의 읽기 및 쓰기 성능을 향상시키기 위해 버퍼 풀(Buffer Pool)을 설계했습니다.

완충 똥을 먹은 후:

데이터를 읽을 때 버퍼 풀에 데이터가 있으면 클라이언트는 버퍼 풀에 있는 데이터를 직접 읽고, 그렇지 않으면 디스크에서 읽습니다.
데이터 수정 시 버퍼 풀에 데이터가 존재하는 경우 버퍼 풀에 있는 데이터가 있는 페이지를 직접 수정한 후 해당 페이지를 더티 페이지로 설정(이 페이지의 메모리 데이터가 더 이상 데이터와 일치하지 않음) 디스크를 줄이기 위해 I/O에서는 더티 페이지가 즉시 디스크에 기록되지 않으며 나중에 백그라운드 스레드가 더티 페이지를 디스크에 기록할 적절한 시간을 선택합니다.

버퍼 풀은 무엇을 캐시합니까?

InnoDB는 디스크와 메모리 간 상호 작용의 기본 단위로 페이지를 사용하여 저장된 데이터를 여러 "페이지"로 나눕니다. 페이지의 기본 크기는 16KB입니다. 따라서 버퍼 풀도 "페이지"로 나누어야 합니다.

MySQL이 시작되면 InnoDB는 버퍼 풀을 위한 연속적인 메모리 공간을 적용한 후 16KB기본 크기에 따라 페이지를 페이지로 나누는데, 버퍼 풀에 있는 페이지를 캐시 페이지라고 합니다 . 현재 이러한 캐시 페이지는 무료이지만 나중에 프로그램이 실행되면 디스크의 페이지가 버퍼 풀에 캐시됩니다.

따라서 MySQL을 처음 시작할 때 사용되는 가상 메모리 공간은 크지만 사용되는 물리적 메모리 공간은 매우 작은 것을 볼 수 있는데, 이는 운영 체제가 이러한 가상 메모리에 액세스한 후에만 페이지 폴트 인터럽트를 트리거하기 때문입니다. 물리적 메모리를 적용한 다음 가상 주소와 물리적 주소 간의 매핑 관계를 설정합니다.

버퍼 풀에는 "인덱스 페이지" 및 "데이터 페이지" 캐싱 외에도 실행 취소 페이지, 삽입 캐시, 적응형 해시 인덱스, 잠금 정보 등이 포함됩니다.

실행 취소 페이지에는 무엇을 기록하나요?

트랜잭션이 시작된 후 InnoDB 계층이 레코드를 업데이트하기 전에 해당 실행 취소 로그를 먼저 기록해야 하며 업데이트 작업인 경우 업데이트된 열의 이전 값을 기록해야 합니다. 즉 실행 취소 로그를 기록해야 합니다. 생성되고 실행 취소 로그가 버퍼 풀에 기록됩니다. 의 실행 취소 페이지.

레코드를 쿼리할 때 하나의 레코드만 버퍼링하면 되나요?

아니요.

레코드를 쿼리하면 InnoDB는 전체 데이터 페이지를 버퍼 풀에 로드하고 페이지를 버퍼 풀에 로드한 후 페이지의 "페이지 디렉터리"를 통해 특정 레코드를 찾습니다.

왜 리두 로그가 필요한가요?

버퍼 풀이 읽기 및 쓰기 효율성을 향상시키는 것은 사실이지만 문제는 버퍼 풀이 메모리를 기반으로 하기 때문에 메모리는 항상 불안정하기 때문에 정전 및 재시작 시 시간이 없는 더티 페이지 데이터가 디스크에 기록된 내용이 손실됩니다.

정전으로 인한 데이터 손실을 방지하기 위해 레코드를 업데이트해야 할 경우 InnoDB 엔진은 먼저 메모리를 업데이트하고 더티 페이지로 표시한 다음 이 페이지에 대한 수정 사항을 redo 형식으로 기록합니다. log., 현재 업데이트가 완료되었습니다 .

이후 InnoDB 엔진은 적절한 시점에 백그라운드 스레드를 통해 버퍼 풀에 캐시된 더티 페이지를 디스크로 플러시하는 것이 바로 WAL(Write-Ahead Logging) 기술 입니다 .

WAL 기술은 MySQL의 쓰기 작업이 즉시 디스크에 기록되지 않고 로그가 먼저 기록된 후 적절한 시점에 디스크에 기록된다는 의미입니다 .

리두 로그란 무엇인가요?

Redo 로그는 특정 데이터 페이지에 대한 수정 사항을 기록하는 물리적 로그입니다. 예를 들어 XXX 테이블스페이스에 있는 YYY 데이터 페이지의 ZZZ 오프셋에 대해 AAA 업데이트가 수행됩니다 . 트랜잭션이 실행될 때마다 이러한 메시지가 표시됩니다. 또는 여러 물리적 로그.

트랜잭션이 커밋되면 먼저 Redo 로그를 디스크에 유지하기만 하면 되며 버퍼 풀에 캐시된 더티 페이지 데이터가 디스크에 유지될 때까지 기다릴 필요가 없습니다.

시스템이 다운되면 더티 페이지 데이터는 유지되지 않지만 리두 로그는 남게 되며, MySQL을 재시작한 후에는 리두 로그의 내용을 바탕으로 모든 데이터를 최신 상태로 복원할 수 있다.

Undo 페이지가 수정되면 해당 Redo 로그를 기록해야 하나요?

필요합니다.

그러나 Undo 페이지가 메모리에 수정된 후에는 해당 Redo 로그가 기록되어야 합니다 .

재실행 로그와 실행 취소 로그의 차이점은 무엇입니까?

이 두 가지 유형의 로그는 InnoDB 스토리지 엔진에 속하며 차이점은 다음과 같습니다.

리두 로그는 " 완료 후 " 트랜잭션의 데이터 상태를 기록 하고 업데이트된 값을 기록합니다 .
실행 취소 로그는 이 트랜잭션의 " 시작 전 " 데이터 상태를 기록 하고 업데이트 전의 값을 기록합니다 .

트랜잭션이 커밋되기 전에 크래시가 발생했다면 재시작 후 언두 로그를 통해 트랜잭션을 롤백하고, 트랜잭션 커밋 후 크래시가 발생한 경우에는 재시작 후 리두 로그를 통해 트랜잭션을 복원한다.

따라서 InnoDB는 Redo Log와 WAL 기술을 이용하여 데이터베이스가 비정상적으로 재시작되더라도 이전에 제출된 레코드가 손실되지 않도록 보장할 수 있는데, 이 기능을 Crash-Safe (충돌 복구)라고 합니다. 리두 로그는 트랜잭션의 4가지 주요 특성에 대한 내구성을 보장한다는 것을 알 수 있습니다 .

Redo 로그를 디스크에 기록해야 하고, 데이터도 디스크에 기록해야 하는데, 왜 귀찮을까요?

Redo 로그를 작성하는 방법은 추가 작업을 사용하므로 디스크 작업은 순차 쓰기 이고, 데이터를 쓰는 경우 먼저 쓰기 위치를 찾아 디스크에 써야 하므로 디스크 작업은 랜덤 쓰기 이다 .

디스크에 "순차 쓰기"는 "무작위 쓰기"보다 훨씬 효율적이므로 디스크에 리두 로그 쓰기에 따른 오버헤드가 더 작습니다.

'순차 쓰기'가 '무작위 쓰기'보다 빠른 이유에 대해서는 노트를 가지고 있는 것과 비교할 수 있는데, 단어 하나하나를 쓰기 위해 해당 페이지를 찾아야 하는 것보다 한 페이지씩 순서대로 쓰는 것이 확실히 훨씬 빠릅니다.

이는 WAL 기술의 또 다른 장점이라고 할 수 있습니다. MySQL의 쓰기 작업이 디스크에 대한 "임의 쓰기"에서 "순차 쓰기"로 변경되어 명령문의 실행 성능이 향상됩니다. 이는 MySQL의 쓰기 작업이 즉시 디스크에 업데이트되지 않고 먼저 로그에 기록된 후 적절한 시점에 디스크에 업데이트되기 때문입니다.

이 시점에서 리두 로그가 필요한 이유에 대한 두 가지 답변이 있습니다.

트랜잭션 내구성을 구현하고 MySQL 충돌을 방지하여 언제든지 MySQL이 갑자기 충돌하더라도 이전에 제출된 레코드가 다시 시작한 후 손실되지 않도록 보장합니다.
쓰기 작업을 "임의 쓰기"에서 "순차 쓰기"로 변경하여 디스크에 대한 MySQL 쓰기 성능을 향상시킵니다.

리두 로그는 언제 플러시되나요?

리두 로그 버퍼에 캐시된 리두 로그는 아직 메모리에 남아 있나요? 언제 디스크로 플러시되나요?

주로 다음과 같은 기회가 있습니다.

MySQL이 정상적으로 종료된 경우
리두 로그 버퍼에 기록된 쓰기 양이 리두 로그 버퍼 메모리 공간의 절반보다 클 경우 디스크 삭제가 트리거됩니다.
InnoDB의 백그라운드 스레드는 매초 리두 로그 버퍼를 디스크에 유지합니다.
트랜잭션이 커밋될 때마다 리두 로그 버퍼에 캐시된 리두 로그는 디스크에 직접 유지됩니다(이 전략은 아래에서 설명하는 innodb_flush_log_at_trx_commit 매개변수로 제어할 수 있습니다).

왜 binlog가 필요한가요?

앞서 소개한 undo 로그와 redo 로그는 모두 Innodb 스토리지 엔진에 의해 생성됩니다.

MySQL이 업데이트 작업을 완료하면 서버 계층에서도 binlog가 생성되며, 나중에 트랜잭션이 제출되면 트랜잭션 실행 중에 생성된 모든 binlog가 binlog 파일에 기록됩니다.

binlog 파일은 모든 데이터베이스 테이블 구조 변경 및 테이블 데이터 수정을 기록하는 로그이며, SELECT, SHOW 등의 쿼리 작업은 기록하지 않습니다.

binlog가 있는데 왜 redo 로그가 필요한가요?

이 문제는 MySQL 타임라인과 관련이 있습니다.

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

InnoDB는 플러그인 형태로 MySQL을 도입한 또 다른 회사인데, binlog에만 의존하면 충돌 방지 기능이 없기 때문에 InnoDB는 redo 로그를 사용하여 충돌 방지 기능을 구현합니다.

리두 로그와 빈 로그의 차이점은 무엇입니까?

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

1. 적용 가능한 다른 개체:

Binlog는 MySQL의 서버 계층에서 구현되는 로그이며 모든 스토리지 엔진에서 사용할 수 있습니다.
redo 로그는 Innodb 스토리지 엔진에 의해 구현된 로그입니다.

2. 다양한 파일 형식:

Binlog에는 STATEMENT(기본 형식), ROW 및 MIXED의 세 가지 형식 유형이 있으며 차이점은 다음과 같습니다.
- STATEMENT: 데이터를 수정하는 모든 SQL은 binlog에 기록됩니다(논리 작업을 기록하는 것과 동일하므로 이 형식의 경우 binlog는 논리 로그라고 부를 수 있음). 마스터-슬레이브 복제의 슬레이브 측은 이를 기반으로 이를 재생산합니다. SQL 문. 하지만 STATEMENT에는 동적 함수의 문제가 있습니다. 예를 들어 uuid 또는 now 함수를 사용하면 메인 라이브러리에서 실행한 결과가 슬레이브 라이브러리에서 실행한 결과가 아닙니다. 이러한 함수가 언제든지 변경되면 복사가 발생합니다. 데이터가 일관성이 없습니다.
- ROW: 행 데이터가 최종적으로 어떻게 수정되었는지 기록하며(이 형식의 로그는 논리 로그라고 할 수 없음) STATEMENT 아래의 동적 기능에는 문제가 없습니다. 하지만 ROW의 단점은 데이터의 각 행에 대한 변경 결과가 기록된다는 점인데, 예를 들어 배치 업데이트 문을 실행하면 데이터의 행이 업데이트되는 만큼 많은 레코드가 생성되므로 binlog 파일도 생성됩니다. STATEMENT 형식에서는 하나의 업데이트 문만 기록됩니다. ;
- MIXED: STATEMENT 및 ROW 모드가 포함되어 있으며 다양한 상황에 따라 자동으로 ROW 모드와 STATEMENT 모드를 사용합니다.
리두 로그는 XXX 테이블스페이스에 있는 YYY 데이터 페이지의 ZZZ 오프셋에 있는 AAA 업데이트와 같이 특정 데이터 페이지에 대한 수정 사항을 기록하는 물리적 로그입니다.

3. 다양한 글쓰기 방법:

Binlog는 추가 쓰기입니다. 파일이 가득 차면 새 파일이 생성되어 계속 쓰기가 됩니다. 이전 로그는 덮어쓰지 않고 전체 로그가 저장됩니다.
Redo 로그는 루프 형태로 작성되며 로그 공간의 크기는 고정되어 있으며 가득 차면 처음부터 시작하여 아직 플러시되지 않은 더티 페이지 로그를 디스크에 저장한다.

4. 다양한 용도:

binlog는 백업 및 복구, 마스터-슬레이브 복제에 사용됩니다.
재실행 로그는 정전 및 기타 오류 복구에 사용됩니다.

실수로 데이터베이스 데이터 전체를 삭제한 경우, 리두 로그 파일을 이용하여 데이터를 복구할 수 있나요?

리두 로그 파일을 사용하여 복원할 수 없으며 binlog 파일만 사용하여 복원할 수 있습니다.

Redo 로그 파일은 주기적으로 기록되기 때문에 기록하는 동안 로그는 지워지고, 디스크에 플러시되지 않은 데이터의 물리적 로그만 기록되며, 디스크에 플러시된 데이터는 리두 로그 파일에서 지워진다. .

binlog 파일은 로그 전체량, 즉 모든 데이터 변경 사항을 저장하는 파일로, 이론적으로는 binlog에 기록된 데이터만 복구할 수 있는 한, 실수로 전체 데이터베이스 데이터를 삭제한 경우에는 binlog를 사용해야 한다. 복원할 파일입니다.