20130829

Mysql InnoDB Start-up (Options)

이 섹션에서는 InnoDB-관련 명령어 옵션과 시스템 변수에 대해서 설명을 하기로 한다서버 스타트업 시점에 이 변수들을 명기함으로써 트루 또는 팰스 (true or false)인 시스템 변수를 활성화 시키거나또는 skip- 접두어를 사용해서 비활성화 시킨다예를 들면InnoDB 체크섬을 활성화 또는 비활성화 시키기 위해서는명령어 라인에서 --innodb_checksums 또는 --skip-innodb_checksums 를 사용하거나옵션 파일에서 innodb_checksums 또는 skip-innodb_checksums를 사용한다수치 값을 가지는 시스템 변수는 명령어 라인에서 --var_name=value 형태를 사용하거나 또는 옵션 파일에서 var_name=value와 같이 사용하면 된다옵션 및 시스템 변수를 지정하는 것에 대한 보다 많은 정보는 Section 4.3, “Specifying Program Options”를 참고하기 바란다대부분의 시스템 변수는 런타임 시점에 변경시킬 수가 있다 (Section 5.2.4.2, “Dynamic System Variables”를 참조).
InnoDB 명령어 옵션:
  • --innodb
서버가 InnoDB를 지원하도록 컴파일 되어 있다며InnoDB 스토리지 엔진을 활성화 시킨다.  --skip-innodb를 사용하면 InnoDB를 비활성화 시킬 수가 있다.
  • --innodb_status_file
InnoDB로 하여금 MySQL 데이터 디렉토리에 /innodb_status.라는 이름의 파일을 생성하도록 한다InnoDB는 주기적으로 SHOW ENGINE INNODB STATUS의 결과를 이 파일에 작성한다.

InnoDB 시스템 변수:
  • innodb_additional_mem_pool_size
InnoDB가 데이터 디렉토리 정보와 다른 내부 데이터 구조를 저장하기 위해 사용하는 메모리 풀의 크기 (바이트 단위). 여러분이 어플리케이션에서 테이블을 많이 가질수록,여기에 할당해야 하는 메모리가 많이 필요하게 된다만일 InnoDB가 이 풀에 있는 메모리를 다 사용하게 되면이 엔진은 OS가 사용하는 메모리를 할당하기 시작하고, MySQL 에러 로그에 경고 메시지를 작성한다디폴트 값은 1MB가 된다.
  • innodb_autoextend_increment
테이블스페이스가 가득 차게 되었을 때 자동-확장 테이블스페이스의 확장 크기 (MB단위). 디폴트는 8MB가 된다.
  • innodb_buffer_pool_awe_mem_mb
이 엔진이 AWE 메모리에 있을 경우의 버퍼 풀의 크기이 변수는 32-비트 윈도우 시스템에만 적용된다만일 여러분이 사용하는 32-비트 윈도우 시스템이 4GB 이상의 메모리를 지원한다면소위 “Address Windowing Extensions”을 사용해서 InnoDB 버퍼 풀을 AWE 메모리에 할당할 수가 있다이 변수의 최대 가능 값은 63000이다만일 이 값이 0보다 크다면innodb_buffer_pool_size는 InnoDB 가 AWE 메모리에 매핑되어 있는 mysqld 32-비트 주소 스페이스에 있는 윈도우가 된다.innodb_buffer_pool_size의 가장 좋은 크기는 500MB이다.

AWE 메모리의 장점을 살리기 위해서는여러분 스스로 MySQL을 컴파일 할 필요가 있다이렇게 하기 위해 필요한 설정은 innobase/os/os0proj.c 소스 파일에서 찾아볼 수가 있다.
  • innodb_buffer_pool_size
InnoDB가 자신의 테이블에 있는 데이터와 인덱스를 캐시하기 위해 사용하는 메모리 버퍼의 크기 (바이트 단위). 이 값을 크게 설정하면 할수록테이블에 있는 데이터를 접속하는데 필요한 I/O가 덜 생긴다지정된 데이터베이스 서버에서는이 값으로 메인 메모리의 80%까지를 설정할 수가 있다하지만이 값을 너무 크게 설정하게 되면 OS와 메인 메모리 할당 경쟁이 생기기 때문에 적절하게 설정하는 좋다.
  • innodb_checksums
