💾 DB 세션에 대해서 설명해주세요.

웹 개발의 측면에서 보는 세션이라고 함은 사용자와 웹 혹은 앱과의 사이에서 발생하는 상태 정보를 저장하고 유지하는 방법이라고 말합니다. 즉, 데이터베이스 접속을 시작으로 여러 데이터베이스에서 관련 작업을 수행한 후 접속을 종료하기까지 전체기간을 의미합니다. 이러한 세션은 유저가 로그인을 하면 생성이 되고 세션에 의해서 유저가 어떤 활동을 하는지 추적 및 확인을 할 수 있게 됩니다. 그리고, 특별한 요인에 의한 종료 혹은 로그아웃이 된것이 아니면 세션은 계속 서버에 남아있게 됩니다. 이 데이터 값에 대한 키 값(ID)은 클라이언트에 남겨져 저장됩니다.

그러나, 일반적으로 세션의 만료 시간이 지나면 해당 세션은 사용이 되지 않고 초기에 설정한 세션의 만료 조건에 따라 자동으로 제거되거나 주기적으로 세션을 직접 정리를 해줘야 합니다.

More Infos

• 🍪 Cookie
  웹 사이트에 접속할 때 서버에 의해 사용자의 컴퓨터에 저장되는 정보를 의미합니다. 이렇게 저장된 정보를 웹은 필요할 때 마다 재사용을 하게 됩니다.
  
  위 처럼 처음 접속하는 경우에는 클라이언트에서 요청을 하면 서버는 요청을 수행하고 클라이언트의 정보를 담은 쿠키를 생성하여 같이 보냅니다.
  
  그렇게 생긴 쿠키에 의해서 stateless을 해결하고 빠른 응답을 할 수 있게 됩니다. 이러한 쿠키는 클라이언트에서 데이터파일로써 생겨 키과 데이터 값을 모두 포함하기 때문에 스니핑의 위험에 노출이 될 수 있기 때문에 세션이 이러한 보안적 약점을 보완하여 준다고 할 수 있습니다.

---

🖥️ 트랜잭션에 대해 설명해주세요. & 트랜잭션의 성질 ACID에 대해서 설명해주세요.

Transaction은 작업의 완전성을 보장해 주는 것이다. 논리적인 작업 셋을 모두 완벽하게 처리하거나, 처리하지 못할 경우에는 원래의 상태로 복구하여 작업의 일부만 적용이 되는 Partial update 현상을 막아주는 기능입니다.

• 🔎 Transaction vs Lock
  서로 비슷한 개념 같지만 Lock은 예를들어 하나의 레코드를 여러 커넥션에서 동시에 변경하려고할 때 Lock이 없다면 해당 레코드는 어떻게 변경이 될지 예측할 수 없는 상태가 됩니다. 그래서 요청한 데이터에 대해서 한 시점에 하나의 커넥션만 변경할 수 있게 해주는 역할을 합니다. 이로써 데이터의 정합성을 보장하는 역할을 하게 됩니다. 이러한 과정에서 하나의 혹은 여러 트랜잭션 간의 작업 내용을 어떻게 공유하고 차단할 것인지를 결정하는 레벨을 의미하는 것이 격리 수준입니다.
  

🔎 More infos about Transaction

: 위에서 언급했듯이 하나의 논리적인 작업 셋을 하나 이상의 쿼리가 COMMIT을 실행 했을때 작업 셋 자체가 온전히 적용되거나 아무것도 적용되지 않아야함을 즉, Partial update 현상을 막아주는 것입니다. DB에서 발생하는 일련의 연산들을 하나의 논리적인 단위로 묶어서 원자성, 일관성, 독립성, 지속성의 ACID의 성질을 보장합니다.

1. 원자성(Atomicity) : 트랜잭션은 원자적이어야 하며, 모든 연산이 성공적으로 완료되거나 실패할 경우 이전 상태로 롤백되어야 합니다.

💡 이해가 되지 않기 때문에 더 구체적으로 작성하겠습니다. 트랜잭션을 설명할때의 원자성이라고 함은 진행과정에서 문제가 발생하여 연산이 종료가 되었을 경우에 중간에 어떠한 연산도 남아있지 않고 성공한 결과들까지 모조리 롤백 되어야 함을 의미합니다!

