linuxism

2010년 12월 25일 토요일

InnoDB Redo log

InnoDB Redo log (일반적으로 log 라고 명명)

• 일반적으로 ib_logfile 이라는 이름으로 파일로 생성됨
• 리두 로그는 하나의 데이터베이스에 전역적으로 1개만 존재함
• 리두 로그는 여러개의 파일 그룹으로 구성되며, 최소 2개 이상으로 구성되며, 순환적(Circular)으로 사용됨
• 리두 로그 파일의 헤더에는 마지막 체크 포인트 값이 관리됨
• 리두 로그는 페이지 형태로 관리되지 않고 레코드 단위로 관리됨
• 하나의 리두 로그 레코드는 512 바이트 단위로 할당되며, 이는 디스크의 섹터 크기와 동일한 크기임
• 작은 트랜잭션이 많은 경우(리두 로그 정보가 512바이트보다 많이 작은 경우), 로그의 나머지 공간은 낭비됨
• 리두 로그는 변경 후의 데이터만 관리함 (변경 전의 데이터는 가지지 않음)

Redo log 관련 옵션

• innodb_log_group_home_dir
  리두 로그 파일들이 존재하는 디렉토리
• innodb_log_file_size
  리두 로그 그룹의 각 파일들 사이즈 (리두 로그 전체 사이즈 =  innodb_log_files_in_group * innodb_log_file_size)
• innodb_log_files_in_group
  리두 로그 그룹의 파일 개수 
• innodb_log_buffer_size
  리두 로그를 파일에 직접 기록하기 전 메모리상에서 버퍼링을 하는데 이를 위한 버퍼 사이즈
• innodb_flush_log_at_trx_commit
  리두 로그를 언제 버퍼에서 파일로 기록할지 결정 (매 트랜잭션마다, 1초에 한번씩 기록, ...)

Redo log 관련 옵션 변경

• 단순히 my.cnf 파일의 관련 옵션을 변경할 수는 없음 (특히, innodb_log_file_size 와 innodb_log_files_in_group 옵션)
• 먼저 MySQL 서버를 깨끗하게 종료함 (set global innodb_fast_shutdown=0 옵션 적용 후, MySQL을 종료)
  -> InnoDB 재 시작시 Redo log가 필요 없도록 모든 변경된 데이터 페이지를 디스크에 기록
• 기존의 Redo log 파일들 (ib_logfile*)은 삭제 또는 백업
  -> 기존 파일이 그 위치에 남아있으면 안됨)
• Redo log 관련 옵션 변경
• MySQL 재 시작 (Redo log 파일이 없으면 새로 생성함)

Redo log buffer

• Redo log files에 기록하기 전에 메모리상에서 버퍼링 하기 위한 공간
• 일반적으로 Redo log buffer의 사이즈는 4M ~ 16M 정도로 충분함
• BLOB이나 TEXT 형태의 데이터 변경이 많은 경우에는 Log buffer의 사이즈를 더 늘려야할 필요성 있음
• Log buffer가 10초 정도의 트랜잭션을 유지할 수 있으면 충분함
• Log의 disk write회수와 write된 바이트 수는 Status Variable로 확인 가능

Redo log files

• Redo log file들은 기본적으로 버퍼링 모드로 할상 오픈된 상태임
• fsync() System call을 이용하여 Disk로 Flush됨
• 일반적으로 Redo log는 4KB 미만의 블록으로 Disk에 기록됨
• Redo log 파일에 기록하기 전에 반드시 읽기 작업이 필요함

Redo log 레코드 포맷

• 페이지 번호
• 페이지에서 대상 레코드의 Offset (위치)
• 로그 타입 (INSERT, UPDATE, DELETE)
• 변경후의 값

작성자: 토토 시간: 23:52  

이메일로 전송BlogThis!Twitter에서 공유Facebook에서 공유

라벨: InnoDB, Redo

댓글 3개:

