2010년 12월 26일 일요일

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로 집중 할당하는 것이  효과적일 것으로 생각한다.






댓글 없음:

댓글 쓰기