'InnoDB'에 해당되는 글 5건

  1. 2010.02.04 MySQL Innodb ZFS 베스트 프랙티스
  2. 2008.12.29 MySQL Foreign Key (외래키) 사용하기 (1)
  3. 2008.12.17 MySQL InnoDB 스토리지 엔진
2010. 2. 4. 21:12

MySQL Innodb ZFS 베스트 프랙티스

NEELAKANTH NADGIR, 2009년 5월 26일  

ZFS 상에서 실행되는 MySQL 퍼포먼스를 얘기할 때 가장 멋진 것은 거의 튜닝할 부분이 없다는 것입니다. 보통 ZFS 를 튜닝 하는 것은 악으로 간주 됩니다. 그러나 종종 필요할 때도 있습니다. 이 글에서는 ZFS 에서 좀 더 좋은 퍼포먼스를 이끌어 낼수 있는 튜닝 포인트와 몇가지 퍼포먼스 버그들에 대해 지적할 것입니다. 이러한 버그들은 수정이 이루어 졌을때 제시해 드린 튜닝은 필요 없어질 것입니다.

참을성이 부족한 분들을 위해서 요약본을 먼저 제시해 드립니다. 이러한 권고사항과 관련된 이유들은 아래에서 확인하시기 바랍니다.

  1. ZFS recordsize 를 이노디비 페이지 사이즈와 일치 시킵니다 (이노디비 데이타파일들은 16KB, 로그파일들은 128KB)
  2. 만약 쓰기 작업이 많은 워크로드라면, Separated ZFS Intent Log 를 유지 합니다.
  3. 만약 데이타베이스 워킹 셋 사이즈가 메모리에 맞지 않는다면, SSD 를 L2ARC 로 사용함으로써 큰 이득을 얻으실 수 있습니다.
  4. 배터리에 의해 백업되는 캐시를 가진 스토리지 디바이스를 사용하거나 ZFS 를 다른 파일 시스템들과 비교할때 캐시 flush 를 끕니다.
  5. ZFS Adaptive replacement cache(ARC) 대신에 MySQL/이노디비 캐시를 사용합니다.
  6. ZFS prefetch 를 끕니다.
  7. 이노디비 double write buffer 를 끕니다.

각각의 항목을 자세히 살펴 봅시다.

What ZFS recordsize 를 이노디비 페이지 사이즈와 일치 시킵니다 (이노디비 데이타파일들은 16KB, 로그파일들은 128KB)
How zfs set recordsize=16k tank/db
Why

퍼포먼스의 가장 큰 이득은 ZFS 레코드 사이즈를 IO 의 사이즈와 일치 시킴으로써 얻을 수 있습니다. 이노디비 Page 는 16KB 이고 대부분의 읽기 IO 가 16KB 사이즈 (몇몇 합쳐질 수 있는 prefetch IO 를 제외한) 이기 때문입니다. ZFS 의 기본 레코드 사이즈는 128KB. 입니다. 읽기 사이즈와 ZFS 레코드 사이즈의 불일치는 심한 IO 를 유발할 수 있습니다. 만약 16KB 읽기 작업을 수행하고 해당 데이타가 ARC 에 아직 존재하지 않는다면 데이틀 얻기 위해서 128KB 를 읽어야 합니다. ZFS 는 작은 읽기 작업을 수행할 수 없습니다. 왜냐하면 체크섬이 전체 블럭에 의해서 계산되기 때문에 데이타의 무결성을 검증하기 위해서 모두 읽어 들여야 합니다. IO 사이즈와 ZFS 레코드 사이즈를 일치 시키는 또 다른 이유는 읽기-수정-쓰기 패널티 때문입니다. ZFS 레코드 사이즈가 128KB 이고 이노디비가 페이지를 수정할때, 만약 ZFS 레코드가 아직 메모리에 존재하지 않는다면 해당 데이타는 디스크로 부터 읽어져야 하고 디스크에 쓰기 전에 수정되어야 합니다. 이것은 IO 레이턴시를 크게 증가시킬 수 있습니다. ZFS 레코드 사이즈와 IO 사이즈를 일치 시킴으로써 이러한 문제를 없을 수 있습니다.