InnoDB는 하드웨어 또는 데이터 파일의 오류에 대한 여분의 폴트 톨로런스 (fault-tolerance)를 보장하기 위해 디스크에서 읽는 모든 페이지에 대해서 체크섬 확인을 사용할 수 있다이러한 확인은 디폴트로 활성화 되어진다하지만거의 드문 경우지만 어떤 환경 (벤치마크를 구동 중에 있는 경우)하에서는 이러한 기능이 불필요할 수도 있으며이럴 경우에는 --skip-innodb_checksums를 사용해서 비활성화를 시킨다이 변수는 MySQL 5.0.3에서 추가되었다.
  • innodb_commit_concurrency
동시에 실행되는 쓰레드의 숫자이 값이 0이 되면 동시성 제어 (concurrency control)가 비활성화 된다이 변수는 MySQL 5.0.12에서 추가되었다.
  • innodb_concurrency_tickets
InnoDB에 동시에 들어갈 수 있는 쓰레드의 숫자는 innodb_thread_concurrency변수로 알아볼 수가 있다여러 개의 쓰레드가 이미 컨커런시 한계에 도달하였다면하나의 쓰레드만이 큐에 들어갈 수 있다하나이 쓰레드가 InnoDB에 들어가게 되면,innodb_concurrency_tickets의 값과 일치하는 자유 티켓의 숫자가 주어지고,쓰레드가 자신의 티켓을 사용하기 전 까지는 자유롭게 InnoDB에 들어가고 나올 수가 있다이런 후에는쓰레드는 다시금 일관성 검사를 하고 InnoDB에 다시 들어가려고 시도하게 된다이 변수는 MySQL 5.0.3에 추가되었다.
  • innodb_data_file_path
개별적인 데이터 파일의 경로와 크기각각의 데이터 파일에 대한 전체 경로는 여기에서 지정된 경로에 innodb_data_home_dir를 연결해서 구성된다파일의 크기는MB 또는 GB (1024MB)이며M 또는 G를 붙인다파일 크기의 합은 최소 10MB이상이어야 한다만일 innodb_data_file_path를 지정하지 않는다면디폴트로 10MB 크기의 자동-확장 데이터 파일을 ibdata1라는 이름으로 하나 만들게 된다개별 파일의 크기 한계는 여러분이 사용하는 OS에 따라서 다르다대형 파일을 지원하는 OS에서는4GB 이상의 파일도 만들 수가 있다또한로우 디스크 파티션을 데이터 파일 형태로 사용할 수도 있다. Section 14.2.3.2, “공유 테이블스페이스에 대해서 로우 (Row) 디바이스 사용하기를 참조할 것.
  • innodb_data_home_dir
모든 InnoDB 데이터 파일에 대한 디렉토리 경로의 공통 부분이 값을 설정하지 않게 되면디폴트는 MySQL 데이터 디렉토리가 된다빈 스트링을 가지고 이 값을 설정할 수도 있는데이렇게 되면여러분은 innodb_data_file_path에 있는 절대 경로를 사용할 수가 있다.
  • innodb_doublewrite
디폴트로는InnoDB은 모든 데이터를 두 번 저장하는데처음에는 이중 쓰기 버퍼(doublewrite buffer)에 저장하고다음에는 실제 데이터 파일에 저장한다이 변수는 디폴트로 활성화된다벤치 마크 테스트를 하거나 또는 최고의 성능이 필요한 경우에는 --skip-innodb_doublewrite를 사용해서 이 변수를 비활성화 시킬 수 있다이 변수는 MySQL 5.0.3에서 추가되었다.
  • innodb_fast_shutdown
