DBMS (MySQL)에서 "트랜잭션 저널링"을 사용해야하는 프로젝트를 진행 중입니다. 우리는 이미 다른 요구 사항을 위해 트랜잭션을 사용하기 위해 InnoDB를 사용하도록 전환했다. 거래 일지가 무엇인지 이해하려고합니다. 나는 MySQL 문서를 읽는 것을 포함하여 하루 이상을 찾고있다. 어쩌면 나는 적절한 키워드를 검색하지 않고 있을지 모르겠습니다. 아니면 "거래 일지"가 부적절한 용어 일 수도 있습니다.MySQL 트랜잭션 저널
데이터베이스 트랜잭션 저널링은 파일 시스템에 커밋되기 전에 저널을 변경한다는 점에서 저널링 파일 시스템과 유사합니다. 필자가 읽은 바에 따르면 InnoDB 엔진은 디스크에 커밋되기 전에 일종의 저널에 트랜잭션을 저장하는 것처럼 들립니다. 이 소리가 정확합니까? 그렇다면 거래 일지는 어디에 있습니까? ib_logfile0과 ib_logfile1입니까?
여기 올바른 길을 가고 있습니다.
InnoDB가 커밋해야 할 트랜잭션을 수행 할 때마다 2 단계 커밋으로 처리됩니다. 트랜잭션은 먼저이 로그에 기록됩니다. 그런 다음 그들은 거기서 저 지르게됩니다.
이것은 MySQL 충돌 또는 서버 충돌시 많은 도움이됩니다.
당신은 MySQL은, ib_logfile0에서 커밋되지 않은 모든 항목을 다시 시작하고 (이것은 일관성과 ACID Compliance의 내구성 부분)
삭제하면 조화로운 상태로 이노을 가져 이노의 크래시 복구의 일환으로 ib_logfile1라는 재생하는 경우 ib_logfile0 및 ib_logfile1을 실행하고 mysql을 시작합니다. 이러한 파일이 포함 된 커밋되지 않은 트랜잭션이 손실됩니다. 응급 복구주기 중에 로그 파일이 누락 된 경우 innodb_log_file_size 설정에 따라 재생성됩니다.
MySQL Documentation for a detailed explanation of InnoDB을 참조하십시오.
@karatedog InnoDB의 MVCC 부분은 ibdata1로 더 잘 알려진 시스템 테이블 공간 내에서 발생합니다. 트랜잭션 시작 전에 나타나는 모든 데이터가 기록되어 업데이트가 부과되기 전에 필요한 행에 액세스하는 다른 사용자가 데이터를 볼 수 있습니다. 이것은 반복 가능 읽기 (REPEATABLE-READ)를 허용합니다. 이것은 ACID 준수, 즉 격리를 의미합니다. 나는 트랜잭션 격리가 좋고, 좋지 않거나 추악한 다양한 시나리오와 관련하여 DBA StackExchange에 이에 대한 게시물을 썼다. 의 MyISAM로서는 Is raid 5 suitable for mysql installation?
Will these two queries result in a deadlock if executed in sequence?
REPAIR TABLE이 존재합니다. 이것이 MySQL 유틸리티 myisamchk이 -r 옵션을 사용하여 온라인이 아닌 MyISAM 테이블에 REPAIR TABLE을 수행하는 이유이기도합니다. MariaDB and Aria은 MyISAM의 대체품으로 크래시 안전 스토리지 엔진을 만들기위한 시도입니다.
이 로그 파일은 응급 복구를위한 것이지만 충돌이 발생하지 않을 때 "트랜잭션"이 올바르게 수행되도록하는 MVCC 메커니즘이 아닌 것으로 알고 있습니다. MyISAM은 트랜잭션이 전혀없는 동안 어느 정도의 크래시 복구를합니다. – karatedog
상세하고시기 적절한 답변을 주셔서 감사합니다. 로그에서 항목을 재생하는 것에 대해 약간 혼란 스럽습니다.트랜잭션 중간에 오류가 발생하면 커밋이 이루어지기 전에 트랜잭션이 모두 또는 전혀 수행되지 않으므로 항목을 재생하고 싶지 않을 것입니다 (트랜잭션의 일부가 저지른). 또는 트랜잭션이 데이터베이스에 커밋되기 전에 실패가 발생했으나 로그 파일에 저장 된 후에 커밋이 발생했을 때만 재생할 것이라고 말하고 있습니까? – alfredough