2. 일관성(Consistency) : 트랜잭션이 완료된 후에도 DB는 일관된 상태를 유지하여야한다.

💡 예를들어 음료를 주문하는 주문 트랜잭션이 실행된 후에 제품의 수량이 음수로 가서는 안된다. 예를들어 음료의 재고가 10개인데 15개를 주문을 시도할 경우에 거부되어야 함을 의미합니다.

3. 독립성(Isolation) : 동시에 실행되는 여러 트랜잭션은 각각 다른 트랜잭션의 연산에 영향을 받지 않아야 합니다.

💡 동시 주문 처리를 할때 동시에 실행이 되었다고 해도 각 트랜잭션은 서로에게 영향을 주지 않아야 합니다.

4. 지속성(Durability) : 트랜잭션이 완료된 후에는 그 결과가 영구적으로 저장되어야 하며, 시스템 장애가 발생해도 유지되어야 합니다.

💡 편의점에서 알바가 주문을 해야하는 상황에서 주문을 완료한 시점에서 컴퓨터의 오류로 재부팅이 되었을때 완료된 주문에 한에서는 관련 주문 정보가 DB에 남아 있어야 합니다. 즉, 다양한 장해 상황에서도 트랜잭션의 결과가 영구적으로 보존되어야 함을 의미합니다.

Added examples

게시판에 글을 저장하는 예시

1) 처리 시작
► 데이터 베이스 커넥션 생성
► 트랜젝션 시작
2) 사용자의 로그인 여부 확인
3) 사용자의 글쓰기 내용의 오류 여부 확인
4) 첨부로 업로드된 파일 확인 및 저장
5) 사용자의 입력 내용을 DBMS에 저장
6) 첨부 파일 정보를 DBMS에 저장
7) 저장된 내용 또는 기타 정보를 DBMS에서 조회
8) 게시물 등록에 대한 알림 메일 발송 🚨
9) 알림 메일 발송 이력을 DBMS에 저장
► 트랜잭션 종료(COMMIT)
► 데이터베이스 커넥션 반납
10) 처리 완료

위의 예시에서는 3가지 문제를 발견할 수 있다.

1. 실제로 DB Connection을 1번과 2번에 많이 구현하며 트랜잭션을 같이 시작하지만(START TRANSACTION) 커넥션은 소유하는 시간이 길어질수록 사용 가능한 여유 커넥션의 개수가 줄어들게 된다. 그렇기 때문에 불필요한 2,3번을 트랜잭션에 포함 시킬 필요가 없다.
2. 8번에서 메일 전송이나 FTP 파일 전송 작업 또는 네트워크를 통해 원격 서버와 통신하는 등과 같은 작업은 어떻게 해서든 DBMS의 트랜잭션 내에서 제거하는 것이 좋다. 만약, 프로그램이 실행되는 동안 메일 서버와 통신할 수 없는 상황이 발생한다면 웹 서버 뿐 아니라 DBMS 서버까지 위험해지는 상황이 발생할 수 있다.
3. 위 작업은 크게 4가지로 분류할 수 있다. 사용자가 입력한 정보를 저장하는 작업인 5,6번은 같이 하나의 트랜잭션으로 묶어야 하고, 7번 작업은 저장된 데이터의 단순 확인 및 조회이므로 트랜잭션에 포함할 필요는 없다. 그리고 9번 작업은 조금 성격이 다르기 때문에 이전 트랜잭션(5,6번)에 함께 묶지 않아도 무방할 수 있다.(업무 요건에 따라 달라 질 수 있다.)

게시판에 글을 저장하는 예시 - 재설계
1) 처리 시작
2) 사용자의 로그인 여부 확인
3) 사용자의 글쓰기 내용의 오류 여부 확인
4) 첨부로 업로드된 파일 확인 및 저장
► 데이터 베이스 커넥션 생성
5) 사용자의 입력 내용을 DBMS에 저장
6) 첨부 파일 정보를 DBMS에 저장
► 트랜잭션 종료(COMMIT)
7) 저장된 내용 또는 기타 정보를 DBMS에서 조회
8) 게시물 등록에 대한 알림 메일 발송
► 트랜젝션 시작
9) 알림 메일 발송 이력을 DBMS에 저장
► 트랜잭션 종료(COMMIT)
► 데이터베이스 커넥션 반납
10) 처리 완료