1. 
   lsfeel02042011년 7월 11일 오전 3:00

   작성자가 댓글을 삭제했습니다.

   답글
2. 
   lsfeel02042011년 7월 11일 오전 8:00

   안녕하세요? 요즘 한창 InnoDB redo logging쪽을 들여다보고 있는 학생입니다.
   
   소스코드 디버깅을 통해 분석해 보고 있는데요. 위에서 언급해주신 내용에서 궁금한 점이 있어 이렇게 댓글을 답니다.
   
   혹시 위에서 언급하신 "리두 로그는 변경 후의 데이터만 관리함" 에서 "리두 로그"가 Redo log record만을 의미하는 것인지 궁금합니다.
   
   MySQL에 INSERT Query를 수행하는 과정을 주욱 tracing해보니, 변경 후의 정보(redo log record)뿐만 아니라, DML 구문을 수행중에 생성되는 undo log record도 함께 mini-transaction에 logging된다는 사실을 확인하였는데요..(이러한 redo/undo logging 정보들은 mtr_commit시 Redo log buffer에 기록되었다가 transaction commit 또는 checkpoint시점에 InnoDB redo log file에 flush되는 것으로 알고 있습니다.)
   
   그래서 이 부분도 함께 언급해주면 좋을 것 같다는 생각이 듭니다.
   (즉, InnoDB에서는 crash recovery를 위한 log 정보로써 redo log 및 undo log 정보를 함께 redo log file에 기록한다...이 글에서 말하는 Redo log는 redo log record만을 일컫는다..)
   
   혹시 제가 잘못 알고 있는 것인지 궁금합니다.
   
   p.s MySQL 공부하면서 작성자님 글이 큰 도움이 되고 있습니다^^ 정말 감사드립니다...

   답글
3. 
   토토2011년 8월 17일 오후 8:24

   안녕하세요.
   
   InnoDB에서 트랜잭션의 COMMIT/ROLLBACK을 위해서
   두 가지 로그를 가지고 있습니다. 말씀하신 것과 같이 Redo log와 Undo log인데요. Redo log buffer를 거쳐서 Redo log file로 저장되는 것은 맞습니다.
   Redo log 파일에는 변경된 정보들이 하나의 레코드로 저장되는데 이를 Redo log record라고 표현하는 것이 더 정확하겠지만, 여기에서는 Redo log record랑 Redo log랑 동의어정도로 생각해주시면 될듯합니다. 
   
   Redo log는 Roll forwarding을 위한 로그이고,
   Undo log는 Roll backing을 위한 로그입니다. 둘은 전혀 다른 로그이며,
   저장 위치도 다릅니다.
   
   Redo log는 InnoDB log file ( innodb_log_file_size 와 innodb_log_files_in_group 옵션으로 지정되는) 에 기록되지만
   Undo log는 시스템 테이블 스페이스에 저장됩니다.
   또한 Undo log는 트랜잭션의 Commit/Rollback 이외에도 
   Non-locking consistent read에도 이용되기 때문에 변경의 주체가 되는 트랜잭션 종료와 관계 없이 계속 시스템 테이블 스페이스에 남아 있을 수 있습니다.
   
   다른 궁금하신 것이 있으시면 또 문의 주세요

출처 - http://intomysql.blogspot.kr/2010/12/innodb-redo-log.html

Innobase Oy was a Finnish company headquartered in Helsinki, Finland. Innobase is best known for being the developer of the InnoDB transactional storage engine for the MySQL open source database system. From 2005 on, Innobase Oy was a subsidiary of Oracle Corporation, which acquired Innobase.^[1] It has been fully merged into Oracle and terminated all business activities as of July 8, 2013.^[2]

History[edit]

In 1995 Heikki Tuuri founded Innobase Oy to develop InnoDB. In September 2000 Innobase Oy started collaboration with MySQL AB, which resulted in the release of MySQL that incorporated InnoDB in March 2001.

