Mysql Redo Log 란

정의

---

Redo Log 란 DB 장애발생시 복구에 사용되는 Log 다.

 

동작원리

---

실제로 Database 에서 Commit 이 발생하면 바로 디스크 영역(Table Space)으로 들어가지 않고 메모리 영역(Buffer Poll & Log Buffer)에 들어가게 된다. 이렇게 하여 DISK I/O 를 절약할수 있다.

그런데 DB 에 장애가 발생하여서 메모리 영역에만 남아있는 데이터를 디스크 영역으로 옮겨지지 못한채 서버가 다운되는 현상이 발생했을때 복구할수 있는방법이 바로 Redo Log 이다.

복구를 한다고 해도 메모리에 있는 데이터는 전부 날아갔기 때문에 복구할수 있는 방법은 디스크에 기록된 Redo Log 파일로 복구를 해야하는데 언제 메모리에 저장되어있는 데이터를 디스크로 이동할까 ?

innodb_flush_log_at_trx_commit 설정값에 따라 언제 메모리에서 디스크로 Redo Log 가 기록 되는지 확인할수 있다.

 

innodb_flush_log_at_trx_commit

---

value	설명	장점	단점
0	Client 에서 Commit / RollBack 이실행되면 Redo log를 메모리에 기록하는것으로 끝나고 매 1초마다 메모리에서 디스크로 Redo log 를 기록한다.	디스크 I/O 요청이 줄어듬	장애 발생시 디스크 에 플러시 되지 않은 Redo Log 는 손실된다
1(default)	Client 에서 트랜잭션이 실행되면 메모리에 기록하고 Commit 시에 메모리에 있는 Redo log를 디스크로 기록한다.	데이터의 손실이 발생하지 않음	디스크 I/O 요청이 많아짐
2	Client 에서 쿼리를 실행하면 Redo log를 메모리에 기록하고 Commit 이 실행되면 O/S Buffer 로 Redo Log 가 기록된다. 매 1초마다 메모리(O/S Buffer) 에서 디스크로 Redo log 를 기록한다.	O/S 장애가 아니고 DB 만의 장애인 경우 데이터 손실없음디스크 I/O 요청이 줄어듬	O/S 장애 발생시 디스크에 기록되지 않은 Redo Log 는 손실된다

 0 과 2 옵션의 경우 DDL 변경 및 기타 내부 InnoDB 활동으로 인해 설정과 무관하게 로그가 플러시 되는 경우가 많으며 스케쥴링 문제로 인해 초당 1 회 플러시가 100% 보장 되지않는다.

 

 

Redo Log File

---

ib_logfile 이라는 파일로 저장되며 innodb_log_file_size 설정 값을 통해 파일 사이즈를 변경할수 있다.

innodb_log_files_in_group 속성값에 따라 ib_logfile 의 개수가 정해지는데 기본값/최소값은 2 이며 최대 100개 까지 정할수 있다.

[xxxx@xxxx ~]# ls -alh /data/ib_logfile* -rw-rw---- 1 mysql mysql 64M Jul 31 12:20 /data/ib_logfile0 -rw-rw---- 1 mysql mysql 64M Jul 31 12:21 /data/ib_logfile1

 

Redo Log 의 파일사이즈는 얼마가 적당할까 ?

Redo Log 의 공간을늘리면 InnoDB 가 DISK I/O 를 최적화 할수 있다. 그러나 시스템 장애가 발생하여 복구할때 시간이 길어진다.
Innodb_log_file_size 별로 복구시간을 예측하는건 하드웨어, DB버전, 워크로드에 따라 달라서 어렵다. 대략적으로 1GB 당 5분 정도가 걸린다고 한다.

 

그렇다면 RedoLog 파일의 크기를 작게하는게 좋을까 ? 

사용자가 DML 문장을 실행하면 변경된 데이터는 먼저 Redo Log에 기록되면서 디스크에 영구적으로 남게된다.
InnoDB 스토리지 엔진은 실제 테이블의 데이터를 메모리 (InnoDB Buffer Pool) 상에서만 변경하게 된다.
여기까지 완료되면 DB 서버는 클라이언트의 사용자에게 쿼리가 실행 완료 되었다고 리턴한다.

