Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
Tags
- 자료구조
- PYTHON
- TCP
- airflow.cfg
- 컴퓨터 네트워크
- Docker
- 컴퓨터네트워크
- 데이터 파이프라인
- linux
- 데이터베이스
- redshift
- 데이터 엔지니어링
- 데이터엔지니어링
- TIL
- 데브코스
- airflow
- sql
- http
- 파이썬
- 데이터 웨어하우스
- Django
- HADOOP
- Go
- 정리
- 운영체제
- 가상환경
- 종류
- AWS
- S3
- dockerfile
Archives
- Today
- Total
홍카나의 공부방
[데이터베이스] 트랜잭션 - 장애와 회복, 로그 회복 기법 본문
DB - 디스크와 메인 메모리
- 일반적으로 데이터베이스의 데이터는 디스크에 상주한다.
- 그래서 트랜잭션이 데이터베이스의 데이터를 처리하기 위해서는 데이터를 디스크에서 메인 메모리로 가져와서 연산을 진행한 다음 그 결과를 디스크로 보내는 작업이 필요하다.
- 디스크에서 메모리로 데이터를 읽어들이는 input() 연산의 경우, 연산을 뒤로 미루지 않는다. 예를 들어 우리가 SELECT 문으로 디스크에 있는 데이터를 조회해야 할 때, output() 연산처럼 이를 미루지 않고 바로 읽어들인다는 것(On-demand)이다.
- 단, 메모리에서 디스크로 데이터를 저장하는 output() 연산의 경우, 그 즉시 일어나지 않고 DBMS의 버퍼 관리자(Buffer Manager)가 처리한다.
DB 장애
- 모순의 이유로 DB에서 장애가 발생할 수 있다. 위 예시에서 트랜잭션 실행 시 장애가 발생할 수도 있다.
- 만약 데이터 A에 대해서 output() 연산이 완료되고, B도 output()을 진행하려는 사이에 장애가 발생하여 작업이 완료되지 못하면, 디스크의 데이터와 메모리의 데이터 값이 일치하지 않을 것이다. 즉, inconsistency가 발생하는 것이다.
DB 회복
- 장애가 발생했을 때 DB를 이전의 상태로 복구시킬 수 있다.
- 회복의 기본 원리는 중복(redundancy)이다. 회복에서는 덤프 방법이나 로그 데이터를 이용하는데, 후자는 데이터베이스에서 변경 연산이 실행될 때마다 데이터를 변경하기 이전 값과 변경된 값을 별도의 파일에 기록하는 방법이다.
- 위 그림처럼 로그 데이터를 저장하는 별도의 파일이 있기 때문에, 이를 기반으로 DB를 recovery하게 된다.
- 회복에는 redo(재실행) 연산과 undo(취소)연산이 있다. undo는 말 그대로 예전 상태로 그냥 연산을 싹 다 취소해서 복구하는 거고, redo는 최근에 저장한 DB 복사본을 가져온 후, 로그를 이용하여 모든 연산을 재실행하여 복구하는 것.
- 로그 회복 기법을 본격적으로 살펴보겠다.
로그 파일
- 로그 파일은 데이터를 변경하기 이전의 값과, 변경한 이후의 값을 기록한 파일이다.
- 레코드 단위로 트랜잭션 수행과 동시에 기록된다.
- 로그 레코드는 <트랜잭션 id, 명령>으로 보통 구성되는데, 위 그림에서는 start로 트랜잭션 1번이 시작되었다는 것과 commit으로 완료되었다는 것. 그리고 X, Y 변수의 변경 값, 이전 값이 동시에 기록되고 있다.
- DB 로그 파일은 새로운 dump가 완료되었을 때, 상황에 따라 이전 로그 파일을 삭제하면 된다.
로그 회복 기법 - 지연 갱신
- 트랜잭션이 '부분 완료' 상태가 될 때까지는 output()연산을 지연하는 방법이다.
- 즉, 우리가 통상적으로 트랜잭션이 완료되었다고 여길 때까지 DB를 갱신하지 않는 것이다.
- 트랜잭션 내 연산이 진행되는 '활동' 상태에는 변경 결과를 로그 파일에만 기록한다.
- <Ti, commit>를 포함하는 로그 레코드를 로그 파일에 기록한 뒤, DB를 갱신하고 "완료"상태로 간다.
- 만약 트랜잭션 수행시 장애가 발생해도 DB는 undo 연산을 할 필요가 없다. 로그 내용만 무시하고 버리면 된다. 지연 갱신 방법을 이용했기 때문에 트랜잭션을 수행할 때 DB에 있는 레코드 값이 변경되지 않았기 때문이다.
- 트랜잭션이 모두 수행되고 commit이 된 상태에서 장애가 발생한다면, 로그 내용을 redo해서 DB를 갱신을 시도한다.
- undo가 아니라 redo 연산을 해야 하는 이유는 output() 연산이 됐는지 안됐는지 확실하게 모르기 때문이다. 트랜잭션이 commit 됐어도 DB에 값을 갱신하는 output()은 연산은 언제 될지 모르기 때문에 redo를 해야 한다.
- 지연 갱신 기법에는 로그 데이터에 예전 데이터 값이 필요 없다. undo를 안하기 때문에, 예전 상태가 필요 없다.
로그 회복 기법 - 즉시 갱신
- 트랜잭션 '진행' 상태 중 변경 연산의 결과를 DB에 그대로 반영한다.
- 변경 내용을 로그 파일에 기록한 후, 해당 output() 연산을 즉시 요청한다.
- 즉, write() 연산을 하는 즉시 output() 연산을 요청한다. ( 물론 즉시 output()이 실행되는지는 알 수 없다. )
- 그래서 output() 요청이 commit()이 완료되기 전에 진행될 수도 있기 때문에, 트랜잭션 수행 중 장애가 발생할 경우 안전한 회복을 위하여 undo 연산을 할 수도 있다. 물론 장애 발생 시점에 따라 redo를 실행할 수 있다.
- DBMS는 즉시 갱신 기법과 지연 갱신 기법 중 하나를 사용하게 된다.
검사 시점 회복
- 체크포인트를 만들어서, 체크포인트 이전까지 진행한 작업 사항에 대하여 다음의 작업들을 수행한다.
- 1) 메인 메모리(로그 버퍼)에 있는 모든 로그 레코드를 디스크에 있는 로그 파일에 기록한다.
- 2) 메인 메모리(DB 버퍼)에 있는 모든 변경 연산의 결과를 디스크에 있는 DB에 반영한다.
- 3) 검사 시점을 표현하는 <checkpoint L> 로그 레코드를 로그 파일에 기록한다.
- 단, 언제나 로그가 먼저 내려간다!
- 장애 발생 시 검사 시점 이후의 트랜잭션에만 회복 작업을 수행한다. redo에서 유용하다.
- 작업 범위가 한정되어 회복 작업 시간이 단축될 수 있다.
반응형
'Data Engineering > Database' 카테고리의 다른 글
[SQL] MySQL : 연월일 중 월을 표현하고 싶을 때 (DATE_FORMAT) (0) | 2023.05.28 |
---|---|
[데이터베이스] 정규화, 함수 종속 관계, 정규형 (0) | 2023.05.27 |
[데이터베이스] 트랜잭션 - ACID, 연산, State (0) | 2023.05.25 |
[데이터베이스] 트리거(Trigger)에 대하여 - AWS RDS (0) | 2023.05.20 |
[데이터베이스] 삭제 : DELETE vs DROP vs TRUNCATE (0) | 2023.05.20 |