📮 Commit & Rollback & Auto Commit 에 대해서 설명해주세요.

Commit

Commit 연산은 모든 작업들을 정상적으로 처리하겠다고 확정하는 명령어로서, 처리과정을 DB에 영구적으로 저장하는 것입니다. 그래서 이러한 Commit 연산이 시작된 시점에서 Update문을 통하면서 삭제와 재 삽입의 과정을 제대로 거치게 되면 영구저장이 되는 것입니다.

Rollback

RollBack 연산은 작업 중 문제가 발생하여 트랜잭션의 처리과정에서 발생한 변경사항을 취소하는 명령어입니다. 트랜잭션의 원자성을 위한 작업을 위해서 사용되는 기능입니다. 즉 연산 과정에서 오류가 발생하게 되면 모든 것을 취소하고 바로 전의 작업 즉 이전 Commit한 곳까지 복구를 하게 됩니다.

AutoCommit

사용자가 따로 Commit 연산을 실행하지 않아도 자동으로 모든 명령들이 Commit 되어 즉시 반영되는 명령어 입니다. 대부분의 Laptop에서 이것이 활성화되어 있는데 이것을 되도록이면 해제하여 사용하는 것이 좋다. 왜냐하면 1,2,3 이라는 작업을 할 때 오토커밋이 활성화된 상태에서 1번을 수행하였으나 2,3번에서 에러가 뜬다면 다시 전체적인 작업을 손봐야하는데 되돌리지 못해버리는 불상사가 발생할 수 있다.

show variables like `autocommit%`;

위의 구문을 입력했을때 ON이 나오는 경우는 지금 활성화 상태이기 때문에

SET AUTOCOMMIT = TRUE;  --> 설정
SET AUTOCOMMIT = FALSE; --> 해제

이러한 Statement를 사용하여 설정을 바꿔줘야한다.

ADVANTAGES OF COMMIT & ROLLBACK

1. 데이터 무결성이 보장된다.
2. 영구적으로 변경하기 전에 데이터의 변경사항을 확인 할 수 있다.
3. 논리적으로 연관된 작업을 그룹화 할 수 있다.

---

🖥️ 트랜잭션 격리 수준이 뭘까요?

Transaction Isolation level 은 여러 트랜잭션이 동시에 처리될 때 특정 트랜잭션이 다른 트랜잭션에서 변경하거나 조회하는 데이터를 볼 수 있게 허용할지 말지를 결정하는 것입니다. 이러한 격리 수준은 크게 4가지로 나뉘게 됩니다. 격리 수준이 뒤로 가면서 데이터 고립 정도가 높아지며, 동시 처리 성능도 떨어지는 것이 일반적이라고 볼 수 있습니다. 수준이 SERIALIZABLE이 아니라면 크게 그전에서는 성능 저하가 발생하지 않습니다.

• 트랜잭션 격리 수준 READ UNCOMMITTIED에 대해서 설명해주세요.
  READ UNCOMIMMITTED 는 일반적으로 온라인 서비스 용도의 데이터베이스에 많이 사용됩니다.

  

  위의 사진은 READ UNCOMMITTED의 예시입니다. 사용자 B가 변경된 내용을 커밋하기 전에 사용자 B가 emp_no = 500000을 검색하고 있습니다. 하지만 사용자 B가 사용자 A가 커밋을 하기도 전 상태에서도 조회할 수 있습니다. 그런데 여기서 문제는 사용자 A가 알 수 없는 에로로 인해 롤백을 한다고 해도 사용자 B는 여전히 사용자 A에 대한 테이블을 똑같이 볼 것입니다. 이처럼 어떤 트랜잭션에서 처리한 작업이 완료되지 않았는데도 다른 트랜잭션에서 볼 수 있는 현상을 Dirty Read라고 합니다. 이러한 더티 리드가 허용되는 격리 수준이 READ UNCOMMITTED입니다. 이 Isolation level은 정합성에 문제가 많은 수준입니다.