만일 이 변수를 0으로 설정하면InnoDB는 셧다운을 하기 전에 전체 퍼지 (full purge)와 삽입 버퍼 병합 (insert buffer merge)를 실행한다이러한 연산들은 몇 분의 시간이 걸리거나극단적인 경우에는 몇 시간이 걸릴 수도 있다만일 이 변수를 1로 설정하면,InnoDB는 셧 다운 시점이 이러한 연산들을 건너 띄게 된다이 변수의 디폴트 값은 1이다만일 여러분이 이 변수를 2로 설정한다면InnoDB는 마치 MySQL이 크래시 된 것처럼 자신의 로그만을 플러시 하고 셧 다운은 진행하지 않는다실행되지 않은 트랜젝션은 잃어 버리게 되지만서버를 재 스타트업 시키면 크래시 복구는 실행된다이러한 값 2는 MySQL 5.0.5 이후에 사용되었으며, NetWare에서는 사용할 수 없다.
  • innodb_file_io_threads
InnoDB에서의 파일 I/O 쓰레드의 숫자일반적으로이 변수는 디폴트로 4를 갖게 되지만윈도우에서는 이 숫자를 늘려 줌으로써 디스크 I/O가 좋아질 수가 있다유닉스에서는이 숫자를 늘려도 별 효과가 발생하지 않는다InnoDB는 항상 디폴트 숫자만을 사용한다.
  • innodb_file_per_table
이 변수가 활성화 되어 있다면InnoDB는 데이터 및 인덱스를 공유 테이블스페이스를 이용하는 대신에 자신의 .ibd 파일을 사용해서 새로운 파일을 생성한다디폴트는 공유 테이블스페이스에 테이블을 생성하는 것이다. Section 14.2.3.1, “테이블  테이블스페이스 사용하기를 참조할 것.
  • innodb_flush_log_at_trx_commit
innodb_flush_log_at_trx_commit 0으로 설정되면로그 버퍼는 초 당 한번씩 로그 파일이 기록이 되고 디스크 연산에 대한 플러시는 로그 파일에서 실행되지만트랜젝션 실행 시점에는 아무것도 실행되지 않게 된다이 값이 1 (디폴트)로 설정되면,로그 버퍼는 각 트랜젝션이 실행될 때마다 로그 파일에 기록되고 로그 파일에서 디스크 연산에 대한 플러시가 실행된다. 2로 설정되면로그 버퍼는 각 실행 시점마다 파일로 기록되지만디스크 연산에 대한 플러시는 실행되지 않는다하지만로그 파일에 대한 플러시는 값이 2일 때에도 초당 한번씩 실행된다초당 1회의 플러시는 모든 초당 이루어진다고는 장담할 수가 없는데그 이유는 프로세스 스케쥴링 문제 때문이라는 점을 알아두자.

이 변수의 디폴트 값은 1이며이 값은 ACID와의 호환성을 위해 요구되는 값이다여러분은 이 값을 1 이외의 값으로 설정해서 보다 좋은 성능을 얻을 수는 있겠지만크래시가 나게 되면 한 순간에 모든 것을 잃어 버릴 수도 있다만일 이 값을 0으로 설정한다면어떠한 mysqld 프로세스 크래시라도만일 이 값을 2로 설정한다면, OS 크래시 또는 전원 불량을 통해서만 마지막 초 순간의 트랜젝션이 지워지게 된다하지만,InnoDB의 크래시 복구는 영향을 받지 않으며 따라서 크래시 복구는 변수 값에 상관없이 실행된다대다수의 OS와 몇몇 디스크들은 디스크에 대한 플러시 연산을 제대로 실행하지 못한다는 점을 알아두자.

Note: 트랜젝션을 사용하는 InnoDB을 이용한 리플리케이션 설정에서 내구성과 일관성을 최대로 확보하기 위해서는여러분이 사용하는 마스터 서버의 my.cnf 파일에서innodb_flush_log_at_trx_commit=1sync_binlog=1innodb_safe_binlog(MySQL 5.0.3 이전 버전의 경우)를 사용해야 한다. (innodb_safe_binlog 5.0.3이후에는 필요가 없다.)
  • innodb_flush_method