InnoDB 버퍼 풀에 변경된 데이터는 더티 페이지라고 표현하고 더티페이지를 디스크로 영구히 기록하는 작업을 Flush 라고 한다.
이런 Fulsh 작업은 크게 두가지로 나누어지는데 Redo Log 에서 다루는 영역은 2번 Flush_list 이다.

1. 버퍼 풀에서 자주 사용되지 않는 페이지들 (LRU_list) 
2. 변경된 페이지들의 목록을 시간 순서대로 관리 (Flush_list)
   

InnoDB의 Redo Log 는 여러개의 파일로 구성되지만 InnoDB 의 스토리지 엔진은 내부적으로 이 파일들을 모두 모아서 하나의 연속된 공간으로 인식한다.
이런 더티 페이지들은 Redo Log와 연결되어 있는데 Redo Log 페이지가 가득차게 되면 오래된 Redo Log 슬롯을 적절한 시점에 가장 오래된 리두 로그슬롯을 비워주어야 하는데
항상 Redo Log 가 먼저 디스크로 Flush 되고 버퍼풀 에서 더티 페이지가 디스크로 완전히 플러시 되어야만 더티페이지와 연관을 가지고 있던 로그 슬롯이 재사용 될수있다.

 

따라서 Redo Log 가 작을 경우 InnoDB 의 버퍼풀은 Flush 작업이 빈번하게 일어날 것이고 Flush 과정에서 Random Write 작업(테이블 스페이스로 영구저장) 이 발생하여 DISK I/O 부하로 이어질 것이다.

적정 크기는 ?

Mysql 공식문서를 보면 리두 로그 파일을 버퍼풀 크기만큼 크게 만들라고 한다.

 

redo 로그 파일을 버퍼 풀만큼 크게 만듭니다.
InnoDB가 redo 로그 파일을 가득 채운 경우, 버퍼 풀의 수정된 내용을 체크포인트에서 디스크에 기록해야 합니다.
redo 로그 파일이 작을 경우 불필요한 디스크 쓰기가 많이 발생합니다.
과거에는 대규모 redo 로그 파일이 복구 시간을 오래 끌었지만 이제는 복구 속도가 훨씬 빨라져 대용량 redo 로그 파일을 안심하고 사용할 수 있습니다.

• https://dev.mysql.com/doc/refman/5.7/en/optimizing-innodb-logging.html

 

WAL

---

WAL 이란 용어도 자주 등장하는데 Write Ahead Log 의 약자이다.  InnoDB 에서는 Redo Log 로 불린다.

 

Doublewrite Buffer

---

InnoDB 에서 데이터 파일의 적절한 위치에 페이지를 쓰기전에 버퍼풀에서 Flush 된 페이지를 쓰는 저장 영역이다. 페이지 쓰기 도중에 스토리지/서브시스템/mysqld 프로세스 충돌이 있는 경우에는 Redo Log 를 활용하여도 복구가 불가능하지만 Doublewrite Buffer 에서 복구 할수있다.

 

Log Buffer

---

로그 버퍼는 는 디스크의 리두 로그파일에 기록될 데이터를 보유하는 메모리 영역이다.
로그 버퍼의 크기는 innodb_log_buffer_size 변수로 설정할수 있다. (일반적으로 4MB ~ 16MB 가 좋은 크기라고 한다)
로그 버퍼크기를 크게 조정하면 트랜잭션을 커밋 하기 전에 디스크에 로그를 쓰지않아도 큰 트랜잭션을 실행할수 있다.
많은 행을 업데이트, 삽입, 삭제하는 트랜잭션이 있는 경우 로그버퍼를 크게조정하면 DISK I/O 가 절약된다.

 

 

reference

---

http://intomysql.blogspot.com/2010/12/redo-log.html

http://www.gurubee.net/lecture/4202

https://sarc.io/index.php/mariadb/1146-innodb-redo-logging-process

https://dev.mysql.com/doc/refman/5.7/en/innodb-redo-log.html

https://dev.mysql.com/doc/refman/5.7/en/innodb-doublewrite-buffer.html