• 트랜잭션 격리 수준 READ COMMITTED에 대해서 설명해주세요.
  READ COMMITTED 는 오라클 DBMS에서 기본으로 사용되는 격리 수준이며, 온라인 서비스에서 가장 많이 선택되는 격리 수준입니다. 이 레벨에서는 Dirty Read가 발생하지 않습니다. 어떤 트랜잭션에서 데이터를 변경했더라도 커밋이 완료된 데이터만 다른 트랜잭션에서 조회할 수 있기 떄문입니다.

  

  위 사진에서는 사용자 A는 emp_no = 500000인 사원의 first_name을 Toto로 변경 했는데 이때 새로운 값인 Toto는 즉시 기록이 되고 이전 값은 Undo 영역으로 백업됩니다. 하지만 커밋을 수행하기 전에 사용자 B가 SELECT를 하여 조회를 할 경우 Undo 영역에서 이전 값을 불러와 표시하게 됩니다. 하지만 해당 수준에서 NON_REPEATABLE READ라는 부정합의 문제가 발생할 수 있는데, 사용자 A가 값을 변경하고 커밋을 하기 전에 사용자 B가 검색을 하면 해당 레코드를 찾지 못할 것입니다. 이렇게 커밋을 하기 전 후의 결과가 다르게 나오기 때문에 트랜잭션의 정합성에 어긋난다고 할 수 있습니다.

• 트랜잭션 격리 수준 REPEATABLE READ에 대해서 설명해주세요.
  REPEATABLE READ는 MySQL의 INNODB 엔진에서 기본으로 사용되는 격리 수준입니다. 이러한 REPEATABLE READ는 MVCC(Multi Version Concurrency Control)을 위해 언두 영역에 백업된 이전 데이터를 이용하여 동일 트랜잭션 내에서 동일한 결과를 보여줄 수 있게 보장합니다. READ COMMITTED도 MVCC를 사용하여 COMMIT되기 전의 데이터를 보여주지만, 언두 영역에 백업된 레코드의 여러 버전 가운데 몇 번째 이전 버전까지 찾아 들어가느냐에서 차이가 존재한다. 바이너리 로그를 가진 MySQL 서버에서는 최소 REPEATABLE READ 격리 수준 이상을 사용해야 합니다. 이때는 READ COMMITTED Isolation level에서 발생하는 NON-REPEATABLE READ 문제가 발생하지 않습니다.
  

🚨More infos

모든 InnoDB의 트랜잭션은 고유한 번호를 가지며, 언두 영역에 백업된 모든 레코드에는 변경을 발생시킨 트랜잭션의 번호가 포함되어 있습니다. 만약 이러한 백업 데이터를 InnoDB 엔진 자체적으로 불필요함을 느끼면 주기적으로 삭제되며 현재의 REPEATABLE READ 수준에서는 MVCC를 보장하기 위해서 실행 중인 트랜잭션 가운데 가장 오래된 트랜잭션 번호보다 앞선 언두 영역의 데이터는 삭제 할 수 없습니다. 그래서 위 사진을 보면 사용자 A의 TRX_ID = 12이고 사용자 B의 TRX_ID = 10입니다. 그렇기 때문에 자기 보다 아래인 트랜잭션의 쿼리만을 볼 수 있게 되는 상황이기 때문에 사용자 B는 계속해서 같은 결과를 보게 됩니다.

위에서 배운 것 처럼 위 사진의 경우를 따랐을때, 사용자 B가 보는 테이블에는 처럼과 같은 결과가 나와야하는데 다른 결과를 보이고 있습니다. 이렇게 다른 트랜잭션에서 수행한 변경 작업에 의해 레코드가 보였다 안 보였다 하는 현상을 PHANTOM READ / PHANTOM ROW라고 합니다. SELECT ~ UPDATE는 언두 영역의 쓰기 잠금을 할 수 없기 때문에 SHARE MODE로 조회되는 레코드는 현재의 레코드 값을 가져오게 됩니다.

