데이터베이스 트랜젝션(Transactoin) - ACID (Durability)

데이터베이스에서 트랜잭션(Transaction)은 데이터베이스의 상태를 변화시키는 작업의 논리적인 단위입니다. 일반적으로 트랜잭션은 여러 작업을 하나로 묶어 데이터의 일관성을 보장하는 역할을 합니다. 트랜잭션의 가장 큰 특징은 모든 작업이 성공적으로 완료되거나, 그렇지 않을 경우 모두 원래대로 복구되어야 한다는 점입니다. 이 원칙은 데이터베이스의 무결성과 일관성을 유지하는 데 중요합니다.

 

트랜잭션에는 보통 다음과 같은 4가지 성질이 있습니다. 이를 ACID라고 합니다:

1. Atomicity (원자성)

데이터베이스 트랜젝션(Transactoin) - ACID (Atomicity)

2. Consistency (일관성)

데이터베이스 트랜젝션(Transactoin) - ACID (Consistency)

3. Isolation(격리성)

데이터베이스 트랜젝션(Transactoin) - ACID (Isolation)

4. Durability(지속성)

지속성(Durability)은 데이터베이스 트랜잭션의 ACID 속성 중 하나로, 트랜잭션이 성공적으로 완료된 후의 변경 사항은 영구적으로 저장되어야 한다는 개념을 의미합니다. 즉, 트랜잭션이 커밋되면 그 결과는 시스템 오류나 장애가 발생하더라도 손실되지 않고 안전하게 보존되어야 합니다. 지속성은 데이터베이스의 신뢰성을 유지하고, 데이터가 손실되지 않도록 보장하는 데 중요한 역할을 합니다.

 

지속성의 주요 개념

1. 트랜잭션 커밋 후 영구 저장:
   • 트랜잭션이 성공적으로 커밋되면 그 결과는 영구적으로 데이터베이스에 반영되어야 합니다. 이때 변경된 데이터는 디스크나 기타 비휘발성 저장 장치에 저장되어, 이후 시스템 장애가 발생하더라도 손실되지 않도록 보장됩니다.
   • 커밋(Commit)이 수행된 후에는 데이터가 안정적인 저장소에 기록되기 때문에 사용자는 데이터가 안전하게 저장되었다고 신뢰할 수 있습니다.
2. 데이터 복구:
   • 시스템 장애가 발생하더라도, Redo 로그와 같은 복구 메커니즘을 사용하여 트랜잭션이 커밋한 데이터를 복구합니다.
   • 데이터베이스 관리 시스템(DBMS)은 시스템이 비정상 종료되었을 때도 커밋된 데이터를 다시 복구할 수 있는 기능을 제공하여 지속성을 유지합니다.
3. 로그 기반의 지속성:
   • 지속성을 보장하기 위해 DBMS는 트랜잭션 로그(Transaction Log)를 사용합니다. 이 로그는 데이터베이스의 변경 사항을 기록하며, 이러한 로그를 통해 장애 발생 시 Redo 작업을 수행하여 데이터의 변경 사항을 복구할 수 있습니다.
   • 로그 파일은 트랜잭션이 커밋되기 전에 안정적인 저장소(디스크)에 기록되며, 트랜잭션이 성공적으로 완료되었다고 사용자에게 응답하기 전에 로그가 안전하게 기록되었음을 보장합니다.

지속성을 보장하기 위한 기술적 메커니즘

1. Redo 로그:
   • Redo 로그는 트랜잭션이 수행한 변경 사항을 기록한 로그 파일로, 데이터베이스 시스템이 비정상적으로 종료된 후에도 변경 사항을 복구하는 데 사용됩니다.
   • 트랜잭션이 커밋되면, 그 변경 사항이 Redo 로그에 기록됩니다. 시스템 재시작 시 Redo 로그를 사용해 모든 커밋된 트랜잭션의 변경 사항을 데이터 파일에 반영함으로써 지속성을 유지합니다.
2. Write-Ahead Logging (WAL):
   • Write-Ahead Logging (WAL)은 변경 사항이 실제 데이터 파일에 적용되기 전에 먼저 로그 파일에 기록해야 한다는 원칙입니다. 이 방식은 장애 발생 시 데이터 손실을 방지하고 지속성을 보장하는 중요한 기술입니다.
   • 로그가 디스크에 안전하게 기록된 이후에만 트랜잭션을 커밋하고, 이로 인해 시스템 장애가 발생해도 Redo 로그를 통해 데이터 복구가 가능합니다.