이노디비 로그 파일들은 쓰기 작업이 보통 순차적으로 이루어 지고 사이즈도 다양합니다. 기본적으로 ZFS 레코드 사이즈 128KB 를 사용함으로써 읽기-수정-쓰기 작업의 비용을 줄일 수 있습니다.

Note

데이타베이스 파일을 생성하기 전에 레코드 사이즈를 지정해 주어야 합니다. 만약 이미 파일들을 생성하였 다면 파일들이 새로운 레코드 사이즈를 얻을 수 있게 복사해 주어야 합니다. stat(2) 커맨드를 이용해서 레코드 사이즈를 조사해 보실 수 있습니다 (IO Block:)

What 만약 쓰기 작업이 많은 워크로드라면, Separate ZFS Intent Log 를 유지 합니다.
How zpool add log c4t0d0 c4t1d0
Why

쓰기 레이턴시가 다수의 MySQL 워크로드에서는 아주 중요합니다. 일반적으로 쿼리는 몇몇 데이타를 읽고 계산을 하고, 데이타를 업데이트를 한 다음에 트랜잭션을 커밋 합니다. 커밋을 위해서 이노디비 로그가 수정 됩니다. 많은 트랜잭션들이 동시에 커밋될 수 있습니다. 커밋에 대한 이러한 "대기" 시간이 짧은 것이 중요 합니다. ZFS 에서는 동기화 쓰기가 Separate Intent Log 를 사용함으로써 빨라질 수 있습니다. Sysbench 읽기-쓰기 로 테스트 한 결과 약 10-20% 정도의 속도 향상을 얻을 수 있었습니다.(slog)

Note
  • 만약 여러분의 쿼리 실행이 디스크에서의 물리적인 읽기가 수반된다면 쓰기 시간은 별로 중요하지 않을 수 있습니다. 이 제안을 반드시 여러분의 실제 워크로드에서 테스트해 보시기 바랍니다.
  • Bug 6574286 이 수정될때 까지 여러분은 slog 를 제거하실 수 없습니다.
  • 이노디비는 사실 여러가지 종류의 쓰기 작업을 수행 합니다 (로그 쓰기, 데이타스페이스 쓰기, 삽입 버퍼 쓰기) slog 기능은 풀 전체에서 사용가능하고 그러므로 몇몇 쓰기 (데이타스페이스 쓰기) 같이 slog 로 가지 않아야 할 것들도 가게 됩니다. 이것은 Bug 6832481 ZFS separate intent log bypass property 에 의해서 수정될 수 있습니다.
  • 또한 ZFS 트랜잭션 싱크 타임 동안에 ZFS IO 큐(35 deep) 또한 꽉 찰 수도 있습니다. 이것은 쓰기가 슬롯이 빌때 까지 기다려야 한 다는 뜻입니다. Bug 6471212: need reserved I/O scheduler slots to improve I/O latency of critical ops 가 예약된 슬롯을 사용하여 해결 합니다. Bug 6721168 slog latency impacted by I/O scheduler during spa_sync 또한 확인할 가치가 있습니다.
What L2ARC (혹은 Level 2 ARC)
How zpool add cache c4t0d0
Why

만약 여러분의 데이타베이스가 메모리에 잘 맞지 않는다면, 여러분이 데이타베이스 캐시를 미스할때 마다 디스크에서 블럭을 읽어와야 합니다. 이러한 비용은 일반적인 디스크에서 상당히 높습니다. 데이타베이스 캐시 미스 레이턴시는 한개 혹은 여러개의 SSD 를 레벨-2 캐시 혹은 L2ARC 로 사용함으로써 줄이실 수 있습니다. 여러분의 데이타베이스 워킹 셋 사이즈에 따라서 메모리와 L2ARC 사이즈는 성능에서 몇수십배의 차이를 보실 수 있습니다.

Note
What 안전한 경우에는 ZFS 캐시 flush 를 끕니다
How

ZFS Evil tuning guide 는 이 파라미터에 대한 더 자세한 정보를 제공합니다. 해당 문서를 참고하시기 바랍니다.