• 트랜잭션 격리 수준 SERIALIZABLE에 대해서 설명해주세요.
  가장 단순한 격리 수준이며 동시에 가장 엄격한 격리 수준으로 InnoDB table에서 기본적으로 순수한 SELECT 작업(INSERT ~~ SELECT, CREATE TABLE ~~ AS SELECT ~~ 가 아닌)은 아무런 레코드 잠금도 설정하지 않고 실행됩니다. 트랜잭션의 격리수준이 SERIALIZABLE로 설정되게 되면 읽기 작업도 공유 잠금(읽기 잠금)을 획득해야만 하며 동시에 다른 ㅌ트랜잭션은 그러한 레코드를 변경하지 못하게 됩니다. 즉, 한 트랜잭션에서 읽고 쓰는 레코드를 다른 트랜잭션에서는 절대 접근 할 수 없음을 말합니다. 그렇기 때문에 PHANTOM READ 현상은 발생하지 않습니다.

💡 What is a MVCC(다중 동시성 제어)?

일반적으로 레코드 레벨의 트랜잭션을 지원하는 DBMS가 제공하는 기능이며, MVCC의 가장 큰 목적은 잠금을 사용하지 않는 일관된 읽기를 제공하는데 있습니다. 이러한 기능을 InnoDB에서는 Undo log를 통해서 구현 했습니다. 즉, 격리 수준에 따라 InnoDB의 버퍼 풀이나 데이터 파일에 있는 내용 대신 변경되기 이전의 내용을 보관하고 잇는 언두 영역의 데이터를 반환할지를 정하는 DBMS의 과정을 MVCC라고 합니다.

---

DB 동시성 제어에 대해서 설명해주세요.

Concurrency Control이란 동시에 실행되는 여러 개의 트랜잭션이 작업을 성공적으로 마칠 수 있도록 트랜잭션의 실행 순서를 제어하는 기법입니다. 이러한 동시성 제어의 정의는 아래와 같습니다.

• 다중 사용자 환경을 지원하는 DBMS에서 여러 트랜잭션들이 성공적으로 동시에 실행될 수 있도록 지원하는 기능
• 다중 사용자 환경을 지원하는 DB의 경우 필수적으로 지원해야 하는 병행제어 기능
• 트랜잭션의 직렬화 수행 보장
  

이렇게 직렬화를 하여 여러 트랜잭션이 동시에 실행이 되는것을 피하고 데드락을 방지할 수 있습니다. 위의 과정을 거쳐 트랜잭션의 직렬성 보장하고 공유도를 최대로 올리고 응답 시간을 최소로 하여 시스템 활동을 최대로 보장합니다. 최종적으로 데이터의 무결성 및 일관성을 보장한다.

⚠️ more info & 갱신 손실 문제.

• 동시성 제어의 종류

1. Locking : 트랜잭션이 데이터에 lock을 설정하면 다른 트랜잭션은 해당 데이터에 대해 unlock이 될때 까지 접근/수정/삭제가 불가능합니다. 즉, 트랜잭샌이 사용하는 레코드에 대해여 Mutual Exclusive 기능을 제공합니다.
2. Timestamp : 시스템에서 생성하는 고유 번호인 타임스탬프를 트랜잭션에 부여함으로써 트랜잭션간의 접근 순서를 미리 정합니다.
3. Validation : 먼저 트랜잭션을 수행하고 트랜잭션을 종료할 때 적합성을 검증하여 데이터베이스에 최종 반영합니다.

• 동시성 제어를 하지 않았을 경우의 문제점