3. 데이터 복제 (Replication):
   • 지속성을 높이기 위해 데이터베이스는 데이터 복제(Replication)를 사용할 수 있습니다. 변경된 데이터는 실시간으로 다른 서버로 복제되며, 이를 통해 장애 발생 시 복제된 데이터를 사용해 빠르게 복구할 수 있습니다.
   • Master-Slave 복제 또는 동기 복제(Synchronous Replication) 방식이 사용되며, 여러 노드에 데이터를 동시에 기록함으로써 데이터의 지속성을 보장합니다.
4. Checkpoints (체크포인트):
   • 체크포인트(Checkpoint)는 데이터베이스의 현재 상태를 저장하는 지점으로, 시스템 장애 시 복구 시간을 줄이는 데 사용됩니다.
   • 주기적으로 데이터베이스의 변경 사항을 데이터 파일에 반영하고, 로그 파일의 상태를 기록하여 장애 발생 시 체크포인트 이후의 로그만 다시 적용하도록 합니다. 이로써 장애 시 빠르게 데이터를 복구할 수 있습니다.

데이터베이스별 지속성 보장 방법

1. Oracle:
   • Redo 로그와 Archive 로그를 사용하여 지속성을 보장합니다. Redo 로그는 트랜잭션의 변경 사항을 기록하며, 장애 발생 시 이를 통해 데이터베이스를 복구합니다.
   • Write-Ahead Logging (WAL) 기법을 사용하여 변경 사항을 먼저 로그에 기록하고, 로그가 안정적으로 기록된 이후에 데이터 파일을 업데이트합니다.
2. MySQL (InnoDB):
   • InnoDB 스토리지 엔진은 Redo 로그와 Undo 로그를 사용하여 지속성을 보장합니다. Redo 로그는 트랜잭션의 커밋 후 변경 사항을 기록하고, 시스템 장애 시 이를 사용해 데이터베이스를 복구합니다.
   • MySQL의 InnoDB는 또한 Double Write Buffer라는 기법을 사용해 트랜잭션 커밋 시 데이터를 두 번 기록하여 디스크 손상 시에도 데이터를 복구할 수 있도록 합니다.
3. PostgreSQL:
   • Write-Ahead Logging (WAL)을 사용해 지속성을 보장합니다. 변경 사항이 데이터 파일에 기록되기 전에 로그 파일에 먼저 기록하며, 이 로그를 통해 장애 발생 시 데이터베이스를 복구합니다.
   • PostgreSQL은 또한 Checkpoints를 주기적으로 수행하여 데이터베이스의 현재 상태를 저장하고, 장애 발생 시 WAL과 체크포인트를 통해 데이터를 빠르게 복구할 수 있도록 합니다.

지속성 보장과 성능의 균형

• 지속성을 보장하기 위한 기술들은 데이터의 안정성을 보장하는 데 중요한 역할을 하지만, 이러한 기술들은 성능에 영향을 줄 수 있습니다. 예를 들어, Write-Ahead Logging (WAL) 방식으로 인해 로그를 디스크에 기록하는 과정에서 입출력(I/O)가 증가하며, 이로 인해 트랜잭션 처리 속도가 느려질 수 있습니다.
• 따라서 데이터베이스 관리자는 지속성과 성능 간의 균형을 맞추기 위해 다음과 같은 옵션을 사용할 수 있습니다:
  • 비동기 커밋 (Asynchronous Commit): 지속성을 약간 포기하고 커밋 작업을 비동기로 처리하여 성능을 향상시킬 수 있습니다.
  • 로그 파일의 크기와 수 조정: 로그 파일의 크기와 개수를 조정하여 디스크 I/O를 최적화할 수 있습니다.
  • 체크포인트 빈도 조정: 체크포인트의 빈도를 조정하여 장애 발생 시 복구 시간을 단축하거나, 성능을 개선할 수 있도록 조절할 수 있습니다.

지속성은 데이터베이스의 안정성을 유지하고, 사용자가 커밋된 트랜잭션이 항상 데이터베이스에 반영된다는 것을 신뢰하게 만드는 중요한 요소입니다. 이를 통해 데이터의 무결성과 신뢰성을 유지하며, 시스템 장애 상황에서도 데이터가 손실되지 않도록 보장합니다.

Database Transaction