Why

ZFS 는 디스크 및 캐시와 함꼐 안정적으로 동작하도록 디자인 되었습니다. 데이타가 디스크에 저장이 필요할때 마다 ZFS 는 캐시 flush 커맨드를 디스크에 내립니다. 배터리에 의해 백업되는 캐시를 가진 디스크들은 어떠한 작업도 수행할 필요가 없습니다(참고로 캐시 flush 커맨드는 nop 입니다) 많은 스토리지 디바이스들이 이것을 올바르게 해석하고 올바르게 작업을 수행합니다. 그러나 몇몇 스토리지 시스템들은 여전히 캐시 flush 커맨드를 올바르게 해석하지 못합니다. 이러한 스토리지 시스템들에서 ZFS 가 캐시 flush 커맨드를 내리지 못하도록 막는 것은 IO 레이턴시를 크게 줄이는 효과를 얻을 수 있습니다. Sysbench 읽기-쓰기 테스트에서 약 30% 정도의 퍼포먼스 향상을 볼 수 있었습니다.

Note
  • 배터리로 백업되지 않는 캐시에서 이 튜닝값을 사용하는 것은 오류시에 일관성을 훼손시킬 수 있습니다.
  • ZFS 를 쓰기 캐시가 안보기에 활성화 되어 있는 파일 시스템들과 비교할때, 공정한 비교를 위해서 반드시 이 옵션을 사용하시기 바랍니다.
What ZFS Adaptive replacement cache(ARC) 대신에 MySQL/이노디비 캐시를 사용합니다.
How my.cnf 를 통한 설정 그리고 ARC 사이즈를 제한
Why

여러분이 MySQL/이노디비를 ZFS 와 사용할 때에는 복수의 캐싱레벨을 가지게 됩니다. 이노디비는 고유의 버퍼 풀을 가지고 있고 ZFS 는 ARC 를 가지고 있습니다. 두가지 모두 각각 어떤것을 캐시 하고 flush 할지 독립적으로 결정을 내리게 됩니다. 두개 모두 동일한 데이타를 캐시할 경우도 존재합니다. 이노디비 내부의 캐시를 통해서 여러분은 좀 더 짧은(그리고 빠른) 코드 경로로 데이타에 접근하실 수 있습니다. 또한 이노디비 버퍼 캐시가 꽉 찼을때, 이노디비 버퍼 캐시에 대한 미스는 ARC 에 데이타가 캐시되어 있더라도 더티 버퍼의 flush 를 유발합니다. 이것은 불필요한 쓰기 작업을 유발합니다.. 비록 ARC 가 메모리에 대한 압력에 따라서 동적으로 줄어들고 늘어나지만, 가장 효과적인 것은 단순히 그것을 제한 하는 것입니다. 저희는 보통 (7~200%) 정도 ZFS 보다 이노디비에 캐싱 하는 것이 빠르다는 것을 발견 하였습니다

Note

ARC 는 모든 데이타, 단순히 메타 데이타 혹은 파일시스템 기반에서 아무런 데이타도 캐싱하지 않도록 튜닝될 수 있습니다. 아래의 튜닝 조언을 참고하시기 바랍니다.

What ZFS prefetch 를 끕니다.
How /etc/system: set zfs:zfs_prefetch_disable = 1
Why

대부분의 파일시스템은 prefetch 같은 종류를 구현합니다. ZFS prefetch 는 선형적인 (증가 혹은 감소하는), 스트라이드, 멀티블럭 스트라이드 IO 스트림을 감지하고 퍼포먼스에 이득이 있다고 판단되면 prefetch IO 를 수행 합니다. 이러한 prefetch IO 는 일반적인 읽기 보다 낮은 우선순위를 가지고 있고 일반적으로 잇점이 있습니다. ZFS 는 또한 낮은 수준의 prefetch( 일반적으로 vdev prefetch 라고 불림) 기능을 통해서 데이타의 공간적인 지역성을 도와줄 수 있습니다.