InnoDB was originally closed source, but was released to open source after Innobase failed to find a buyer for InnoDB and started collaboration with MySQL. MySQL tried to close a deal with Innobase in the following years, but eventually Oracle acquired Innobase in October, 2005. Oracle eventually also acquired Sun Microsystems, owner of MySQL AB, in January 2010.

External links[edit]

• Innobase Oy on cnet.com,

References[edit]

출처 - http://en.wikipedia.org/wiki/Innobase

InnoDB is a storage engine for MySQL. MySQL 5.5 and later use it by default. It provides the standard ACID-compliant transaction features, along with foreign keysupport (Declarative Referential Integrity). It is included as standard in most binaries distributed by MySQL AB, the exception being some OEM versions.

InnoDB became a product of Oracle Corporation after its acquisition of Innobase Oy in October 2005.^[1] The software is dual licensed; it is distributed under the GNU General Public License, but can also be licensed to parties wishing to combine InnoDB in proprietary software.^[2]

MariaDB and Percona Server use a fork of InnoDB called XtraDB by default. XtraDB is maintained by Percona. Oracle InnoDB's changes are regularly imported into XtraDB, and some bug fixes and extra features are added.

Features[edit]

InnoDB supports:

• Both SQL and XA transactions
• Tablespaces
• Foreign keys
• FULLTEXT indexes, since MySQL 5.6 and MariaDB 10.0
• Spatial operations, following the OpenGIS standard
• Virtual columns, only in MariaDB^{[citation needed]}

See also[edit]

• Comparison of MySQL database engines

References[edit]

External links[edit]

• Mysqltutorial.org, InnoDB and other table types in MySQL
• Not-so-well-known differences between MyISAM and InnoDB MySQL server storage engines
• The InnoDB Storage Engine, in the MySQL manual.

출처 - http://en.wikipedia.org/wiki/InnoDB

my.cnf에 innodb설정에서 autoextend를 사용해 본 경험이 있는가. 이 옵션을 사용할 경우, 관리에 편리함을 제공받지만, disk가 full이 될 경우, 서버가 죽거나 error를 발생시키는 일이 발생하곤 한다. 이로인해 새로운 디스크를 추가하는 작업/이전하는 작업등 최악의 불편함을 야기하게 된다.
autoextend 옵션이 셋팅된 서버에, 수동으로 extend할 수 있도록 셋팅하는 방법을 알아본다.

more..

초기에 InnoDB의 데이터 파일을 하나로 설정하고 자동증가로 두고 쓰다가 데이터 파일을 추가할 때 사이즈 계산하는 방법이다.

http://www.techiegroups.com/showthread.php?t=8348

since you did not have any my.cnf, ibdata1 is an auto-extending data file
(initially 10 MB) in the datadir of MySQL. And there are two 5 MB
ib_logfiles in the datadir.

"
If you specify the last data file with the autoextend option, InnoDB will
extend the last data file if it runs out of free space in the tablespace.
The increment is 8 MB at a time. An example:
innodb_data_home_dir =
innodb_data_file_path = /ibdata/ibdata1:100M:autoextend

instructs InnoDB to create just a single data file whose initial size is 100
MB and which is extended in 8 MB blocks when space runs out. If the disk
becomes full you may want to add another data file to another disk, for
example. Then you have to look the size of ibdata1, round the size downward
to the closest multiple of 1024 * 1024 bytes (= 1 MB), and specify the
rounded size of ibdata1 explicitly in innodb_data_file_path. After that you
can add another data file:

innodb_data_home_dir =
innodb_data_file_path = /ibdata/ibdata1:988M;/disk2/ibdata2:50M:autoextend
"

81024 pages = 1266 MB

16384 pages = 256 MB

In your case the line

innodb_data_file_path = ibdata1:1266M;ibdata2:10M:autoextend

might work. But best to make a backup of the MySQL datadir first, just in
case something goes wrong.

Regards,

Heikki

