Redo log의 디스크 기록 방식

• Redo log의 디스크 기록 방식은 크게 3가지 방법이 있으며,
  innodb_flush_log_at_trx_commit 환경 설정 변수로 조정할 수 있다.
• [innodb_flush_log_at_trx_commit=0]
  Client에서 쿼리(COMMIT, ROLLBACK까지 포함)가 실행되면, Client thread에서는 Redo log를 log buffer에 기록하는 것으로 끝나고,
  Client들의 Query와 Commit/Rollback 명령과 관계 없이 1초 간격으로 Log buffer에 기록된 내용을 Disk로 Flush 함.
  즉, Client thread는 log buffer 까지만 기록하고, 별도의 Thread가 Disk까지의 완전히 저장을 1초 단위로 실행함.
  -> 장점 : 데이터의 안전성이 보장됨
  -> 단점 : Disk 의 쓰기 요청이 많아짐 
• [innodb_flush_log_at_trx_commit=1]
  Client에서 쿼리(COMMIT, ROLLBACK 제외)가 실행되면, Client thread에서는 Redo log를 log buffer에 기록하는 것으로 끝나고
  COMMIT 또는 ROLLBACK이 실행되면, log buffer의 내용을 Disk로 쓰고 Flush를 실행함.
  즉, Client thread가 Redo log를 디스크까지 완전히 저장 후 실행이 완료됨
  -> 장점 : Disk의 쓰기 요청이 줄어듬
  -> 단점 : 장애가 발생 시, 최대로 최근 1초 분량의 데이터는 손실 될 수 있음
• [innodb_flush_log_at_trx_commit=2]
  Client thread에서 쿼리(COMMIT, ROLLBACK 제외)를 실행하면, Client thread에서 Redo log를 log buffer에 기록하고,
  COMMIT 이 실행되면, Disk로 쓰기를 Client thread에서 실행함.
  하지만 Client thread가 Flush를 실행하진 않으므로, 이 때의 Redo log는 O/S Buffer에 쌓이게 됨.
  Client들의 Query와 Commit/Rollback 명령과 관계 없이 별도의 Thread가 1초 간격으로 Disk로의 Flush를 실행 함.
  -> 장점 : Disk의 쓰기 요청이 줄어듬
  -> 단점 : O/S의 장애가 아니고, MySQL 만의 장애인 경우에는 데이터 손실이 없음
               하지만, O/S의 장애가 발생하면, 최대로 최근 1초 동안의 데이터 손실이 발생할지는 모름