-.1 Redo logging process

 
MariaDB 도 Oracle과 같이 데이터 안전을 보장하고 성능을 향상시키기 위해
커밋된 트랜잭션 내용을 먼저 로그 파일로 기록하고, 실제 데이터 파일(disk) 의 변경은 나중에 모아서 배치형태로 처리함 
=> WAL (Write Ahead Logging)
 

  1) 데이터 변경  해당 되는 페이지를 수정  Dirty 마크를 표시  (Innodb_buffer_pool)

  2) 관련 Redo log record  메모리 상의 내부적인 log 관련 memory 저장 

  3) Redo log record  Innodb_log_buffer  이동함

  4) redo log record  redo log file  Flush 함 

  5) 버퍼풀 내의 변경된 Dirty 페이지를 checkpoint  수행하여 Disk 저장함

 

 

-2. 관련 PARAMETER

 
-.Innodb_flush_log_at_trx_commit (default : 1)
 
트랜잭션의 커밋 명령이 실행될 경우 변경된 내용이 디스크에 언제 반영될지 설정하는 옵션
 
 
 
 해당 값에 따라 순간적인 장애시 트랜잭션을 잃을 수 있음
 
0 인 경우, 1초마다 log buffer의 내용들을 log file로 내려씀 . MySQL 이나 OS가 갑자기 crash 된다면 최대 1초동안의 트랜잭션을 잃을 수 있다.
1 인 경우, 커밋 발생 시 log file 로 내려쓰기 때문에 안전하나 성능이 느림
2 인 경우, 커밋 발생 시 OS buffer/cache 로 내려쓰고 1초마다 log file 로 내려씀
OS가 갑자기 crash 된다면 최대 1초동안의 트랜잭션을 잃을 수 있으나 MySQL 장애시에는 이미 OS 영역으로 데이터는 넘어갔기 때문에 안전할 수 있음
 
* sync_binlog =1 + innodb_flush_log_at_trx_commit=1 이 가장 안전함
 
 
-. innodb_max_dirty_pages_pct=0~99.999 ( default : 75)
 
버퍼 풀에서 dirgy page 를 몇 %까지 허용할 수 있을지 결정함
dirty page가 비율을 초과하면 innodb_io_capacity 파라미터로 정한 값 만큼 한번에 페이지를 flush시킴
이 값을 낮추면 좀 더 자주 dirty page 를 flush해주겠지만 버퍼 풀의 효율성이 떨어지게 되어 Disk I/O가 높아질 수도 있으나
너무 높으면 redo file이 full 나서 더 이상 로그를 기록할 수 없는 현상이 발생할 수  있음
 
-. innodb_io_capacity=100 ~ 2^64-1 (default : 200)
 
innodb_max_dirty_pages_pct 파라미터로 명시한 값 만큼 버퍼 풀 내 dirty page가 늘어나면 이 파라미터 값 만큼 한번에 페이지를 flush 시킴
 
-. innodb_log_buffer_size
 
리두 로그를 파일에 직접 기록하기 전, 메모리상에서 버퍼링을 하는데 이를 위한 버퍼 사이즈
 
-. innodb_log_files_in_group (default :2 )
 
redo log 의 갯수 
 
-. innodb_log_file_size
 
리두 로그 파일 크기로 일반적으로  innodb_buffer_pool_size/innodb_log_files_in_group 를 적정 값으로 봄