Skip to content

2조 240821 트랜잭션 학습

Jump to bottom
bellringstar edited this page Aug 21, 2024 · 7 revisions

트랜잭션 isolation level

출처

  1. MySQL 공식 문서 (https://dev.mysql.com/doc/)

1. 트랜잭션 격리 수준의 정의

트랜잭션 격리 수준은 동시에 실행되는 여러 트랜잭션들 사이의 상호작용을 제어하는 메커니즘입니다. 이는 데이터의 일관성과 동시성 사이의 균형을 조절합니다.

2. 트랜잭션 격리 수준의 종류

SQL 표준(ANSI/ISO SQL)에서는 네 가지 트랜잭션 격리 수준을 정의하고 있습니다:

  1. READ UNCOMMITTED
  2. READ COMMITTED
  3. REPEATABLE READ
  4. SERIALIZABLE

MySQL의 InnoDB 스토리지 엔진은 이 네 가지 격리 수준을 모두 지원합니다.

3. 각 격리 수준 상세 설명

3.1 READ UNCOMMITTED

이 수준은 가장 낮은 격리 수준입니다.

  • 특징: 트랜잭션이 커밋되지 않은 데이터를 읽을 수 있습니다.
  • 장점: 동시성이 매우 높습니다.
  • 단점: Dirty Read, Non-Repeatable Read, Phantom Read 등의 문제가 발생할 수 있습니다.

Q: Dirty Read란 무엇이며, 어떤 문제를 일으킬 수 있나요?

A: Dirty Read는 한 트랜잭션이 아직 커밋되지 않은 다른 트랜잭션의 데이터를 읽는 현상입니다. 이는 다음과 같은 문제를 일으킬 수 있습니다:

  1. 데이터 불일치: 읽은 데이터가 나중에 롤백될 수 있어 일관성이 없는 데이터를 사용하게 됩니다.
  2. 비즈니스 로직 오류: 잘못된 데이터를 기반으로 의사결정을 내릴 수 있습니다.
  3. 데이터 무결성 손상: Dirty Read를 기반으로 다른 데이터를 수정하면 전체 데이터베이스의 무결성이 손상될 수 있습니다.

3.2 READ COMMITTED

이 수준은 대부분의 데이터베이스 시스템의 기본 격리 수준입니다.

  • 특징: 커밋된 데이터만 읽을 수 있습니다.
  • 장점: Dirty Read 문제가 발생하지 않습니다.
  • 단점: Non-Repeatable Read와 Phantom Read 문제가 여전히 발생할 수 있습니다.

Q: Non-Repeatable Read 현상을 예를 들어 설명해주세요.

A: Non-Repeatable Read는 한 트랜잭션 내에서 같은 데이터를 두 번 읽었을 때 그 결과가 다른 현상을 말합니다. 예를 들어:

  1. 트랜잭션 A가 특정 행을 읽습니다 (예: 사용자의 잔액이 1000원).
  2. 트랜잭션 B가 같은 행을 수정하고 커밋합니다 (예: 잔액을 500원으로 수정).
  3. 트랜잭션 A가 같은 행을 다시 읽으면 다른 값(500원)을 얻게 됩니다.

이는 데이터 분석이나 보고서 생성 시 일관성 없는 결과를 초래할 수 있습니다.

3.3 REPEATABLE READ

이는 MySQL의 기본 격리 수준입니다.

  • 특징: 트랜잭션이 읽은 데이터는 트랜잭션이 완료될 때까지 다른 트랜잭션에 의해 변경되지 않습니다.
  • 장점: Dirty Read와 Non-Repeatable Read 문제가 발생하지 않습니다.
  • 단점: Phantom Read 문제가 여전히 발생할 수 있습니다. (그러나 MySQL의 InnoDB에서는 특별한 방식으로 Phantom Read도 방지합니다)

Q: MySQL의 InnoDB에서는 REPEATABLE READ 수준에서 어떻게 Phantom Read를 방지하나요?

A: MySQL의 InnoDB는 다음과 같은 방식으로 REPEATABLE READ 수준에서 Phantom Read를 방지합니다:

  1. MVCC (Multi-Version Concurrency Control): InnoDB는 각 트랜잭션에 대해 일관된 읽기 뷰를 제공합니다. 트랜잭션이 시작될 때의 데이터베이스 상태를 기반으로 이 뷰를 생성합니다.
  2. 넥스트-키 잠금 (Next-Key Locking): InnoDB는 인덱스 레코드에 대한 잠금뿐만 아니라, 인덱스 레코드 사이의 "간격"에 대해서도 잠금을 설정합니다. 이를 통해 새로운 행이 삽입되는 것을 방지합니다.
  3. 갭 락 넥스트-키 잠금의 일환으로, 갭 락은 인덱스의 특정 위치와 그 다음 위치 사이의 ‘갭’을 잠그는 역할을 합니다. 이를 통해 쿼리가 실행 중인 트랜잭션 내에서 특정 범위에 새로운 데이터가 삽입되는 것을 방지합니다.
  4. 인덱스 조건 푸시다운 (Index Condition Pushdown): 쿼리 최적화 기술로, 불필요한 행의 검색을 줄여 Phantom Read의 가능성을 낮춥니다.

이러한 기술들의 조합으로 InnoDB는 REPEATABLE READ 수준에서도 높은 수준의 일관성을 제공합니다.

3.4 SERIALIZABLE

이는 가장 높은 격리 수준입니다.

  • 특징: 트랜잭션들이 순차적으로 실행되는 것처럼 동작합니다.
  • 장점: 모든 동시성 문제 (Dirty Read, Non-Repeatable Read, Phantom Read)를 방지합니다.
  • 단점: 동시성이 매우 낮아져 성능이 저하될 수 있습니다.

Q: SERIALIZABLE 격리 수준이 필요한 상황은 어떤 경우인가요?

A: SERIALIZABLE 격리 수준이 필요한 상황은 다음과 같습니다:

  1. 금융 거래: 은행 송금, 주식 거래 등 높은 정확성이 요구되는 금융 작업
  2. 재고 관리: 동시에 여러 주문이 처리될 때 재고의 정확성을 유지해야 하는 경우
  3. 예약 시스템: 항공권, 호텔 예약 등 동시 접근으로 인한 충돌을 완전히 방지해야 하는 경우
  4. 법적 요구사항: 데이터의 완전한 일관성이 법적으로 요구되는 경우

그러나 이 수준을 사용할 때는 성능 저하를 고려해야 하며, 가능한 경우 더 낮은 격리 수준과 애플리케이션 레벨의 로직을 조합하여 동일한 효과를 달성하는 것이 좋습니다.

4. 격리 수준 선택 시 고려사항

트랜잭션 격리 수준을 선택할 때는 다음 사항을 고려해야 합니다:

  1. 데이터 일관성 요구사항
  2. 동시성 및 성능 요구사항
  3. 애플리케이션의 특성
  4. 하드웨어 리소스

Q: 어떤 경우에 READ COMMITTED를 선택하고, 어떤 경우에 REPEATABLE READ를 선택해야 할까요?

A: READ COMMITTED와 REPEATABLE READ 중 선택할 때 고려해야 할 점은 다음과 같습니다:

READ COMMITTED 선택 시:

  1. 높은 동시성이 필요한 경우
  2. 실시간 데이터 업데이트가 중요한 경우 (예: 실시간 재고 관리)
  3. 긴 트랜잭션이 자주 발생하는 경우
  4. Non-Repeatable Read가 애플리케이션 로직에 큰 영향을 미치지 않는 경우

REPEATABLE READ 선택 시:

  1. 트랜잭션 내에서 일관된 데이터 읽기가 중요한 경우
  2. 보고서 생성이나 데이터 분석 작업이 많은 경우
  3. Non-Repeatable Read가 비즈니스 로직에 심각한 문제를 일으킬 수 있는 경우
  4. Phantom Read 방지가 필요한 경우 (MySQL InnoDB의 경우)

최종적인 선택은 애플리케이션의 특성과 요구사항을 면밀히 분석한 후 결정해야 합니다.

5. MySQL에서의 트랜잭션 격리 수준 설정

MySQL에서는 다음과 같이 트랜잭션 격리 수준을 설정할 수 있습니다:

SET [GLOBAL | SESSION] TRANSACTION ISOLATION LEVEL {
    READ UNCOMMITTED
  | READ COMMITTED
  | REPEATABLE READ
  | SERIALIZABLE
}

Q: GLOBAL과 SESSION의 차이점은 무엇인가요?

A: GLOBAL과 SESSION의 차이점은 다음과 같습니다:

  1. GLOBAL:
    • 서버 전체에 적용됩니다.
    • 새로운 연결에만 영향을 미칩니다.
    • 관리자 권한이 필요합니다.
    • 예: SET GLOBAL TRANSACTION ISOLATION LEVEL READ COMMITTED;
  2. SESSION:
    • 현재 세션에만 적용됩니다.
    • 즉시 적용되며, 현재 연결에서만 유효합니다.
    • 일반 사용자도 설정 가능합니다.
    • 예: SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;

일반적으로 특정 작업이나 트랜잭션에 대해 일시적으로 격리 수준을 변경할 때는 SESSION을 사용하고, 서버의 기본 동작을 변경하려면 GLOBAL을 사용합니다.

6. Consistent Nonlocking Reads in MySQL InnoDB

MySQL의 InnoDB 스토리지 엔진은 Consistent Nonlocking Reads라는 중요한 기능을 제공합니다. 이 기능은 트랜잭션 격리 수준, 특히 REPEATABLE READ와 밀접한 관련이 있습니다.

6.1 Consistent Nonlocking Reads의 정의

Consistent Nonlocking Reads는 InnoDB가 다중 버전 동시성 제어(MVCC)를 사용하여 구현하는 읽기 작업입니다. 이 방식을 통해 InnoDB는 읽기 작업에 대해 잠금을 설정하지 않고도 일관된 데이터를 제공할 수 있습니다.

6.2 작동 원리

  1. 스냅샷 생성: 트랜잭션이 시작될 때, InnoDB는 데이터베이스의 현재 상태에 대한 "스냅샷"을 생성합니다.
  2. 일관된 뷰: 트랜잭션 내의 모든 읽기 작업은 이 스냅샷을 기반으로 수행됩니다. 이를 통해 트랜잭션은 일관된 데이터 뷰를 유지합니다.
  3. 언두 로그 활용: InnoDB는 언두 로그를 사용하여 이전 버전의 데이터를 재구성합니다. 이를 통해 트랜잭션은 자신의 스냅샷 시점의 데이터를 볼 수 있습니다.
  4. 잠금 없는 읽기: 다른 트랜잭션의 쓰기 작업과 충돌하지 않고 데이터를 읽을 수 있습니다.

6.3 Consistent Nonlocking Reads의 이점

  1. 높은 동시성: 읽기 작업이 쓰기 작업을 차단하지 않아 전반적인 시스템 성능이 향상됩니다.
  2. 데이터 일관성: 각 트랜잭션은 일관된 데이터 뷰를 유지합니다.
  3. 교착 상태(Deadlock) 감소: 읽기 작업에 대한 잠금이 없으므로 교착 상태 발생 가능성이 줄어듭니다.

6.4 격리 수준과의 관계

Consistent Nonlocking Reads는 주로 REPEATABLE READ 격리 수준에서 사용되지만, 다른 격리 수준에서도 적용됩니다:

  • READ UNCOMMITTED: 일관된 읽기를 제공하지 않습니다. 직접 현재 데이터를 읽습니다.
  • READ COMMITTED: 각 SELECT 문마다 새로운 스냅샷을 생성합니다.
  • REPEATABLE READ: 트랜잭션 시작 시 생성된 스냅샷을 트랜잭션 종료 시까지 사용합니다.
  • SERIALIZABLE: 모든 일반 SELECT 문을 SELECT ... FOR SHARE로 암시적으로 변환하여 공유 잠금을 사용합니다.

Q: Consistent Nonlocking Reads가 REPEATABLE READ 격리 수준에서 어떻게 Phantom Read를 방지하는지 설명할 수 있나요?

A: Consistent Nonlocking Reads는 REPEATABLE READ 격리 수준에서 다음과 같은 방식으로 Phantom Read를 방지합니다:

  1. 스냅샷 격리: 트랜잭션이 시작될 때 생성된 스냅샷을 사용하여 모든 읽기 작업을 수행합니다. 이 스냅샷은 트랜잭션 시작 시점의 데이터베이스 상태를 나타냅니다.
  2. 버전 관리: InnoDB는 언두 로그를 사용하여 데이터의 이전 버전을 유지합니다. 트랜잭션은 항상 자신의 스냅샷 시점에 해당하는 데이터 버전을 읽습니다.
  3. 범위 잠금: 실제로 데이터를 변경하는 작업(INSERT, UPDATE, DELETE)에 대해서는 넥스트-키 잠금(Next-Key Locking)을 사용하여 새로운 행의 삽입을 방지합니다.
  4. 일관된 결과: 동일한 쿼리를 반복 실행해도 트랜잭션 내에서는 항상 같은 결과를 반환합니다. 이는 다른 트랜잭션에 의해 새로운 행이 삽입되더라도 마찬가지입니다.

이러한 메커니즘의 조합으로 인해, REPEATABLE READ 격리 수준에서 Consistent Nonlocking Reads는 Phantom Read 문제를 효과적으로 방지할 수 있습니다. 이는 MySQL InnoDB가 SQL 표준에서 정의한 REPEATABLE READ의 요구사항을 넘어서는 보호를 제공함을 의미합니다.

6.5 주의사항

  1. 오래 실행되는 트랜잭션: 장기간 실행되는 트랜잭션은 많은 언두 로그를 생성할 수 있으며, 이는 성능에 영향을 줄 수 있습니다.
  2. 읽기 전용 트랜잭션: 읽기 전용 트랜잭션의 경우, 명시적으로 트랜잭션을 시작하지 않아도 일관된 읽기가 제공됩니다.

Q: Consistent Nonlocking Reads의 장점은 명확해 보입니다. 그렇다면 이 방식의 단점이나 제한사항은 무엇인가요?

A: Consistent Nonlocking Reads는 많은 장점을 제공하지만, 몇 가지 단점과 제한사항도 있습니다:

  1. 메모리 사용량 증가:
    • 여러 버전의 데이터를 유지해야 하므로 메모리 사용량이 증가할 수 있습니다.
    • 언두 로그의 크기가 커질 수 있어 디스크 공간을 더 많이 사용할 수 있습니다.
  2. 성능 오버헤드:
    • 데이터의 여러 버전을 관리하고 적절한 버전을 찾는 데 약간의 성능 오버헤드가 발생할 수 있습니다.
    • 매우 오래된 데이터를 읽어야 할 경우, 언두 로그를 탐색하는 데 시간이 걸릴 수 있습니다.
  3. 실시간 데이터 접근의 어려움:
    • 항상 일관된 과거 시점의 데이터를 보여주므로, 실시간으로 변경된 최신 데이터를 즉시 볼 수 없습니다.
    • 이는 일부 실시간 애플리케이션에서는 문제가 될 수 있습니다.
  4. 복잡성 증가:
    • MVCC 메커니즘은 구현과 이해가 더 복잡할 수 있어, 문제 해결이 어려울 수 있습니다.
  5. 긴 실행 트랜잭션의 영향:
    • 매우 오래 실행되는 트랜잭션은 많은 양의 언두 데이터를 유지해야 하므로 시스템 리소스를 많이 사용할 수 있습니다.
  6. 특정 쿼리에 대한 제한:
    • FOR UPDATE나 LOCK IN SHARE MODE와 같은 특수한 쿼리는 여전히 잠금을 사용합니다.
  7. 격리 수준에 따른 동작 차이:
    • 격리 수준에 따라 동작이 다르므로, 애플리케이션 로직이 특정 격리 수준에 의존적일 수 있습니다.

이러한 단점과 제한사항을 고려하여, 개발자와 데이터베이스 관리자는 자신의 시스템 요구사항에 맞게 적절한 설정과 최적화를 수행해야 합니다.

MVCC(Multi-Version Concurrency Control)가 트랜잭션 동작에 미치는 영향

MVCC(Multi Version Concurrency Control)

  • 동시 접근을 허용하는 데이터베이스에서 동시성을 제어하기 위해 사용하는 방법
    • MVCC는 스냅샷을 이용하는 방식으로, 기존의 데이터를 덮어 씌우는게 아니라 기존의 데이터를 바탕으로 이전 버전의 데이터와 비교해서 변경된 내용을 기록
  • 가장 큰 목적은 잠금을 사용하지 않는 일관된 읽기를 제공하기 위함
  • Non-Blocking Reads: 트랜잭션이 데이터를 읽을 때, 데이터에 대한 락을 걸지 않아 읽기 성능을 크게 향상
    • Deadlock 감소: 읽기 작업 시 락을 걸지 않아 Deadlock 발생 확률이 감소함
  • Consistent Reads: 트랜잭션이 시작된 시점에 데이터 스냅샷을 사용하여 Repeatable Read 고립 수준에서 동일한 트랜잭션 내에서는 항상. 동일한 데이터를 읽을 수 있음
    • Serializable이 아니라면 Phantom Read를 방지할 수는 없음

InnoDB가 MVCC를 구현한 방식

  • 언두 로그를 이용
    • "rollback segment"라는 데이터 구조로 언두 테이블스페이스에 저장됨
  • 롤백 세그먼트의 언두 로그는 삽입 및 업데이트 언두 로그로 구분
    • 삽입 언두 로그는 삽입 작업의 트랜잭션 롤백에만 필요하며 트랜잭션이 커밋되자마자 삭제 가능
    • 업데이트 언두 로그는 일관된 읽기에도 사용되지만 InnoDB가 스냅샷을 할당한 트랜잭션이 없는 경우에만 삭제 가능
  • READ_COMMITTED 이상의 경우는 InnoDB 버퍼 풀이나 데이터 파일에 있는 내용 대신 변경되기 이전 내용을 보관하고 있는 언두 영역의 데이터를 반환
  • READ_UNCOMMITTED인 경우는 데이터가 커밋됐든 상관 없이 InnoDB 버퍼 풀이 현재 가지고 있는 변경된 데이터를 읽어 반환
  • 하나의 레코드에 대해 여러 버전이 유지되고, 필요에 따라 어느 데이터가 보여지는지 상황에 따라 달라지는 구조
  • 트랜잭션이 길어지면 언두에서 관리하는 예전 데이터가 삭제되지 못하고 오랫동안 관리되어야 하므로, 언두 영역이 저장되는 시스템 테이블 스페이스 공간이 많이 늘어날 수 있으니 주의
  • SQL 문으로 행을 삭제할 때 행이 데이터베이스에서 즉시 물리적으로 제거되지 않음
  • InnoDB only physically removes the corresponding row and its index records when it discards the update undo log record written for the deletion
    • 이 작업을 purge라고 부름
    • purge 작업은 매우 빠르며 일반적으로 삭제를 수행한 SQL 문과 동일한 시간이 소요

References

트랜잭션 암시적 커밋

암시적 커밋

일부 명령문은 명령문을 실행하기 전에 COMMIT를 수행한 것처럼 암시적으로 트랜잭션을 종료

- 데이터베이스 개체를 정의하거나 수정하는 DDL(데이터 정의 언어) 문
- mysql 데이터베이스의 테이블을 암시적으로 사용하거나 수정하는 명령문
	ALTER USER, CREATE USER, DROP USER, GRANT, RENAME USER, REVOKE, SET PASSWORD
- 트랜잭션 제어 및 잠금 문
	BEGIN, LOCK TABLES, SET autocommit = 1 (if the value is not already 1), START TRANSACTION, UNLOCK TABLES
  - UNLOCK TABLES는 비트랜잭션 테이블 잠금을 획득하기 위해 현재 LOCK TABLES로 잠긴 테이블이 있는 경우에만 트랜잭션을 커밋합니다. 
  FLUSH TABLES WITH READ LOCK 다음에 나오는 UNLOCK TABLES에 대해서는 커밋이 발생하지 않습니다.
- 데이터 로딩 문
	LOAD DATA는 NDB 스토리지 엔진을 사용하는 테이블에 대해서만 암시적 커밋을 발생시킵니다.
- Administrative statements
  ANALYZE TABLE, CACHE INDEX, CHECK TABLE, FLUSH, LOAD INDEX INTO CACHE, OPTIMIZE TABLE, REPAIR TABLE, RESET 
- 복제 제어문
	START REPLICA, STOP REPLICA, RESET REPLICA, CHANGE REPLICATION SOURCE TO, CHANGE MASTER TO

트랜잭션 롤백

Redo Log (재실행 로그)

  • Redo Log는 데이터베이스가 수행한 모든 변경 작업(Insert, Update, Delete)을 순서대로 기록합니다.
  • Redo Log에는 트랜잭션 ID, 변경 전/후 데이터, 타임스탬프 등의 정보가 포함됩니다.
  • Redo Log는 데이터베이스 장애 발생 시 데이터를 복구하기 위해 사용됩니다.
  • 장애 발생 시 데이터베이스는 Redo Log를 순서대로 재실행하여 장애 발생 직전 상태로 데이터를 복구할 수 있습니다.
  • Redo Log는 보통 데이터베이스의 일정 크기의 파일에 저장되며, 이를 Redo Log File이라고 합니다.
  • 이 Redo Log File은 데이터베이스 운영 중 계속 생성되며, 일정 시간이나 크기가 되면 새로운 파일로 바뀝니다.

Undo Log (무효화 로그)

  • Undo Log는 트랜잭션 롤백을 위해 사용됩니다.
  • 트랜잭션이 수행한 변경 작업(Insert, Update, Delete)의 역순으로 기록되어, 트랜잭션 롤백 시 이 로그를 역순으로 실행하면 변경 내역을 취소할 수 있습니다.
  • Undo Log에는 트랜잭션 ID, 변경 전/후 데이터, 타임스탬프 등의 정보가 포함됩니다.
  • Undo Log는 메모리 내에 저장되며, 트랜잭션 커밋 시 삭제됩니다.
  • 트랜잭션이 롤백되면 Undo Log를 역순으로 실행하여 트랜잭션 변경 내역을 취소합니다.

트랜잭션 롤백 과정

  1. 트랜잭션 시작: 트랜잭션 ID와 함께 Redo Log와 Undo Log가 생성됩니다.
  2. 트랜잭션 중 변경 사항 발생: 변경 내역이 Redo Log와 Undo Log에 기록됩니다.
  3. 트랜잭션 롤백 요청: 트랜잭션 ID를 통해 Undo Log에 기록된 변경 내역을 역순으로 실행하여 데이터를 원래 상태로 되돌립니다.
  4. 장애 발생 시 복구: Redo Log를 재실행하여 장애 발생 전 데이터베이스 상태로 복구합니다.

트랜잭션 실행 중 장애 발생 시 어떻게 되는지?

DB failover

  1. 장애 감지:
    • 모니터링 시스템이 주 서버의 장애를 감지
    • 하트비트 메커니즘, 상태 체크 등을 통해 실시간 모니터링
  2. 장애 확인:
    • 일시적 네트워크 문제와 실제 서버 장애를 구분
    • 오탐(False positive)을 방지하기 위해 여러 번 확인
  3. 백업 서버 준비:
    • 대기 중인 백업 서버의 상태 확인
    • 필요한 경우 최신 데이터 동기화 수행
  4. 네트워크 전환:
    • 가상 IP 주소를 주 서버에서 백업 서버로 이동
    • DNS 업데이트 (필요한 경우)
  5. 데이터 일관성 확보:
    • 트랜잭션 로그 적용으로 데이터 최신 상태 유지
    • 미완료 트랜잭션 롤백 또는 복구
  6. 애플리케이션 연결 전환:
    • 애플리케이션의 데이터베이스 연결을 새 서버로 리다이렉션
    • 커넥션 풀 리셋 및 재구성
  7. 서비스 재개:
    • 새로운 주 서버(이전 백업 서버)로 서비스 시작
    • 성능 및 안정성 모니터링
  8. 원인 분석 및 복구:
    • 장애 원인 분석 및 문제 해결
    • 가능한 경우 원래 주 서버 복구 및 동기화
  9. 정상화:
    • 시스템이 안정화되면 원래 구성으로 복귀 여부 결정

페일오버 구현 방식은 다양합니다:

  • 자동 페일오버: 모니터링 시스템이 자동으로 전체 과정을 처리
  • 수동 페일오버: DBA나 시스템 관리자의 개입으로 진행
  • 반자동 페일오버: 일부 단계는 자동화하고 중요 결정은 수동으로 처리

주요 고려사항:

  • 페일오버 시간(RTO: Recovery Time Objective) 최소화
  • 데이터 손실(RPO: Recovery Point Objective) 최소화
  • 네트워크 지연 및 분할 내성(Split-brain 문제 방지)
  • 애플리케이션 레벨의 재시도 및 오류 처리 로직

구체적인 구현은 사용하는 데이터베이스 시스템(예: MySQL, PostgreSQL, Oracle)과 인프라 환경(온프레미스, 클라우드)에 따라 달라질 수 있습니다.

추가적인 정보나 특정 데이터베이스 시스템에서의 페일오버 구현에 대해 더 자세히 알고 싶으시면 말씀해 주세요.

데이터베이스 페일오버 과정에서 언두 로그(Undo Log)와 리두 로그(Redo Log)는 데이터 일관성과 무결성을 유지하는 데 중요한 역할을 합니다. 각각의 사용 방식을 살펴보겠습니다:

리두 로그(Redo Log) 사용:

  1. 데이터 동기화:
    • 주 서버의 최신 리두 로그를 백업 서버에 적용하여 데이터 동기화
    • 장애 직전까지의 트랜잭션을 백업 서버에 반영
  2. 미완료 트랜잭션 처리:
    • 커밋된 트랜잭션 중 디스크에 기록되지 않은 변경사항 복구
    • 페일오버 후 데이터 일관성 보장
  3. 시점 복구:
    • 특정 시점까지의 데이터 상태로 복구 가능
    • 장애 발생 직전의 상태로 정확히 복원
  4. 트랜잭션 재현:
    • 백업 서버가 주 서버 역할을 하게 될 때, 누락된 트랜잭션 재실행
  5. 복제 지연 해소:
    • 비동기 복제 환경에서 복제 지연으로 인한 데이터 차이 해소

언두 로그(Undo Log) 사용:

  1. 롤백 처리:
    • 장애 시점에 진행 중이던 미완료 트랜잭션 롤백
    • 데이터 일관성 유지를 위해 부분적으로 실행된 트랜잭션 취소
  2. 읽기 일관성 제공:
    • 페일오버 직후 장기 실행 쿼리에 대한 일관된 뷰 제공
    • 트랜잭션 격리 수준 유지
  3. 동시성 제어:
    • 페일오버 중 및 직후의 동시 접근 트랜잭션 관리
    • MVCC(Multi-Version Concurrency Control) 지원
  4. 데이터 검증:
    • 리두 로그 적용 후 데이터 상태 검증에 활용
    • 필요시 특정 변경사항 취소에 사용
  5. 부분 복구:
    • 특정 트랜잭션만 선택적으로 롤백해야 할 경우 활용

페일오버 과정에서의 로그 사용 시나리오:

  1. 백업 서버 준비:
    • 리두 로그를 사용해 백업 서버의 데이터를 최신 상태로 동기화
  2. 일관성 확보:
    • 리두 로그로 커밋된 트랜잭션 적용
    • 언두 로그로 미완료 트랜잭션 롤백
  3. 서비스 재개:
    • 언두 로그를 통해 동시성 및 읽기 일관성 보장
    • 리두 로그로 누락된 트랜잭션 재실행
  4. 모니터링 및 검증:
    • 양쪽 로그를 사용해 데이터 상태 및 무결성 검증

이러한 로그 활용을 통해 페일오버 과정에서 데이터 손실을 최소화하고, 일관된 데이터베이스 상태를 유지할 수 있습니다. 구체적인 구현은 사용하는 데이터베이스 관리 시스템과 설정에 따라 다를 수 있습니다.

👼 개인 활동을 기록합시다.

개인 활동 페이지

🧑‍🧑‍🧒‍🧒 그룹 활동을 기록합시다.

그룹 활동 페이지

🎤 미니 세미나

미니 세미나

🤔 기술 블로그 활동

기술 블로그 활동

📚 도서를 추천해주세요

추천 도서 목록

🎸 기타

기타 유용한 학습 링크

Clone this wiki locally