이노디비에서 행들은 프라이머리 인덱스의 순서에 따라서 저장됩니다. 이노디비는 두 종류의 prefetch 요청을 수행합니다; 하나는 순차적인 페이지를 접근할때 발생되고 다른 하나는 익스텐트 안에서 랜덤액세스에 의해서 발생합니다. prefetch IO 명령을 내릴때 이노디비는 파일이 프라이머리 키 순서대로 배치되어 있다고 가정합니다. ZFS 에서는 그렇지 않습니다. 저희들은 여전히 이노디비 prefetch 에 대한 영향도를 조사하고 있습니다.

OLTP 워크로드에서 데이타를 랜덤한 순서대로 읽는 다는 것은 잘 알려진 사실입니다. 그래서 prefetch 로는 이득을 얻기 힘듭니다. 그러므로 저희들은 ZFS prefetch 를 끄기를 권고 합니다

Note
  • 만약 여러분이 프라이머리 캐시 전략을 단순 메타데이타 캐시로 변경하였다면 파일 레벨 prefetch 를 수행하지 않을 것입니다.
  • 만약 레코드 사이즈를 16K 로 설정했다면 하위 레벨 prefetch 를 수행하지 않을 것입니다.
What 이노디비 double write buffer 를 끕니다.
How skip-innodb_doublewrite in my.cnf
Why

이노디비는 테이블스페이스 내의 페이지들을 안전하게 업데이트 하기 위해서 double write buffer 를 사용 합니다. 이노디비는 먼저 변경사항을 이 버퍼에 쓰고 그 다음에 데이타 페이지에 씁니다. 이것은 부분적인 쓰기를 막기 위해서 입니다. ZFS 는 부분쓰기를 허용하지 않기 때문에 여러분은 안전하게 이 옵션을 끄실 수 있습니다. 저희들의 테스트에서 약 5% 정도의 성능 향상을 얻었습니다.

Note


[원문] MySQL Innodb ZFS Best Practices

출처 : http://blog.sdnkorea.com

Trackback 0 Comment 0
2008. 12. 29. 10:17

MySQL Foreign Key (외래키) 사용하기

MySQL에서 InnoDB 테이블은 Foreign 키 제한 검사를 지원한다.

Foreign 키 제한은 단순히 두 테이블을 조인 (join)하기 위해 필요한 것이 아니다. InnoDB가 아닌 스토리지 엔진의 경우, 컬럼이 REFERENCES tbl_name(col_name) 구문을 사용하도록 정의하는 것이 가능한데, 이것은 실제로 아무런 효과도 없으며, 또한 여러분이 지금 정의하는 컬럼은 다른 테이블에 있는 컬럼을 참조하도록 의도된 것이라는 것을 알려주는 메모 또는 코멘트 역할만 하게 된다. 이 신텍스를 다음과 같은 상황에서 사용할 때는 특히 중요하다:

·         MySQLcol_name 이 실제로 tbl_name 에 있는지 (또는 tbl_name 자체가 존재하는지) 확인하기 위한 어떠한 종류의 CHECK도 실행하지 않는다.   

·         MySQL 은 여러분이 정의한 테이블에서 열을 가져와서 삭제하는 것과 같은 행동을 tbl_name 에서는 전혀 하지 않는다; 다른 말로 표현하면, 이 신텍스는 ON DELETE 또는 ON UPDATE 가 구동하는데 아무런 영향을 미치지 않는다. (여러분이ON DELETE 또는 ON UPDATE 구문을 REFERENCES 구문의 일부분으로 작성한다 하더라도, 이것은 무시되어 버린다.)

·         이 신텍스는 column을 만들어 낸다; 이것은 어떤 종류의 인덱스 또는 키를 만들지는 않는다.

·         이 신텍스는 InnoDB 테이블을 정의하기 위해 사용할 때 에러를 발생시킨다.

여러분은 여기에서 보듯이, 컬럼을 만들어서 조인(join) 컬럼으로 사용할 수 있다:

