■ Undo Log란? • 임시 테이블 스페이스에있는 언두 로그는 사용자 정의 임시 테이블의 데이터를 수정하는 트랜잭션에 사용됩니다. 실행 취소 로그 레코드의 집합으로 Transaction 실행후 Rollback 시 Undo Log 를 참조해 이전 데이터로 복구할수 있도록 로깅 해놓은 영역입니다. 서버가 실행되는 동안 롤백에만 사용됩니다. 이 유형의 실행 언두 로그는 재실행 로깅 I/O를 피함으로써 성능을 향상시킵니다. 트랜잭션이 데이터를 쓸 때 항상 테이블 인덱스 또는 데이터(버퍼 풀 또는 실제 파일)에 데이터를 삽입합니다. 개인 복사본이 생성되지 않습니다. 활성 XtraDB/InnoDB 트랜잭션에 의해 수정되는 이전 버전의 데이터는 실행 취소 로그에 저장됩니다. 그런 다음 원본 데이터를 복원하거나 일..
■ DBMS에서 커밋(Commit)이란?? COMMIT 문은 관계형 데이터베이스 관리 시스템(RDBMS)에서 트랜잭션을 종료하고 다른 사용자에게 변경된 모든 사항을 보이도록 만드는 명령문입니다. 일반적으로 트랜잭션 종료시 해당 업데이트를 확정한다는 의미에서 "commit"이라고 합니다. 반대로 업데이트를 취소 처리를 롤백 (ROLLBACK)이라고 하며, 이러한 제어를 약속 제어라고 부르기도합니다. SQL에서는 ROLLBACK 문이 그 처리를 담당합니다. SQL에서 COMMIT은 RDBMS 내에 있는 데이터베이스 트랜잭션을 종결시키고, 모든 변화를 다른 사용자들이 볼 수 있게 합니다. 일반적인 포맷은 BEGIN WORK 구문으로 시작하여, COMMIT 구문이 나오게 됩니다. 다른 방법으로 ROLLBACK ..
■ Redo Log란 많은 데이터베이스 관리 시스템과 마찬가지로 MySQL은 데이터 내구성을 달성하기 위해 로그를 사용합니다(기본 InnoDB 스토리지 엔진을 사용할 때). 만약 DB 에 장애가 발생하여서 메모리 영역에만 남아있는 데이터를 디스크 영역으로 옮겨지지 못한채 서버가 다운되는 현상이 발생했을때 복구할수 있는방법이 바로 Redo Log, Undo log를 이용하는 것입니다. 이 로그들을 이용하면 트랜잭션이 커밋될 때 충돌이나 정전이 발생해도 데이터가 손실되지 않습니다. 리두로그에 대해선 따로 정리해서 포스팅하겠습니다. ■ Redo log 동작원리 MySQL의 InnoDB 스토리지 엔진은 고정 크기(순환방식)의 Redo 로그 공간을 사용합니다. 크기는 innodb_log_file_size 및 in..
■ InnoDB 스토리지 엔진 모니터링 방법 InnoDB 스토리지의 상태를 확인하는 방법은 infomration_Schema와 sys스키마, performance 스키마를 확인하는 방법등이 있습니다. 이중에서 가장 대표전인것이 Show 명령어를 이용하여 엔젠상태를 확인하는 방법입니다. 이 명령어를 통해서 나오는 스토리지 엔진에 대해 하나하나 확인해 보겠습니다. ■ 스토리지 엔진 내용 MySQL에서 다음과 같은 명령어를 입력하면 아래와 같은 화면이 나옵니다. 이 내용 안에는 Deadlock 정보, 버퍼풀 정보, 트랜잭션 정보등 정말 DBA에게 중요한 정보들이 많이 나옵니다. 이 정보들에 대해 확인해 보겠습니다. MySQL> show engine innodb status; ===================..
sync_relay_log sync_relay_log를 1로 설정하면 수신된 각 트랜잭션이 디스크에 기록된 후 릴레이 로그를 디스크에 동기화하도록 복제 I/O 스레드에 지시합니다. 즉 성능은 줄이되 안정성을 높이는 방법입니다. 가능하면 1로 설정을 권고합니다. 0이나 다른 숫자로 바꾸면 성능이 좋아지긴 합니다. 이건 선택적인 문제이기도 합니다. 참고로 sync_relay_log를 1보다 크게 또는 sync_relay_log를 0(여기서 동기화는 운영 체제에서 처리됨)인 경우 복제본이 예기치 않게 중단되는 경우 디스크에 동기화되지 않은 커밋된 트랜잭션이 있을 수 있습니다. 이러한 트랜잭션으로 인해 디스크에 마지막으로 동기화된 릴레이 로그에 있는 정보를 기반으로 복구 중인 복제본이 트랜잭션을 건너뛰는 대신 ..
■ InnoDB 스토리지 엔진의 테이블 데이터 저장 방식 MySQL 테이블의 데이터는 IOT(Index Oraganized Table)라고 하여 프리머리 키값을 이용하여 데이터를 정렬 후 테이블에 저장하게 되어 있습니다. 이 프리머리 키를 다른말로 클러스터링 인덱스라고도 합니다. 그리고 MySQL에서는 이 클러스터링 인덱스가 좀 특별하게 다루어집니다. 그림 1. MySQL B-Tree 인덱스 구조 위의 그림은 MySQL의 클러스터링 인덱스의 구조인데 일반적인 B- Tree 인덱스와 비슷합니다.. 그러나 MySQL에서 B-Tree 인덱스의 리프노드에는 모든 칼럼이 같이 저장되어 있습니다. 즉 클러스터링 테이블은 데이터와 프리머리 인덱스를 모두 포함하고 있는 구조가 되는 것입니다. ■ 세컨더리 인덱스(Sec..
■ Com_xxx 명령문 카운터 Com_xxx 명령문 카운터 변수는 각 xxx 문이 실행된 횟수를 나타냅니다. 각 명령문 유형에 대해 하나의 상태 변수가 있습니다. 예를 들어 Com_delete 및 Com_update는 각각 DELETE 및 UPDATE 문을 계산합니다. Com_delete_multi 및 Com_update_multi는 유사하지만 다중 테이블 구문을 사용하는 DELETE 및 UPDATE 문에 적용됩니다. 쿼리 캐시에서 쿼리 결과가 반환되면 서버는 Com_select가 아니라 Qcache_hits 상태 변수를 증가시킵니다. 차이점을 잘 판별해야 합니다. Prepared Statement(준비된 명령문) Parameter(인수)를 알 수 없거나 실행 중 오류가 발생한 경우에도 모든 Com_s..
■ 버퍼풀 상태 저장과 복원 서버를 다시 시작한 후 워밍업 기간을 줄이기 위해 InnoDB는 서버 종료시 각 버퍼 풀에 대해 가장 최근에 사용한 페이지의 백분율을 저장하고 서버 시작시 이러한 페이지를 복원합니다. 최근에 저장된 페이지의 백분율은 innodb_buffer_pool_dump_pct 구성 옵션으로 정의됩니다. 사용중인 서버를 다시 시작한 후에는 버퍼풀에 있던 디스크 페이지가 메모리로 다시 가져오기 때문에 (같은 데이터를 쿼리, 업데이트 등) 일반적으로 워밍업 시간이 꾸준히 증가합니다. 시작시 버퍼 풀을 복원하는 기능은 DML 조작이 해당 행에 액세스 할 때까지 기다리지 않고 다시 시작하기 전에 버퍼 풀에 있던 디스크 페이지를 다시로드하여 예열시간(warmup)을 단축시킵니다. 또한 대규모 일괄..
아시다시피 CentOS 8이 Redhat 정책에 의해서 더이상 엔터프라이즈 리눅스로서 위치가 이상해지기 시작했습니다. 역시 IBM으로 편입되면서 애매한 위치를 만들어 버리는군요. 이에 RHEL을 Fork하여 CentOS와 비슷한 엔터프라이즈 커뮤니티를 다시 만든것이 Rokcy 리눅스인것으로 알고 있습니다. 조만간 리눅스가 안정화되기 시작하면 본격적으로 CentOS를 대체할것이라 생각합니다. 특히 8.5는 정식으로 Rocky Linux에서 릴리즈한 버전으로 도전정신이 있으신분은 쓰셔도 무방할 듯 합니다. 저도 빨리 정식 서비스에 사용해보고 싶습니다. 지금부터 MySQL 8.0을 Rocky Linux에 설치하는 방법을 알아보도록 하겠습니다. ■ MySQL 계정 만들기 먼저 mysql에서 사용할 계정을 만들어..
보통 IP를 DB에 저장할때는 캐릭터 형태의 컬럼(varchar 혹은 char)을 많이 사용하는것으로 알고 있습니다. 저또한 마찬가지 입니다. 그러나 MySQL에서는 IP를 특화된 방법으로 저장하고 불러올 수 있습니다. 또한 저장 방법이 Integer방식이기 때문에 검색에서 더 효율적이기도 합니다. MySQL에서 IP를 저장하는 방법과 호출하는 방법에 대해 알아보겠습니다. ▶︎ 준비사항 MySQL에서 IP를 저장하는 방법은 숫자형으로 저장이 됩니다. MySQL문서에서는 INT형보다는 INT UNSIGNED 컬럼을 사용할것을 권고하고 있습니다. create table addr(ip int(11) unsigned); ▶︎ 사용방법 INET_ATON(expr) 일발적인 IPv4 네트워크 주소 방식으로 표현된 ..