처음 my.cnf를 셋팅할 때 100M:autoextend를 설정해두고 얼마나 늘어난지 정확히 알 수 없다면,
위와 같은 방법으로 계산하여, 수동으로 설정할 수가 있다. 따라서, diskfull에 의한 피해를 입지 않도록 할 수 있다.

100M:autoextend 로 설정했다고 해도, 총 데이터 사이즈가 100M를 넘지 않았을 경우에는 그냥 autoextend구문을 빼고, 새로운 데이터파일을 추가할 수 있다.
예) ibdata1:100M:autoextend --> ibdata1:100M; ibdata2:100M

데이터 파일 추가전에 반드시 백업을 통해 데이터유실에 대한 피해를 예방하여야 하며, 사이즈를 잘못 계산하여 에러가 발생했을때에는 err로그를 보자. 그곳에 정확한 page 사이즈가 찍힌다.

more..

위 와 같은 경험을 해본 사람이라면, mysql 사용시 autoextend를 잘 사용하지는 않을 것이다. 하지만, 아직 일부의 개발자들은 autoextend를 편리함으로 인해 사용하고 있다. 이를 지원해주기 위해 위 내용을 알아두고 활용하면 좋으리라. ^0^        

출처 - http://niflheim.tistory.com/23

초기에 InnoDB의 데이터 파일을 하나로 설정하고 자동증가로 두고 쓰다가 데이터 파일을 추가할 때 사이즈 계산하는 방법이다.

http://www.techiegroups.com/showthread.php?t=8348

since you did not have any my.cnf, ibdata1 is an auto-extending data file
(initially 10 MB) in the datadir of MySQL. And there are two 5 MB
ib_logfiles in the datadir.

"
If you specify the last data file with the autoextend option, InnoDB will
extend the last data file if it runs out of free space in the tablespace.
The increment is 8 MB at a time. An example:
innodb_data_home_dir =
innodb_data_file_path = /ibdata/ibdata1:100M:autoextend

instructs InnoDB to create just a single data file whose initial size is 100
MB and which is extended in 8 MB blocks when space runs out. If the disk
becomes full you may want to add another data file to another disk, for
example. Then you have to look the size of ibdata1, round the size downward
to the closest multiple of 1024 * 1024 bytes (= 1 MB), and specify the
rounded size of ibdata1 explicitly in innodb_data_file_path. After that you
can add another data file:

innodb_data_home_dir =
innodb_data_file_path = /ibdata/ibdata1:988M;/disk2/ibdata2:50M:autoextend
"

81024 pages = 1266 MB

16384 pages = 256 MB

In your case the line

innodb_data_file_path = ibdata1:1266M;ibdata2:10M:autoextend

might work. But best to make a backup of the MySQL datadir first, just in
case something goes wrong.

Regards,

Heikki

최초 100MB로 설정된 데이터 파일이 130메가로 자동증가된 경우에는 위와 같이 자동증가 파일의 사이즈를 정해주고 새로운 데이터 파일을 추가하면 된다.

주의할 점은 autoextend 옵션은 마지막에만 쓸 수 있다. 그래서 첫번째 파일의 사이즈를 정해주는 과정이 필요한 것이다.

데이터 파일의 추가 전 반드시 백업을 하여 만일의 사태에 대비하여야 하며, 데이터 파일 추가시에 사이즈 문제로 오류가 발생한다면 에러로그를 보라. 로그안에 페이지 사이즈가 나온다. 그 페이지 사이즈로 위와 같이 용량을 계산하면 된다.

위 경우는 autoextend 된 데이터 파일이 있는 경우에 해당한다. 그러나 원래 설정한 용량이 초과하지 않은 데이터 파일만 있는 경우는 간단히 새로운 데이터 파일과 용량만 설정하고 서버를 다시 시작하면 데이터 파일 추가가 적용된다.

출처 - http://mixellaneous.tistory.com/75

출처 - http://www.mysqlkorea.co.kr/gnuboard4/bbs/board.php?bo_table=community_03&wr_id=1424