CREATE TABLE person (
    id SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT,
    name CHAR(60) NOT NULL,
    PRIMARY KEY (id)
);
CREATE TABLE shirt (
    id SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT,
    style ENUM('t-shirt', 'polo', 'dress') NOT NULL,
    color ENUM('red', 'blue', 'orange', 'white', 'black') NOT NULL,
    owner SMALLINT UNSIGNED NOT NULL REFERENCES person(id),
    PRIMARY KEY (id)
);
INSERT INTO person VALUES (NULL, 'Antonio Paz'); 
SELECT @last := LAST_INSERT_ID();
INSERT INTO shirt VALUES
(NULL, 'polo', 'blue', @last),
(NULL, 'dress', 'white', @last),
(NULL, 't-shirt', 'blue', @last);
INSERT INTO person VALUES (NULL, 'Lilliana Angelovska');
SELECT @last := LAST_INSERT_ID();
INSERT INTO shirt VALUES
(NULL, 'dress', 'orange', @last),
(NULL, 'polo', 'red', @last),
(NULL, 'dress', 'blue', @last),
(NULL, 't-shirt', 'white', @last); 
SELECT * FROM person;
+----+---------------------+
| id | name                |
+----+---------------------+
|  1 | Antonio Paz         |
|  2 | Lilliana Angelovska |
+----+---------------------+ 
SELECT * FROM shirt;
+----+---------+--------+-------+
| id | style   | color  | owner |
+----+---------+--------+-------+
|  1 | polo    | blue   |     1 |
|  2 | dress   | white  |     1 |
|  3 | t-shirt | blue   |     1 |
|  4 | dress   | orange |     2 |
|  5 | polo    | red    |     2 |
|  6 | dress   | blue   |     2 |
|  7 | t-shirt | white  |     2 |
+----+---------+--------+-------+ 
SELECT s.* FROM person p, shirt s
 WHERE p.name LIKE 'Lilliana%'
   AND s.owner = p.id
   AND s.color <> 'white'; 
+----+-------+--------+-------+
| id | style | color  | owner |
+----+-------+--------+-------+
|  4 | dress | orange |     2 |
|  5 | polo  | red    |     2 |
|  6 | dress | blue   |     2 |
+----+-------+--------+-------+

이러한 형태로 사용될 경우에, REFERENCES 구문은 SHOW CREATE TABLE 또는 DESCRIBE 구문의 결과에는 나타나지 않는다:

