RAID 인터페이스의 WriteCache와 로그(BinaryLog 및 Redo log) 동기화

RAID 인터페이스의 WriteCache

• 일반적인 DBMS용 장비에는 여러개의 디스크가 장착되어 있고,
• 각 디스크들이 스트라이핑(RAID-0)되고 다시 미러링(RAID-1)된 형태로 구성된다(물론 그 반대도)
• 그리고, 이러한 RAID 인터페이스에는 기본적으로 Cache 메모리가 장착되어 있으며,
• 이 Cache 메모리는 쓰기용도와 읽기 용도를 구분해서 사이즈를 지정 가능하다.
• 또한, 운영체제에서는 Write-Policy를 관리하여
  Cache 메모리까지 동기화시킬지(Write-back)
  최종 디스크까지 동기화를 시킬지(Write-through) 결정
• 어떤 RAID 인터페이스는 BBU (Battery backed unit)이 장착되어 있어서
  시스템의 장애시에도 쓰기 캐시의 내용이 손상되지 않도록 한다.

Binary Log & Redo log

• Binary log와 Redo log는 모두 Sequential I/O 방식으로 기록된다.
• 하지만, Binary log를 디스크에 기록하는 방식인 sync_binlog와
• Redo log를 디스크에 기록하는 방식인 innodb_flush_log_at_trx_commit가 동기화 방식으로 설정되면,
• InnoDB의 Commit 단위 또는 MyISAM의 쿼리 실행 단위로 디스크 쓰기 요청을 발생시키게 된다.

테스트 결과

• InnoDB의 redo log를 대상으로 테스트 해보지 못했고, MyISAM의 binary log를 대상으로 테스트
• 하지만, InnoDB의 redo log도 크게 다르지 않을 것으로 예상됨
• 아래 3가지 상황으로 IO 상태를 모니터링해 보았다
  (이 장비에는 디스크는 1개, RAID 인터페이스가 없고 Write cache도 없다)
  (또한 이 장비에서는 초당 SELECT - 100건, INSERT - 50건, UPDATE - 20건 정도의 부하가 있었음)
  - A) BinaryLog (활성) + sync_binlog (1, 동기화)
  - B) BinaryLog (활성) + sync_binlog (0, 비동기화)
  - C) BinaryLog (비활성)
• 각 상황별 테스트 결과를 보면
  - B)와 C)의 경우, 거의 비슷한 결과를 보여주면서 양호하게 처리하고 있지만,
  - A)의 경우에는 Write request 회수도 상당히 높아지고 처리 시간도 상당히 소요되는 것을 알 수 있다.
  - 실제 Application에서는 A)의 경우에는 상당한 Slow Query가 발생하고 있었다.
•  

결론적으로

• DBMS용도의 장비라면 최소 2~3개 이상의 디스크에 Cache 메모리를 가진 
  RAID 인터페이스가 상당히 효과적으로 I/O를 개선해줌을 알 수 있다.
• 만약, 비용적인 이유로 RAID와 Cache메모리 장착이 어렵다면 Binary log또는 Redo log의 
  동기화 옵션을 비활성화 시키는 것을 추천한다 
  (물론, 1~2초 정도의 데이터 손실을 감안할 수 있다면) 
  이로 인해서 얻을 수 있는 것과 잃을 수 있는 것은 상당히 클 것으로 보인다.
• 또한, 일반적으로 MySQL 에서는 RAID의 Cache 메모리를 Read 보다는 
  Write를 위한 Cache로 집중 할당하는 것이  효과적일 것으로 생각한다.