mysql - 디스크 성능과 MySQL 리플리케이션

만약에 여러분이 리플리케이션을 사용하고 있지 않다면, 현재의 시스템 성능을 개선하기 위해서는 MyISAM과 InnoDB의 성능에 대해서만 고려를 하면 된다. 이 두 가지를 제외하고 시스템의 성능을 높일 수 있는 방법은 여러 가지가 있다. 시스템을 튜닝해서 초당 1500개의 업데이트를 처리할 수 있게끔 하는 것은 쉬운 일이다. 여러분은 지금 IDE, SATA, 또는 SCSI 디스크를 한 개 사용하거나, 또는 디스크 두 개를 S/W RAID로 연결해서 사용하고 있을 것이다.

이렇게 디스크를 사용하고 있다고 한다면, 향후의 여러 가지 원인으로 인한 장애 또는 확장성을 고려해서, 여러분은 리플리케이션을 사용해야 할 필요성을 느끼게 될 것이다.
시스템의 리플리케이션을 설정하기 위해서는 우선, 마스터 서버상에서 바이너리 로깅을 활성화 시켜야 한다. 이렇게 함으로써, 데이터 베이스에서 이루어지는 모든 업데이트가 슬레이브 서버에 전달이 되어 그곳에서 실행이 되도록 할 수가 있다. 하지만, 여기에서 첫 번째 장애를 만나게 된다.

여러분이 바이너리 로깅을 활성화 시키면, 시스템의 성능은 현격하게 저하된다. 여러분이 서버를 초당 1500개의 업데이트를 처리하게끔 설정을 했다고 하더라도, 실제로는 초당 150개 정도만이 처리가 된다. 만약에 바이너리 로깅을 비활성화 시키면, 모든 것이 정상으로 처리된다. 무슨 일이 있는 것일까?

슬레이브에 리플리케이트를 하기 위해서, 그리고 일관성을 유지 하기 위해서, MySQL의 바이너리 로깅 메커니즘은 하나의 트랜젝션에 대한 바이너리 로그 “이벤트”를 실행 과정 (commit process)의 일 부분으로 기록 한다. 하나의 트랜젝션이 COMMIT 명령어에 대해서 “OK”신호를 리턴하기 전에, 해당 트랜젝션은 반드시 바이너리 로그가 있는 디스크에 로그를 해야만 한다. OS가 이것을 무시하거나 캐시에 기록을 하도록 하기 위해서는, MySQL은 이 명령어의 일부분으로 바이너리 로그상에 있는 fsync를 호출해야 한다.

시스템이 어떤 데이터를 읽으면서 동시에 쓰기를 하는 동안, 여러분이 데이터를 쓸 경우에는 서버로 하여금 디스크에 fsync를 걸도록 한다고 가정을 하면, 서버는 쓰기 동작을 실행하기 위한 디스크 검색 (seek)을 요청하게 된다. 대부분의 디스크상에서의 디스크 검색은 각각 4-8ms 정도가 걸리기 때문에, 하나의 단일 디스크에서는 평균적으로 초당 125-250개만이 실행하게 된다.

따라서, 각각의 업데이트가 바이너리 로그에 쓰여져야 하기 때문에, 바이너리 로깅을 할성화 시키게 되면 업데이트를 초당 150개 이하만 처리하게 되는 것이며, 주어진 시간 내에서 디스크가 물리적으로 처리할 수 있는 디스크 검색의 숫자에 따라서 초당 처리 속도가 제한을 받게 되는 것이다. 바이너리 로깅 메커니즘을 통한 초당 처리 속도를 향상시킬 수 있는 유일한 방법은 보다 작은 수의 디스크 검색이 이루어지도록 하는 것이다. 아래에 기술되어 있는 방법들이 이렇게 실행하기 위한 것들이다:

- unsafe syncing : sync_binlog=n 옵션을 사용할 수가 있는데, 이렇게 하
면 n >1 인 경우에는 모든 단일 트랜젝션에 대해서 fsync
를 호출하지 못하도록 만든다. 이것은 간단한 방법이기는
하지만, 만일 서버가 크래시 될 경우 (전원 문제, 커널 패
닉 등), 이미 실행된 트랜젝션 중에 n개를 잃을 가능성이
생기게 된다. 따라서, 이 방법은 일반적으로 좋은 해결책
이 되지 않는다.
- 배터리 백업 쓰기용 캐시 (battery-backed write cache (BBWC))을 사용하
는 RAID : 비록 비싸기는 하지만, 이 방법이 가장 일반적인 방법이다.
BBWC는 RAID 카드 자체에 있는 일종의 RAM으로서, 보통
128MB 정도의 용량을 가지며, 캐시 쓰기 용도로 사용된다.
RAID 카드는 RAM에 데이터가 저장되면, 디스크에 실제 쓰기
동작이 실행되기 전에 캐시에 쓰여진 것으로 인식을 한다.
- 디스크 분리 : data=journal,commit=10 옵션으로 마운트 시킨 리눅스 ext3
파일 시스템을 사용해서 바이너리 로그를 자신만의 별도 디
스크에 작성한다.
- Ramdisk journal : 바이너리 로그를 공유 디스크에 저장하지만, 별도의 볼륨
을 사용하고, 배터리 백업 하드웨어 램 디스크 디바이스를 사
용하는 리눅스 ext3 파일 시스템을 사용한다.