SHOW CREATE TABLE shirt\G
*************************** 1. row ***************************
Table: shirt
Create Table: CREATE TABLE `shirt` (
`id` smallint(5) unsigned NOT NULL auto_increment,
`style` enum('t-shirt','polo','dress') NOT NULL,
`color` enum('red','blue','orange','white','black') NOT NULL,
`owner` smallint(5) unsigned NOT NULL,
PRIMARY KEY  (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1

여기에서처럼 REFERENCES 를 컬럼 정의문에서 코멘트 형태 또는 리마인더(reminder)”로 사용하는 것은 MyISAM BerkeleyDB 테이블에서도 적용 할 수 있다.


출처 : www.mysqlkorea.co.kr

Trackback 0 Comment 1
  1. 최세민 2009.08.20 17:59 address edit & del reply

    좋은 정보 감사합니다.
    FOREIGN KEY가 적용 되지 않아서 한참 해맸는데 테이블 형식을 innodb로 변경하니깐 바로 적용 되는 군요. ^^

2008. 12. 17. 10:05

MySQL InnoDB 스토리지 엔진

 

 

 * InnoDB란?

 * InnoDB 설정

 

 

[InnoDB란?]

 

InnoDB 스토리지 엔진은 대용량 데이터를 처리할때 최고의 성능을 낼 수 있도록 설계되었으며 디스크기반의 여타 다른 스토리지 엔진 보다 우수하다. InnoDB 스토리지 엔진은의 가장 두드러진 점은 트랙젝션 기능이 있다. 또한 로우 레벨 락킹이 가능하며 Foreign Key도 지원한다.

 

InnoDB 스토리지 엔진은 자신만의 테이블 스페이스 및 버퍼 풀을 가지고 있다. 테이블 스페이스는 데이타 및 인덱스를 저장하기 위해 쓰이며 버퍼 풀은 메모리에 데이터와 인덱스를 캐싱하기 위해 활용된다. 테이블 스페이스는 여러개의 파일로 구성 할 수 있으며 테이블 단위로 테이블 스페이스를 만들어 줄 수 있다. 또한 OS의 파일 처리 시스템이 최대 2G로 되어 있다고 해도 InnoDB에서는 2G이상의 테이블 스페이스를 만들수 있다.

 

* InnoDB 테이블 스페이스 최대 한계치는 64TB이다.

 

[InnoDB설정]

 

MySQL 환경 설정에서 InnoDB 스토리지 엔진은 기본으로 구성되어 있다. InnoDB를 사용하지 않을 경우에는 옵션 skip-innodb를 환경 설정 파일에 추가해주면 된다.

 

아래 내용은 기본 환경설정 파일 중 my-huge.cnf에 대한 설정 부분이며 메모리가 1G-2G일 때 권장하는 환경 설정 파일이다.(서비스 내용에 따라 알맞는 튜닝이 필요하다.)

[my-huge.cnf]
      # Example MySQL config file for very large systems.
      #
      # This is for a large system with memory of 1G-2G where the system runs mainly
      # MySQL.
      :
     (중략)
      :
      # Uncomment the following if you are using InnoDB tables
A01 #innodb_data_home_dir = /usr/local/mysql/data/
A02 #innodb_data_file_path = ibdata1:2000M;ibdata2:10M:autoextend
A03 #innodb_log_group_home_dir = /usr/local/mysql/data/
A04 #innodb_log_arch_dir = /usr/local/mysql/data/
      # You can set .._buffer_pool_size up to 50 - 80 %
      # of RAM but beware of setting memory usage too high
A05 #innodb_buffer_pool_size = 384M
A06 #innodb_additional_mem_pool_size = 20M
      # Set .._log_file_size to 25 % of buffer pool size
A07 #innodb_log_file_size = 100M
A08 #innodb_log_buffer_size = 8M
A09 #innodb_flush_log_at_trx_commit = 1
A10 #innodb_lock_wait_timeout = 50
      :
      (중략)
      :

아래 내용은 기본 환경설정 파일 중 my-innodb-heavy-4G.cnf(InnoDB 전용)에 대한 설정 부분이며 메모리가 4G일 때 권장하는 환경 설정 파일이다.(서비스 내용에 따라 알맞는 튜닝이 필요하다.)

[my-innodb-heavy-4G.cnf]
      #BEGIN CONFIG INFO
      #DESCR: 4GB RAM, InnoDB only, ACID, few connections, heavy queries
      #TYPE: SYSTEM
      #END CONFIG INFO

      #
      # This is a MySQL example config file for systems with 4GB of memory
      # running mostly MySQL using InnoDB only tables and performing complex
      # queries with few connections.
      :
      (중략)
      :

      # Set the default transaction isolation level. Levels available are:
      # READ-UNCOMMITTED, READ-COMMITTED, REPEATABLE-READ, SERIALIZABLE
B01 transaction_isolation = REPEATABLE-READ

      :
      (중략)
      :

      # *** INNODB Specific options ***

      # Use this option if you have a MySQL server with InnoDB support enabled
      # but you do not plan to use it. This will save memory and disk space
      # and speed up some things.
B02 #skip-innodb

      # Additional memory pool that is used by InnoDB to store metadata
      # information.  If InnoDB requires more memory for this purpose it will
      # start to allocate it from the OS.  As this is fast enough on most
      # recent operating systems, you normally do not need to change this
      # value. SHOW INNODB STATUS will display the current amount used.
B03 innodb_additional_mem_pool_size = 16M

      # InnoDB, unlike MyISAM, uses a buffer pool to cache both indexes and
      # row data. The bigger you set this the less disk I/O is needed to
      # access data in tables. On a dedicated database server you may set this
      # parameter up to 80% of the machine physical memory size. Do not set it
      # too large, though, because competition of the physical memory may
      # cause paging in the operating system.  Note that on 32bit systems you
      # might be limited to 2-3.5G of user level memory per process, so do not
      # set it too high.
B04 innodb_buffer_pool_size = 2G

      # InnoDB stores data in one or more data files forming the tablespace.
      # If you have a single logical drive for your data, a single
      # autoextending file would be good enough. In other cases, a single file
      # per device is often a good choice. You can configure InnoDB to use raw
      # disk partitions as well - please refer to the manual for more info
      # about this.
B05 innodb_data_file_path = ibdata1:10M:autoextend

      # Set this option if you would like the InnoDB tablespace files to be
      # stored in another location. By default this is the MySQL datadir.
B06 #innodb_data_home_dir = <directory>

      # Number of IO threads to use for async IO operations. This value is
      # hardcoded to 4 on Unix, but on Windows disk I/O may benefit from a
      # larger number.
B07 innodb_file_io_threads = 4

      # If you run into InnoDB tablespace corruption, setting this to a nonzero
      # value will likely help you to dump your tables. Start from value 1 and
      # increase it until you're able to dump the table successfully.
B08 #innodb_force_recovery=1

      # Number of threads allowed inside the InnoDB kernel. The optimal value
      # depends highly on the application, hardware as well as the OS
      # scheduler properties. A too high value may lead to thread thrashing.
B09 innodb_thread_concurrency = 16

      # If set to 1, InnoDB will flush (fsync) the transaction logs to the
      # disk at each commit, which offers full ACID behavior. If you are
      # willing to compromise this safety, and you are running small
      # transactions, you may set this to 0 or 2 to reduce disk I/O to the
      # logs. Value 0 means that the log is only written to the log file and
      # the log file flushed to disk approximately once per second. Value 2
      # means the log is written to the log file at each commit, but the log
      # file is only flushed to disk approximately once per second.
B10 innodb_flush_log_at_trx_commit = 1

      # Speed up InnoDB shutdown. This will disable InnoDB to do a full purge
      # and insert buffer merge on shutdown. It may increase shutdown time a
      # lot, but InnoDB will have to do it on the next startup instead.
B11 #innodb_fast_shutdown

      # The size of the buffer InnoDB uses for buffering log data. As soon as
      # it is full, InnoDB will have to flush it to disk. As it is flushed
      # once per second anyway, it does not make sense to have it very large
      # (even with long transactions).
B12 innodb_log_buffer_size = 8M

      # Size of each log file in a log group. You should set the combined size
      # of log files to about 25%-100% of your buffer pool size to avoid
      # unneeded buffer pool flush activity on log file overwrite. However,
      # note that a larger logfile size will increase the time needed for the
      # recovery process.
B13 innodb_log_file_size = 256M

      # Total number of files in the log group. A value of 2-3 is usually good
      # enough.
B14 innodb_log_files_in_group = 3

      # Location of the InnoDB log files. Default is the MySQL datadir. You
      # may wish to point it to a dedicated hard drive or a RAID1 volume for
      # improved performance
B15 #innodb_log_group_home_dir

      # Maximum allowed percentage of dirty pages in the InnoDB buffer pool.
      # If it is reached, InnoDB will start flushing them out agressively to
      # not run out of clean pages at all. This is a soft limit, not
      # guaranteed to be held.
B16 innodb_max_dirty_pages_pct = 90

      # The flush method InnoDB will use for Log. The tablespace always uses
      # doublewrite flush logic. The default value is "fdatasync", another
      # option is "O_DSYNC".
B17 #innodb_flush_method=O_DSYNC

      # How long an InnoDB transaction should wait for a lock to be granted
      # before being rolled back. InnoDB automatically detects transaction
      # deadlocks in its own lock table and rolls back the transaction. If you
      # use the LOCK TABLES command, or other transaction-safe storage engines
      # than InnoDB in the same transaction, then a deadlock may arise which
      # InnoDB cannot notice. In cases like this the timeout is useful to
      # resolve the situation.
B18 innodb_lock_wait_timeout = 120

      :
      (중략)
      :

* InnoDB 활성화 시 테이블 스페이스 파일과 로그 파일이 생성이 된다.


Trackback 0 Comment 0