1. Lost Update(갱신 손실) : 하나의 트랜잭션이 갱신한 내용을 다른 트랜잭션이 덮어씀으로써 갱신이 무효화가 되는 것을 의미합니다. 두 개 이상의 트랜잭션이 동시에 갱신할때 발생합니다. - READ UNCOMMITTED
2. Dirty Read(현황 파악 오류) : 읽기 작업을 하는 트랜잭션 1이 쓰기 작업을 하는 트랜잭션 2가 작업한 중간 데이터를 읽기 때문에 발생하는 문제이다. 이로인해서 트랜잭션 1의 작업을 RollBack하게 되고 무효가 된 데이터를 읽게 되어 잘못된 결과를 도출하게 됩니다. - READ UNCOMMITTED
3. Inconsistency(모순성) : 다른 트랜잭션들이 해당 항목 값을 갱신하는 동안 한 트랜잭션이 두 개의 항목 값 중 어떤 것은 갱신되기 전의 값을 읽고 다른 것은 갱신된 후의 값을 일게 되어 데이터의 불일치가 발생하게 됩니다. - READ COMMITTED
4. Cascading Rollback(연쇄 복귀) : 두 트랜잭션이 동일한 데이터 내용을 접근할 때 발생하는 문제입니다. 한 트랜잭션이 데이터를 생신한 다음 샐패하여 Rollback 연산을 수향하는 과정에서 갱신과 RollBack 연산을 실행하고 있는 사이에 해당 데이터를 읽어서 사용할때 발생할 수 있는 문제입니다.

동시성 문제	격리 수준	예시	해결 방안	주의 사항
Lost Update	READ COMMITTED	높음	Locks 사용, OCC	데드락 발생 가능성 주의
Dirty Read	READ UNCOMMITTED	높음	격리 수준 높이기	불필요한 락 발생 주의
Inconsistency	SERIALIZABLE	높음	격리 수준 높이기	성능 저하 주의
Cascading Rollback	SERIALIZABLE	높음	Nested Transactions 사용	성능 저하 주의

🤥 OCC(Optimistic Concurrency Control) : 트랜잭션 1이 데이터를 읽은 후, 갱신 시에 해당 데이터의 버전을 확인하고, 다른 트랜잭션이 이미 갱신한 경우 예외를 발생시켜 갱신을 중단할 수 있습니다.
🤥 Nested Transaction : 일부 DBMS에서 지원하는 경우, 중첩 트랜잭션을 사용하여 부분적인 롤백을 수행하고, 필요한 경우에만 전체 트랜잭션을 롤백할 수 있는 기능입니다.

---

DB 락에 대해서 설명해주세요.

MySQL에서 사용되는 잠금은 크게 스토리지 엔진 레벨과 MySQL 엔진 레벨로 나눌 수 있습니다.

MySQL 엔진 레벨의 잠금

MySQL 엔진 레벨의 잠금은 모든 스토리지 엔진에 영향을 미치지만, 스토리지 엔진 레벨의 잠금은 스토리지 엔진 간 상호 영향을 미치지는 않습니다. MySQL 락의 종류는 테이블의 구조를 잠그는 메타데이터 락 그리고 사용자의 필요에 맞게 사용할 수 있는 네임드 락, 또한 SELECT를 제외한 나머지 DML, DDL 문장을 실행하는 경우에 글로벌 락이 해제 될때 까지 대기 상태로 하게 만드는 글로벌 락 기능도 함께 제공합니다.

InnoDB 스토리지 레벨의 잠금

InnoDB 스토리지 엔진은 MySQL에서 제공하는 잠금과는 별개로 스토리지 엔진 내부에서 레코드 기반의 잠금 방식을 탑재하고 있습니다. 이러한 잠금 방식 때문에 MyISAM보다는 훨씬 뛰어난 동시성 처리를 제공할 수 있다고 합니다. 이러한 InnoDB 스토리지 엔진에서의 락의 종류는 인덱스의 레코드 자체 만을 잠그는 Record Lock 그리고 레코드 자체가 아닌 레코드와 바로 인접한 레코드 사이의 간격만을 잠그는 Gab Lock, 레코드 락과 갭 락을 합쳐 놓은 형태의 잠금을 Nexy Key Lock이라고 합니다. 그리고 마지막으로 Auto_Increment Lock이 있습니다. 자동 증사 락은 테이블 수준의 잠금을 진행할 때 사용합니다.

---

🔐 DB 데드락 & DB 회복에 대해서 설명해주세요.

DB DEAD-LOCK

두 개 이상의 트랜잭션이 각각 자신의 데이터에 대하여 락을 획득하고 상대방 데이터에 대하여 락을 요청하면 무한 대기 상태에 빠질 수 있는 현상을 말합니다. (서로 락을 걸어주다가 무한 대기에 빠지는 현상) 이때, 보통 DBMS가 트랜잭션의 둘 중 하나는 강제로 중지시켜 하나의 트랜잭션은 정상 동작을 하고 중지된 트랜잭션은 롤백되게 끔 만듭니다.

