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