디스크 이슈

심볼릭 링크 사용하기

• 디스크 검색 (Disk seek)은 성능 저하의 중요 원인을 제공한다. 이런 문제는 효과적인 캐싱 처리가 불가능할 정도로 데이터 양이 많아지는 경우에 뚜렷하게 나타난다. 여러분이 다소 랜덤하게 대형 데이터 베이스를 접속하는 경우에는, 데이터를 읽기 위해서 최소 1번의 디스크 검색과 데이터를 쓰기 위한 두 번의 디스크 검색이 필요하다는 점을 확실히 알고 있어야 한다. 이런 문제를 최소화 하기 위해서는, 가능한 한 최소의 디스크 검색이 이루어 지도록 해야 한다.
• 서로 별개의 디스크에 대한 파일 심볼릭 링크 (symbolic link) 또는 디스크 스트라이핑 (striping)을 사용해서 사용 가능한 디스크 스핀들 (spindle)의 숫자를 늘린다:
  
  • 심볼릭 링크 사용하기
    MyISAM 테이블의 경우, 인덱스 파일과 데이터 파일이 일반적으로 저장되어 있는 데이터 디렉토리를 다른 디스크로 심볼릭 링크 시킨다. 이렇게 하면 디스크 검색 및 데이터 읽기 시간을 보다 개선 시킬 수 있다.
  • 스트라이핑
    스트라이핑이란, 여러분이 디스크를 많이 가지고 있고, 첫 번째 블럭은 첫 번째 디스크에 올려 놓고, 두 번째 블럭을 두 번째 디스크에, 세 번째는 세 번째 디스크에, 그리고 N 번째 블럭은 (N MOD 디스크 번호) 디스크에 놓는 것을 의미한다. 만일 일반적인 데이터의 크기가 스트라이프 크기보다 작다면 (또는 정확히 같다면), 보다 좋은 성능을 얻을 수가 있다. 스트라이핑은 OS 및 스트라이프 크기에 매우 밀접하기 때문에, 여러분이 사용하는 어플리케이션을 서로 다른 스트라이프 크기로 벤치 마크를 해보기 바란다. 스트라이핑의 속도 차이는 파라미터와 매우 밀접한 관련이 있다. 스트라이핑 파라미터와 디스크 숫자를 어떻게 설정하느냐에 따라서 전체적인 차이를 가지게 된다.
• 안전성을 위해서는, RAID 0+1 (스트라이핑 및 미러링 (striping plus mirroring))을 사용할 수도 있지만, 이와 같은 경우에는, 2 × N 개의 디스크 드라이브가 필요하게 된다.
• 리눅스의 경우에는 hdparm를 사용해서 디스크 인터페이스를 구성 한다면 보다 우수한 성능을 얻어낼 수가 있을 것이다. MySQL의 경우, 아래의 옵션을 사용하면 된다:
  hdparm -m 16 -d 1 이때 성능 향상과 안정성은 여러분이 사용하는 시스템의 하드웨어와 매우 밀접하게 된다.
• 여러분은 또한 데이터 베이스가 사용하는 파일 시스템용 파라미터를 설정할 수도 있다:
  만일 파일이 언제 최종적으로 접속이 되었는지 알 필요가 없다면 (실제로 데이터 베이스 서버에서는 필요 없는 사항임), 여러분이 사용하는 파일 시스템을 -o noatime 옵션을 사용해서 마운트 한다. 이렇게 하면 파일 시스템에 있는 아이노드 (inode)에 최종 접속 시간을 업데이트 하지 않게 되며, 이에 따라서 디스크 검색 시간을 절약 시킬 수가 있다. 대부분의 OS에서, 여러분은 파일 시스템을 -o async 옵션과 함께 마운트 시킴으로써 비 동기적인 업데이트가 되도록 만들 수가 있다. 이렇게 하면, 보다 개선된 성능을 얻어낼 수가 있다. (리눅스에서는 이 플래그가 디폴트임)

심볼릭 링크 사용하기

유닉스에 있는 데이터 베이스에 대한 심볼릭 링크 사용하기

유닉스에 있는 테이블에 대한 심볼릭 링크 사용하기

윈도우에 있는 데이터 베이스에 대한 심볼릭 링크 사용하기

데이터 베이스 디렉토리에 있는 테이블과 데이터 베이스는 다른 위치로 이동 시킨 후에 새로운 위치를 가리키는 심볼릭 링크로 대체 시킬 수가 있다.