만일 fdatasync (디폴트)를 설정하면InnoDB는 fsync()를 사용해서 데이터와 로그 파일을 플러시한다만일 O_DSYNC를 설정하면InnoDB는 O_SYNC를 사용해서 로그 파일을 열고 플러시하지만데이터 파일을 플러시하기 위해서는 fsync()를 사용하게 된다만일 O_DIRECT 가 지정된다면 (몇몇 GNU/Linux 버전에서 사용 가능함), InnoDB는 O_DIRECT를 사용해서 데이터 파일을 열고데이터 파일과 로그 파일을 플러시하기 위해 fsync()를 사용한다InnoDB는 fsync()를 fdatasync()대신에 사용하고대부분의 유닉스에서 O_DSYNC를 사용하는 것이 문제가 있기 때문에 이것을 디폴트로 사용하지 않는다는 점을 알아두자이 변수는 유닉스에만 연관이 되는 변수이다윈도우의 경우플러시 방식은 항상 async_unbuffered이며 이것을 변경할 수는 없다.

이 변수가 다른 값을 가지게 되면 InnoDB performance에 상당한 영향을 미치게 된다예를 들면InnoDB 데이터와 로그 파일이 SAN에 존재하는 시스템에서는,innodb_flush_method를 O_DIRECT에 설정하면 단일 SELECT 명령문의 성능을 저하시키게 된다.
  • innodb_force_recovery
크래시 복구 모드.
Warning: 여러분이 깨져있는 데이터 베이스에서 테이블을 덤프 하고자 하는 위급한 상황에서만 이 변수를 0보다 크게 설정해야 한다이 변수가 취할 수 있는 값은 1에서 6이다각 변수의 값이 의미하는 것은 Section 14.2.8.1, “Forcing InnoDB Recovery”에서 설명하고 있다보다 안전성을 제공하기 위해서InnoDB는 이 변수가 0보다 큰 경우에는 자신의 데이터를 변경하지 못하게 끔 하고 있다.
  • innodb_lock_wait_timeout
InnoDB 트랜젝션의 타임아웃은 롤백이 진행되기 전에 락을 대기하는 시간이다.InnoDB 는 자동으로 자신의 락 테이블에 있는 트랜젝션 데드락 (deadlock)를 검사하고 트랜젝션을 롤 백 한다InnoDB는 LOCK TABLES 명령문을 사용해서 락 세트를 알려준다디폴트는 50초이다.
  • innodb_locks_unsafe_for_binlog
이 변수는 InnoDB 검색과 인덱스 스캔에서 다음- (next-key) 락킹을 제어한다디폴트로는, 0으로 설정 되는데 (비활성화), 이것은 다음-키 락킹이 활성화 됨을 의미한다.

보통의 경우InnoDB는 next-key locking”이라는 알고리즘을 사용한다InnoDB는 테이블 인덱스를 검색 또는 스캔을 하는 시점에 이 알고리즘을 이용해서 하위-레벨 락킹을 실행하는데이렇게 되면 자신이 직면하는 모든 인덱스 레코그에서 공유 또는 배타적인 락을 설정하게 된다따라서하위-레벨 락은 실제로 인덱스 레코트 락이 된다. The locks that InnoDB가 인덱스 레코드에 설정하는 락은 인덱스 레코드보다 앞에 있는  (gap)”에도 영향을 준다만일 사용자가 공유 또는 배타적인 락을 인덱스의 레코드 R 에 가지고 있다면다른 사용자는 새로운 인덱스 레코드를 R 앞에 삽입할 수 없게 된다이 변수를 활성화 시키게 되면 InnoDB는 검색 또는 인덱스 스캔에서 다음-키 락킹을 사용할 수 없게 된다다음-키 락킹은 외래-키 제약과 이중 키 검사를 확인하는데 사용할 수 있다이 변수를 활성화 시키면 팬텀 (phantom) 문제가 발생할 수도 있음을 알아두자여러분이 나중에 선택된 열에 있는 몇몇 컬럼을 업데이트 하고자 하는 의도를 가지고, 100보다 큰 식별자 값을 사용해서 child 테이블에서 모든 칠드런(children)을 읽고 락을 하기 원한다고 가정하자:

SELECT * FROM child WHERE id > 100 FOR UPDATE;