DB RECOVERY

위와 같은 장애 유형으로 문제가 발생할 수 있는데 이때, 데이터베이스를 장애가 발생했던 이전의 상태로 복구 시켜서 일관된 데이터베이스 상태를 만드는 것은 DB 회복이라고 합니다. 회복을 위한 데이터 복사본을 만드는 방법에는 덤프, 로그가 있습니다.

• 덤프는 가장 기본적인 기법으로 일정 주기로 원본의 데이터베이스의 모든 내용을 다른 저장장치에 복사하는 것입니다.
• 로그는 변경 이전의 데이터베이스를 기준으로 변경 연산이 발생할때 마다 로그 파일을 작성하여 기록하고, 회복할 때 로그에 적힌 내용을 사용하여 복원하는 방법입니다. 이렇게 만들어지는 파일을 로그 파일이라고 합니다. (START, INSERT, UPDATE, DELETE, ABORT, COMMIT 등의 트랜잭션 연산 타입)
  

---

↺REDO, ↻UNDO에 대해서 설명해주세요.

DBMS는 트랜잭션이 종료되었는지 혹은 중단 되었는지 여부를 판단하여 종료된 경우에는 종료를 확정하기 위해 REDO(재실행)을 하고 중단된 경우에는 없던 일로 되돌리기 위해 UNDO(취소)를 진행합니다.

• REDO 는 장애가 발생한 후 시스템을 다시 가동 했을 때, 로그 파일에 트랜잭션의 시작이 있고 종료(COMMIT)이 있는 경우 로그를 보면서 트랜잭션이 변경한 내용을 다시 기록하는 과정입니다. 즉, log 파일에 기록된 트랜잭션의 변경 사항을 다시 적용 하여 데이터베이스가 장애 등으로 인해 손상이 된 경우 복구 하는 과정입니다.
• UNDO 는 장애 발생 후 시스템을 재가동 했을 때, 로그 파일에 트랜잭션의 시작만 있고 COMMIT이 없는 경우 완료하지 못했지만 버퍼의 변경 내용이 데이터베이스에 기록되어 있을 가능성이 있기 때문에 로그를 보면서 트랜잭션이 변경한 내용을 원상복구 시키는 과정입니다.(트랜잭션이 시작을 하면 변경연산에 대해서 실시간 반영을 하지는 않지만 중간까지 부분연산을 완료하면 실제 DB에 반영을 시킵니다. 이럴 가능성을 보고 UNDO를 하는 것입니다.) 즉, 로그 파일에 기록된 트랜잭션의 변경 사항을 취소하여 트랜잭션이 실패하거나 롤백되어야 하는 경우에 데이터베이스를 이전 상태로 롤백하는 경우에 사용을 하게 됩니다.
  
  

체크포인트 회복 기법에 대해서 설명해주세요.

체크포인트 회복 기법이란 로그는 그대로 기록을 유지하면서, 회복관리자가 정하는 일정한 시간 간격으로 검사 시점을 생성하는 것을 의미합니다. 이를 사용하여 회복 시 많은 양의 로그를 검색하고 갱신하는 시간을 줄이고 기법을 더 단순화 시킬 수 있습니다.

MySQL InnoDB의 기본 트랜잭션 고립 수준은 뭘까요?

InnoDB의 기본 고립 수준은 REPEATABLE READ입니다. 이는 트랜잭션 내에서는 동인한 쿼리를 실해해도 결과가 항상 일관성을 유지한다는 의미를 가지고 있습니다. InnoDB의 스토리지 엔진은 트랜잭션이 롤백 될 가능성에 대비하기 위해 변경 되지 전 레코드를 언두 공간에 백업해두고 실제 레코드의 값을 변경합니다. 이러한 변경 방법을 MVCC라고 합니다.

References
1. DB Session
2. Session & Cookie
3. Definitions of Commit & Rollback
4. AutoCommit
5. 동시성 제어
6. DB의 전반적인 이해
7. Checkpoint DB Recovery