데브러너 (DevRunner)

10.12.1 Optimizing Disk I/O

이 절에서는 데이터베이스 서버에 더 많고 더 빠른 스토리지 하드웨어를 할당할 수 있을 때 스토리지 디바이스를 구성하는 방법을 설명합니다. I/O 성능을 향상시키기 위한 InnoDB 구성 최적화에 대한 정보는 Section 10.5.8, “Optimizing InnoDB Disk I/O”를 참조하십시오.

디스크 시크는 매우 큰 성능 병목입니다. 이 문제는 데이터 양이 너무 커져서 효과적인 캐싱이 불가능해지기 시작하면 더욱 두드러집니다. 데이터를 대체로 임의(random)로 액세스하는 대규모 데이터베이스의 경우, 읽기에는 최소한 한 번의 디스크 시크, 쓰기에는 두어 번의 디스크 시크가 필요하다는 점을 확신할 수 있습니다. 이 문제를 최소화하려면 시크 시간이 짧은 디스크를 사용하십시오.
사용 가능한 디스크 스핀들 수를 늘려 시크 오버헤드를 줄이려면 파일을 다른 디스크로 심링크하거나 디스크를 스트라이핑하는 방법이 있습니다:
- Symbolic link 사용
  
  이는 MyISAM 테이블의 경우, 데이터 디렉터리의 일반적인 위치에 있는 인덱스 파일과 데이터 파일을 다른 디스크(또한 스트라이프 구성일 수 있음)로 심링크한다는 뜻입니다. 해당 디스크가 다른 용도로 사용되지 않는다고 가정하면, 이는 시크 시간과 읽기 시간을 모두 개선합니다. Section 10.12.2, “Using Symbolic Links”를 참조하십시오.
  
  Symbolic link는 InnoDB 테이블에서는 지원되지 않습니다. 그러나 InnoDB 데이터 파일과 로그 파일을 서로 다른 물리적 디스크에 배치하는 것은 가능합니다. 자세한 내용은 Section 10.5.8, “Optimizing InnoDB Disk I/O”를 참조하십시오.
- Striping
  
  스트라이핑은 여러 개의 디스크를 두고 첫 번째 블록은 첫 번째 디스크, 두 번째 블록은 두 번째 디스크, _N_번째 블록은 (N MOD number_of_disks) 디스크에 두는 것을 의미합니다. 즉, 일반 데이터 크기가 스트라이프 크기보다 작거나(또는 완벽히 정렬되어 있으면) 훨씬 더 나은 성능을 얻을 수 있습니다. 스트라이핑은 운영 체제 및 스트라이프 크기에 크게 의존하므로, 서로 다른 스트라이프 크기로 애플리케이션을 벤치마크해야 합니다. Section 10.13.2, “Using Your Own Benchmarks”를 참조하십시오.
  
  스트라이핑에 따른 속도 차이는 설정된 파라미터에 매우 크게 의존합니다. 스트라이핑 파라미터와 디스크 개수를 어떻게 설정하느냐에 따라 성능 차이가 몇 배 이상(orders of magnitude) 날 수 있습니다. 랜덤 액세스에 최적화할지, 순차 액세스에 최적화할지 선택해야 합니다.
신뢰성을 위해 RAID 0+1(스트라이핑과 미러링)을 사용하고 싶을 수 있지만, 이 경우 N 개의 데이터를 저장하기 위해 2 × N 개의 드라이브가 필요합니다. 비용을 감당할 수 있다면 아마도 이것이 최선의 선택일 것입니다. 그러나 이를 효율적으로 처리하려면 일부 볼륨 관리 소프트웨어에 투자해야 할 수도 있습니다.
좋은 선택지는 데이터 유형의 중요도에 따라 RAID 레벨을 달리하는 것입니다. 예를 들어, 다시 생성할 수 있는 다소 중요한(semi-important) 데이터는 RAID 0 디스크에 저장하되, 호스트 정보 및 로그와 같이 매우 중요한 데이터는 RAID 0+1 또는 RAID N 디스크에 저장합니다. RAID _N_은 패리티 비트를 업데이트하는 데 필요한 시간 때문에 쓰기가 많은 경우 문제가 될 수 있습니다.
데이터베이스가 사용하는 파일 시스템의 파라미터를 설정할 수도 있습니다:

파일이 마지막으로 액세스된 시점을 알 필요가 없다면(이는 데이터베이스 서버에서는 그다지 유용하지 않습니다), 파일 시스템을 -o noatime 옵션을 사용하여 마운트할 수 있습니다. 이는 파일 시스템의 inode에서 마지막 액세스 시간 업데이트를 건너뛰어 일부 디스크 시크를 피할 수 있습니다.

많은 운영 체제에서 파일 시스템을 -o async 옵션으로 마운트하여 비동기적으로 업데이트되도록 설정할 수 있습니다. 컴퓨터가 비교적 안정적이라면, 이 옵션은 신뢰성을 크게 훼손하지 않으면서 더 좋은 성능을 제공해야 합니다. (이 플래그는 Linux에서는 기본적으로 활성화되어 있습니다.)

Using NFS with MySQL

MySQL에서 NFS 사용을 고려할 때는 주의해야 합니다. 운영 체제와 NFS 버전에 따라 다음과 같은 잠재적인 문제가 있습니다:

NFS 볼륨에 위치한 MySQL 데이터 파일과 로그 파일이 잠겨 사용 불가능해지는 경우. 잠금 문제는 여러 MySQL 인스턴스가 동일한 데이터 디렉터리에 액세스하는 경우나, 예를 들어 정전과 같은 이유로 MySQL이 올바르지 않게 종료되는 경우 발생할 수 있습니다. NFS Version 4는 권고(advisory) 및 리스 기반(lease-based) 잠금을 도입하여 이러한 기본적인 잠금 문제를 해결합니다. 그러나 데이터 디렉터리를 여러 MySQL 인스턴스 간에 공유하는 것은 권장되지 않습니다.
순서가 바뀐 메시지 수신 또는 손실된 네트워크 트래픽으로 인해 발생하는 데이터 불일치. 이 문제를 피하려면 TCP와 hard, intr 마운트 옵션을 함께 사용하십시오.
최대 파일 크기 제한. NFS Version 2 클라이언트는 파일의 하위 2GB(부호 있는 32비트 오프셋)까지만 액세스할 수 있습니다. NFS Version 3 클라이언트는 더 큰 파일(최대 64비트 오프셋)을 지원합니다. 지원되는 최대 파일 크기는 NFS 서버의 로컬 파일 시스템에도 의존합니다.

전문적인 SAN 환경 또는 기타 스토리지 시스템 내에서 NFS를 사용할 경우, 이러한 환경 밖에서 NFS를 사용하는 것보다 일반적으로 더 높은 신뢰성을 제공합니다. 그러나 SAN 환경 내의 NFS는 직접 연결되거나 버스 연결된 비회전(non-rotational) 스토리지보다 느릴 수 있습니다.

NFS 사용을 선택하는 경우 NFS Version 4 이상을 권장하며, 프로덕션 환경에 배포하기 전에 NFS 설정을 철저히 테스트해야 합니다.