id 컬럼에 인덱스가 존재한다고 가정한다쿼리는 id 100보다 큰 첫 번째 레코드부터 인덱스를 스캔한다만일 인덱스 레코드에 설정되어 있는 락이 갭에 만들어져 있는 삽입의 락을 풀지 못한다면다른 클라이언트는 새로운 열을 테이블 안에 삽입할 수 있게 된다만일 동일한 트랜젝션 안에서 같은 SELECT를 실행한다면여러분은 쿼리가 리턴하는 결과에서 새로운 열을 볼 수가 있다이것은만일 새로운 아이템이 데이터베이스에 추가될 경우InnoDB는 “serializability”를 보장하지 않는다는 것을 의미하는 것이다따라서만일 이 변수가 활성화 되어 있다면InnoDB는 READ COMMITTED를 보장하게 된다. (“serializability” 충돌을 보장한다.)

MySQL 5.0.2 버전 이후로는이 옵션은 덜 안전한 기능을 제공하게 된다UPDATE또는 DELETE에 있는 InnoDB는 업데이트 또는 삭제를 하는 열만을 잠근다이를 통해서 데드락의 가능성은 많이 감소하기는 하지만아주 없어진 것은 아니다이 변수를 활성화 시킨다고 하더라도 UPDATE 과 같은 연산이 다른 열에 영향을 주는 경우조차도 다른 유사한 연산 (UPDATE과 같은 연산)을 앞지르지는 못한다는 점을 알아두자.:

CREATE TABLE A(A INT NOT NULL, B INT) ENGINE = InnoDB;
INSERT INTO A VALUES (1,2),(2,3),(3,2),(4,3),(5,2);
COMMIT; 

클라이언트 하나가 아래의 명령문을 실행한다고 가정하자:

SET AUTOCOMMIT = 0;
UPDATE A SET B = 5 WHERE B = 3; 

그런 다음에는다른 클라이언트가 첫 번째 클라이언트의 명령문 다음에 나오는 아래의 명령문을 실행한다고 가정하자:

SET AUTOCOMMIT = 0;
UPDATE A SET B = 4 WHERE B = 2; 

이와 같은 경우두 번째 UPDATE는 반드시 첫 번째 UPDATE의 실행 또는 롤백을 기다려야 한다첫 번째 UPDATE는 열 (2,3)에 배타적인 락을 가지고 있기 때문에두 번째 UPDATE이 열들을 스캐닝할 때 동일한 열에 대해서 배타적인 락을 획득하고자 시도하지만 성공하지는 못한다이것은두 번째 UPDATE가 우선 열에 대해서 배타적인 락을 획득하고 난 다음에 그 열이 결과 셋에 포함되어 있는지를 확인하기 때문이다.만일 속해 있지 않다면필요 없는 락을 풀게 되고그 때에innodb_locks_unsafe_for_binlog 변수가 활성화가 된다.

따라서InnoDB는 첫 번째 UPDATE를 아래와 같이 실행한다:

x-lock(1,2)
unlock(1,2)
x-lock(2,3)
update(2,3) to (2,5)
x-lock(3,2)
unlock(3,2)
x-lock(4,3)
update(4,3) to (4,5)
x-lock(5,2)
unlock(5,2)

InnoDB는 두 번째 UPDATE를 아래와 같이 실행한다:

x-lock(1,2)
update(1,2) to (1,4)
x-lock(2,3) - wait for query one to commit or rollback
  • innodb_log_archive
InnoDB 아카이브 파일을 로그할지를 결정이 변수는 여러 가지 이유로 존재하기는 하지만 더 이상 쓰여지지는 않는 변수다디폴트 값은 0이다.
  • innodb_log_buffer_size
InnoDB가 로그 파일을 디스크에 쓰기 위해 사용하는 버퍼의 크기 (바이트). 사용 가능한 크기는 1MB 에서 8MB이다디폴트는1MB. 로그 버퍼가 크면 트랜젝션을 실행하기 전에 로그를 디스크에 쓰지 않고서도 대형 트랜젝션을 처리할 수가 있게 된다따라서만일 여러분이 대형 트랜젝션을 가지고 있다면로그 버퍼를 크게 해서 디스크 I/O를 절감하도록 한다.
  • innodb_log_file_size