이렇게 하기 위한 권장 방법은 데이터 베이스를 다른 디스크로 간단히 심링크 (symlink)시키는 것이다.

유닉스에 있는 데이터 베이스에 대한 심볼릭 링크 사용하기

유닉스에서 데이터 베이스를 심링크 시키는 방법은 우선 여유 공간이 있는 디스크에 디렉토리를 하나 만들고 MySQL 데이터 디렉토리에서 이곳으로 심링크를 생성하는 것이다.

hell> mkdir /dr1/databases/test

shell> ln -s /dr1/databases/test /path/to/datadir

MySQL은 하나의 디렉토리에서 여러 개의 데이터 베이스로 링크 시키는 것을 지원하지 않는다. 데이터 디렉토리를 하나의 심볼릭 링크로 대체 시키면 데이터 베이스 간에 심볼릭 링크를 만들지 않는 한 올바로 동작을 한다. MySQL이 데이터 디렉토리 밑에 데이터 베이스 db1 를 가지고 있다고 가정하고, 그 다음에 심링크 db2를 만들어서 db1를 가리키도록 만들어 본다:

shell> cd /path/to/datadir

shell> ln -s db1 db2

그 결과, db1 안에 뿐만 아니라, db2에도 테이블 tbl_a가 나타난다. 만일 한 클라이언트가 db1.tbl_a 를 업데이트하고 다른 클라이언트가 db2.tbl_a를 업데이트 한다면, 문제가 발생될 수 있다.

하지만, 만일 여러분이 정말로 이렇게 실행하고자 하다면, mysys/my_symlink.c의 소스 파일을 수정하면 되는데, 아래의 명령문을 잘 살펴 보기 바란다:

if (!(MyFlags & MY_RESOLVE_LINK) ||

    (!lstat(filename,&stat_buff) && S_ISLNK(stat_buff.st_mode)))

위의 것을 아래와 같이 수정한다:

if (1)

유닉스에 있는 테이블에 대한 심볼릭 링크 사용하기

realpath() 호출을 완벽하게 실행하지 못하는 시스템에서는 테이블을 심링크 시킬 수가 없다. (리눅스 및 솔라리스는 realpath()를 지원함). 여러분은 SHOW VARIABLES LIKE 'have_symlink' 명령문을 사용해서 지금 사용하고 있는 시스템이 심볼릭 링크를 지원하는지를 검사해 볼 수가 있다.

심링크는 MyISAM 테이블에 대해서만 전적으로 지원한다. 다른 스토리지 엔진을 위한 테이블이 사용하는 파일에 대해서 심볼릭 링크를 사용한다면 예상하지 못한 문제가 나올 수도 있다.

MyISAM 테이블을 위한 심볼릭 링크는 다음과 같이 처리가 된다:

• 데이터 디렉토리에서는 항상 (.frm)포맷 파일, (.MYD)데이터 파일, 그리고 (.MYI)인덱스 파일을 가지고 있다. 데이터 파일과 인덱스 파일은 다른 어떤 곳으로도 이동 시킬 수가 있고 데이터 디렉토리에서 심링크로 대체 시킬 수가 있다. 하지만, 포맷 파일은 그렇게 할 수가 없다.
• 데이터 파일과 인덱스 파일은 서로 별개의 디렉토리에 독립적으로 심링크 시킬 수가 있다.
• CREATE TABLE에 DATA DIRECTORY 및 INDEX DIRECTORY 옵션을 사용하면 구동 중인 MySQL 서버가 심링크를 실행하도록 지시할 수가 있다. 다른 방법으로는, mysqld가 구동 중이 아니라면, 명령어 라인에서 ln -s를 실행 시켜서 수동으로 심링크를 만들수도 있다.
• myisamchk는 심링크?가 없다. 이것은 심링크가 가리키고 있는 파일에서 직접 동작을 한다. 임시 파일은 데이터 파일 또는 인덱스 파일이 저장되어 있는 디렉토리 안에서 만들어진다.
• Note: 심링크를 사용하고 있는 테이블을 삭제하면, 심링크가 가리키고 있는 심링크 및 파일이 모두 삭제된다.
• 만일 ALTER TABLE ... RENAME를 사용해서 테이블 이름을 변경 시킨 후에 이것을 다른 데이터 베이스로 이동 시키지 않으면, 데이터 베이스 디렉토리에 있는 심링크는 새로운 이름으로 바뀌게 되고 데이터 파일과 인덱스 파일은 이에 따라서 이름이 바뀌게 된다.
• 만일 ALTER TABLE ... RENAME를 사용해서 테이블을 다른 데이터 베이스로 이동 시킨다면, 테이블은 다른 데이터 베이스 디렉토리로 옮겨지게 된다. 구형의 심링크와 이것이 가리키고 있는 파일들은 삭제가 된다. 달리 말하면, 새로운 테이블은 심링크가 되지 않는다.
• 여러분이 심링크를 사용하지 않는다면, --skip-symbolic-links 옵션을 mysqld에 사용해서 어느 누구도 mysqld를 사용해서 데이터 디렉토리 밖에 있는 파일의 이름을 바꾸거나 종료 시킬 수 없도록 --skip-symbolic-links 옵션을 mysqld에 사용해야 한다.

테이블 심링크 연산은 아직까지는 지원하지 않는다:

• ALTER TABLE은 DATA DIRECTORY 및 INDEX DIRECTORY 테이블 옵션을 무시한다.
• BACKUP TABLE 및 RESTORE TABLE은 심볼릭 링크를 고려하지 않는다.
• .frm 파일은 절대로 심볼릭 링크가 될 수 없다 (앞에서 설명하였듯이, 데이터 파일과 인덱스 파일만이 심볼릭 링크가 가능하다). 이를 시도하게 되면, 올바르지 못한 결과가 나온다. MySQL 데이터 베이스 밑에 데이터 베이스b1가 있고, 이 데이터 베이스 안에 테이블 tbl1이 있고, db1 디렉토리에서 tbl1를 가리키는 심링크 tbl2를 만들고자 한다고 가정하자:
  

  shell> cd /path/to/datadir/db1
  
  shell> ln -s tbl1.frm tbl2.frm
  
  shell> ln -s tbl1.MYD tbl2.MYD
  
  shell> ln -s tbl1.MYI tbl2.MYI
  
  
  
  

  하나의 쓰레드가 db1.tbl1을 읽고 다른 쓰레드가 db1.tbl2를 업데이트 한다면 문제가 발생한다:
  
  • 쿼리 캐시는 “fooled”가 된다 (쿼리 캐시는 tbl1이 업데이트 되지 않았음을 알 수 없기 때문에 이전 내용만을 리턴한다).
  • tbl2 에 있는 ALTER 명령문은 실패한다.

윈도우에 있는 데이터 베이스에 대한 심볼릭 링크 사용하기

심볼릭 링크는 모든 윈도우 서버에 대해서 디폴트로 활성화 되어 있다. 이것은 여러분이 서로 다른 디스크에 있는 데이터 베이스 디렉토리를 가져 올 수 있도록 해 준다. 이것은 유닉스에서의 데이터 베이스 심볼릭 링크가 동작하는 방식과 유사하지만, 링크 설정 과정은 다르다. 만일 심볼릭 링크가 필요 없다면, --skip-symbolic-links 옵션을 사용해서 이것을 비 활성화 시키면 된다.

윈도우에서는 목적 디렉토리 경로를 가지고 있는 데이터 디렉토리에 파일을 하나 생성함으로써 MySQL에 대한 심볼릭 링크를 만든다. 이 파일은 db_name.sym이라는 이름이 되어야 하고, 여기에서 db_name는 데이터 베이스의 이름이 된다.

MySQL 데이터 디렉토리가 C:\mysql\data이고 D:\data\foo에 데이터 베이스 foo가 있도록 한다고 가정하자. 이에 대한 심볼릭 링크는 다음과 같이 만들어 진다:

1. D:\data\foo 디렉토리가 확실히 존재하는지 다시 한번 확인하고, 없다면 생성을 한다. 만일 이 디렉토리에 이미 foo라는 이름의 데이터 베이스가 존재 한다면, 이것을 D:\data로 이동 시킨다. 그렇지 않으면, 심볼릭 링크가 효력을 갖지 못하게 된다. 데이터 베이스 디렉토리를 이동 시킬 때에는 서버가 구동되지 않도록 해야만 문제가 발생되지 않는다.
2. 경로 이름 D:\data\foo\를 가지는 텍스트 파일 C:\mysql\data\foo.sym를 생성한다.

이렇게 하면, 데이터 베이스 foo에서 생성된 모든 테이블은 D:\data\foo안에서 생성된다.