로그 그룹에 있는 각 로그의 크기 (바이트). 로그 파일의 조합 크기는 32-비트 컴퓨터에서는 4GB보다 작아야 한다디폴트는 5MB. 사용 가능한 크기의 범위는 1MB 에서 버퍼 풀의 1/N-th까지 이며여기에서 N 은 그룹에 있는 로그 파일의 수가 된다이 값이 클수록버퍼 풀에서 체크포인트 플러시 동작이 덜 필요하게 되며디스크 I/O를 줄여주게 된다하지만 로그 파일이 크게 되면크래시 발생시의 복구가 그 만큼 느려지게 된다.
  • innodb_log_files_in_group
로그 그룹의 로그 파일의 숫자InnoDB는 원형 방식 (circular fashion)으로 파일을 기록한다디폴트는 (권장 값) 2.
  • innodb_log_group_home_dir
InnoDB 로그 파일에 대한 디렉토리 경로만일 어떠한 InnoDB 로그 변수도 지정하지 않는다면디폴트로 ib_logfile0 및 ib_logfile1라는 이름의 5MB 파일 두 개를MySQL 데이터 디렉토리에 생성한다.
  • innodb_max_dirty_pages_pct
0에서 100 사이의 정수가 된다디폴트는 90. InnoDB의 메인 쓰레드는 아직 기록되지 않은 페이지의 퍼센트가 이 값을 초과하지 않게 하기 위해 버퍼 풀에 있는 페이지를 기록하고자 시도한다.
  • innodb_max_purge_lag
이 변수는 퍼지 연산 (purge operation)이 래깅 (lagging)될 때 INSERTUPDATE및 DELETE 연산을 지연 시키는 방법을 제어한다 (Section 14.2.12, “다중-버전 구현을 참조). 이 변수의 디폴트 값은0이며이것은 아무런 지연도 없음을 의미한다.

InnoDB 트랜젝션 시스템은 UPDATE 또는 DELETE 연산에 의한 삭제-표시된 인덱스 레코드를 가지고 있는 트랜젝션 리스트를 관리한다이 리스트의 길이는 purge_lag가 되도록 한다purge_lag 가 innodb_max_purge_lag를 초과하게 되면INSERTUPDATE 및 DELETE 연산은((purge_lag/innodb_max_purge_lag)×10)–5 밀리 초 만큼 지연된다이러한 지연 시간은 퍼지 배치가 시작되는 시점에매 초마다 계산된다퍼지될 열을 볼 수 있는 이전의 상수 읽기 뷰 (old consistent read view)로 인해 퍼지가 실행되지 않으면 연산은 지연되지 않는다.

문제가 있는 워크로드에 대한 전형적인 설정은 백만분의 1초 이며트랜젝션이 작고,크기가 100바이트 정도이며테이블에는 100MB의 퍼지되지 않은 열만 허용할 수 있다는 가정을 한다.
  • innodb_mirrored_log_groups
데이터베이스용으로 보관하기 위한 로그 그룹의 동일한 복사본의 숫자현재 버전까지는이것은 1로 설정해야 한다.
  • innodb_open_files
이것은 InnoDB에 다중의 테이블스페이스를 사용하는 경우에만 관련이 있는 변수이다이 변수의 값은 InnoDB가 한번에 열어 둘 수 있는 .ibd 파일의 최대 숫자를 지정한다최소 값은 10. 디폴트는 300.
.ibd 파일용으로 사용되는 파일 설명자 (descriptor)는 InnoDB만을 위한 것이다이러한 설명자는 --open-files-limit 서버 옵션에 의해 지정되는 것들과는 별개의 것들이며,테이블 캐시의 연산에는 영향을 주지 않는다.
  • innodb_safe_binlog
InnoDB 테이블과 바이너리 로그의 내용물 사이에 일관성 보장을 추가한다. Section 5.12.3, “The Binary Log”를 참조할 것이 변수는 MySQL 5.0.3부터는 삭제되었다.
  • innodb_support_xa
ON 또는 1 (디폴트 임)로 설정되면이 변수는 트랜젝션의 2-단계 실행 (two-phase commit)을 지원하도록 InnoDB를 활성화 시킨다innodb_support_xa를 활성화 시키면 트랜젝션 준비 (transaction preparation)를 위한 여분의 디스크 플러시가 발생한다만일 여러분이 XA를 사용하는 것에 신경을 쓰지 않는다면디스크 플러시의 숫자를 줄이고 InnoDB 의 성능을 좋게 하기 위해서 이 변수를 0 또는 OFF로 설정하면 된다이 변수는 MySQL 5.0.3에서 추가되었다.
  • innodb_sync_spin_loops
쓰레드가 지연되기 전에 (suspended) 풀어 주기 위해 InnoDB 뮤텍스 (mutex)를 기다리는 쓰레드의 대기 시간이 변수는 MySQL 5.0.3에서 추가되었다.
  • innodb_table_locks
만일 AUTOCOMMIT=0라면InnoDB는 LOCK TABLES를 존중하게 된다; MySQL은 다른 모든 쓰레드가 테이블에 대한 자신들의 모든 락을 풀기 전까지는LOCK TABLE .. WRITE에서 리턴을 하지 않는다innodb_table_locks의 디폴트 값은1이며이렇게 되면 LOCK TABLES은 AUTOCOMMIT=0경우에, InnoDB로 하여금 내부적으로 테이블을 잠그도록 한다.
  • innodb_thread_concurrency
InnoDB는 이 변수가 주는 한계와 동등하거나 작게 InnoDB 내부에 OS 쓰레드의 숫자를 유지하고자 한다만일 성능상의 문제가 있다면그리고 SHOW ENGINE INNODB STATUS 가 세마포어를 기다리는 많은 수의 쓰레드를 내 보낸다면쓰레드 “thrashing”을 가지고 있는 것이며이 변수를 보다 작게 또는 보다 크게 설정해 보아야 한다만일 여러분이 사용하는 컴퓨터가 많은 수의 CPU와 디스크를 가지고 있는 것이라면컴퓨터의 자원을 보다 많이 사용할 수 있도록 이 값을 높게 설정하도록 한다권장하는 값은 여러분이 사용하는 시스템의 프로세스와 디스크의 전체 합이다.
이 변수의 범위는 0에서 100까지이다. MySQL 5.0.19 이전에는 20보다 크거나 같게 되면 무한 일관성 (infinite concurrency)으로 해석이 되었다. 5.0.19 버전 이후에는, 0을 무한으로 해석한다무한이라는 의미는 일관성 검사가 비활성화 되고 뮤텍스 (mutex)를 획득하고 풀기 위한 오버헤드를 제거된다는 것을 의미한다.

디폴트 값은 여러 번 변경되었다: MySQL 5.0.8 이전에는 8 이었으며, 5.0.8 에서5.0.18까지는 20 (infinite), 5.0.19 에서 5.0.20까지는 0 (infinite), 그리고 5.0.21이후에는8 (finite)이다.
  • innodb_thread_sleep_delay
InnoDB 큐를 조이닝 (joining)하기 전에 InnoDB 쓰레드가 일시 정지 (sleep)하는 시간마이크로 초디폴트는 10,000. 0은 일시 정지를 비활성화 시킨다이 변수는MySQL 5.0.3에 추가되었다.
  • sync_binlog
만일 이 변수의 값이 양수 (positive)라면, MySQL 서버는 모든 sync_binlog 가 자신의 바이너리 로그를 기록한 후에 그 바이너리 로그를 디스크에 동기화 시킨다(fdatasync()).자동 실행 모드 (autocommit mode)에서는 명령문 당 한 번씩 바이너리 로그를 기록하고그렇지 않은 경우에는 매 트랜젝션 별로 한 번씩 기록한다는 점을 알아두자디폴트 값은 0 이며이것은 디스크에 동기화를 시키지 않는다. 1의 값을 선택하는 것이 안전한데그 이유는 크래시가 발생할 경우에는 바이너리 로그에서 하나의 명령문/트랜젝션을 잃어버리게 되기 때문이다하지만이 값을 선택하면 성능이 덜 나오게 된다 (디스크가 배터리-백업 캐시를 가지고 있지 않는 한).


댓글 없음:

Articles