시점 복구(PITR)는 PostgreSQL에서 강력한 기능으로, PostgreSQL의 등장으로 더욱 효율적이고 사용자 친화적이 되었습니다. 이는 관리자가 PostgreSQL 데이터베이스를 과거의 특정 시점으로 복원할 수 있게 해줍니다. 이는 대규모 시스템에서 대량의 트랜잭션 부하를 관리하는 경우 특히 유용합니다.
이 블로그에서는 PITR을 탐구하고 잠재적인 함정과 그 해결책에 대한 지식을 제공하여 원활하고 성공적인 구현을 보장합니다. 또한 주요 이점을 공유하고 PostgreSQL의 단계별 구현을 자세히 설명하겠습니다.
주요 구성 요소
PITR을 구현하려면 두 가지 주요 구성 요소가 필요합니다:
1. 기본 백업
기본 백업은 특정 시점에서 데이터베이스의 스냅샷입니다. 여기에는 데이터베이스를 원래 상태로 복원하는 데 필요한 모든 데이터 파일, 구성 파일 및 메타데이터가 포함됩니다. 기본 백업은 PITR의 시작점 역할을 합니다.
2. 사전 기록 로그(WAL)
WAL 파일은 데이터베이스에서 이루어진 모든 변경 사항을 기록합니다. 이러한 로그는 특정 시점에서 데이터베이스를 복원하는 데 필요한 변경 사항을 저장합니다. PITR을 수행할 때, 원하는 데이터베이스 상태를 재현하기 위해 WAL 파일을 순차적으로 재생합니다.
PITR을 사용하는 이유는 무엇인가요?
PITR은 여러 시나리오에서 유용합니다:
우발적인 변경 사항 되돌리기
우연한 조작, 예를 들어 WHERE
절이 없는 DELETE
또는 DROP
문은 중요한 데이터 손실을 초래할 수 있습니다. PITR을 사용하면 실수하기 직전의 데이터베이스 상태로 복구하여 중요한 데이터를 보존할 수 있습니다.
데이터 손상으로부터 복구
애플리케이션 버그, 하드웨어 고장 또는 디스크 손상으로 인해 데이터 불일치가 발생할 수 있습니다. PITR을 사용하면 깨끗한 데이터베이스 스냅샷을 복원하고 유효한 변경 사항만 재생하여 다운타임과 데이터 손실을 최소화할 수 있습니다.
테스트 또는 디버깅을 위한 복원
개발자들은 종종 디버깅 또는 테스트 목적으로 프로덕션 데이터베이스를 복제해야 합니다. PITR을 사용하면 특정 시점의 데이터베이스 스냅샷을 만들어 실시간 데이터에 영향을 주지 않고 실험을 수행할 수 있습니다.
재해 복구
PITR은 재해 복구 전략에 필수적입니다. 자연 재해 또는 사이버 공격과 같은 재앙이 발생할 경우 데이터베이스를 마지막 일관된 상태로 빠르게 복원하여 업무 연속성을 보장할 수 있습니다.
자원의 효율적인 사용
주기적인 기본 백업과 WAL 파일을 결합함으로써, PITR은 빈번한 전체 백업의 필요성을 최소화하여 저장 공간을 절약하고 백업 시간을 단축합니다. PITR은 또한 특정 초로 복구할 수 있는 정확한 복구 방법으로, 사고 발생 중 데이터 손실 위험을 최소화합니다. 단일 트랜잭션 롤백부터 전체 데이터베이스 복원까지 다양한 복구 시나리오를 효율적으로 처리할 수 있을 만큼 유연합니다.
PostgreSQL 17의 PITR의 새로운 기능은 무엇인가요?
PostgreSQL 17은 성능, 사용성 및 호환성에 중점을 두고 PITR을 위한 여러 가지 개선 사항을 도입합니다:
페일오버 슬롯 동기화
논리 복제 슬롯은 이제 페일오버 동안 동기화를 지원합니다. 이는 PITR에 필요한 WAL이 페일오버 후에도 유지되어 수동 개입을 줄여줍니다.
개선된 WAL 압축
WAL 압축 알고리즘이 업데이트되어 저장 효율성을 개선하고 WAL 아카이빙에 필요한 공간을 줄였습니다. 이는 특히 높은 트랜잭션 속도를 가진 대규모 시스템에 유리합니다.
더 빠른 복구 속도
WAL 재생 프로세스의 최적화는 특히 대량 데이터 세트에 대해 더 빠른 복구 시간을 제공합니다.
논리 복제와의 호환성 개선
PITR은 이제 논리 복제 설정과 더 잘 통합되어 물리적 및 논리적 복제를 활용하는 클러스터를 복구하는 것이 더 쉬워졌습니다.
세밀한 WAL 아카이빙 제어
PostgreSQL 17은 WAL 아카이빙에 대한 더 많은 제어를 제공하여 복구 요구 사항에 맞게 보존 정책을 세밀하게 조정할 수 있습니다.
PostgreSQL에서 PITR을 수행하는 자세한 단계
PITR을 설정하고 수행하려면 다음 단계를 따르십시오. PITR을 사용하기 전에 다음이 필요합니다:
- WAL 아카이빙: WAL 아카이빙을 활성화하고 구성합니다.
- 기본 백업:
pg_basebackup
또는pgBackRest
를 사용하여 전체 기본 백업을 수행합니다. - 안전한 저장소: 백업 및 WAL 파일이 안전하게 저장되도록 하며, 가능하면 오프사이트에 저장합니다.
1. WAL 아카이빙 구성
WAL 아카이빙은 백업 간의 증분 변경 사항을 저장하므로 PITR에 필수적입니다. WAL 아카이빙을 구성하려면 postgresql.conf 파일을 업데이트하여 다음을 설정합니다:
wal_level = replica # Ensures sufficient logging for recovery
archive_mode = on # Enables WAL archiving
archive_command = 'cp %p /path/to/wal_archive/%f' # Command to archive WALs
max_wal_senders = 3 # Allows replication and archiving
그런 다음 구성 매개변수를 설정한 후 PostgreSQL 서버를 재시작합니다:
sudo systemctl restart postgresql
다음 명령어로 WAL 아카이빙 상태를 확인합니다:
SELECT * FROM pg_stat_archiver;
pg_stat_archiver
뷰나 PostgreSQL 로그에서 오류를 찾으세요.
2. 베이스 백업 수행
PITR을 위한 시작점으로 사용할 베이스 백업을 가져오려면 pg_basebackup을 사용하여 명령을 입력하면 됩니다:
pg_basebackup -D /path/to/backup_directory -Fp -Xs -P
이렇게 하면 일관된 데이터베이스 스냅샷이 만들어지고 WAL 파일이 복구를 위해 보관됩니다.
3. 백업 무결성 확인
백업 무결성을 확인하려면 pg_verifybackup
을 사용하세요:
pg_verifybackup /path/to/backup_directory
4. 장애 시뮬레이션
데모 목적으로 장애를 시뮬레이션할 수 있습니다. 예를 들어 데이터를 실수로 삭제해 보세요:
DELETE FROM critical_table WHERE id = 123;
5. 베이스 백업 복원
베이스 백업을 복원하기 전에 PostgreSQL 서버를 중지하세요:
sudo systemctl stop postgresql
그런 다음, 기존 데이터 디렉토리의 이름을 변경하는 다음 명령을 사용하세요:
mv /var/lib/pgsql/17/data /var/lib/pgsql/17/data_old
그런 다음, 베이스 백업으로 데이터 디렉토리를 교체하세요:
cp -r /path/to/backup_directory /var/lib/pgsql/17/data
데이터 디렉토리의 권한을 업데이트하세요:
chown -R postgres:postgres /var/lib/pgsql/17/data
6. 복구 구성
복구 모드를 활성화하려면 먼저 PostgreSQL 데이터 디렉토리에 recovery.signal
파일을 만들어야 합니다:
touch /var/lib/pgsql/17/data/recovery.signal
그런 다음 postgresql.conf를 업데이트하여 다음 매개변수를 추가하세요:
restore_command = 'cp /path/to/wal_archive/%f "%p"' # Restore archived WALs
recovery_target_time = '2024-11-19 12:00:00' # Specify target time
Alternatively, use recovery_target_lsn or recovery_target_name for more advanced scenarios.
7. 복구 모드에서 PostgreSQL 시작
다음 명령으로 PostgreSQL 서버를 다시 시작하세요:
sudo systemctl start postgresql
복구 진행 상황을 모니터링하세요.
tail -f /var/lib/pgsql/17/pg_log/postgresql.log
PostgreSQL은 복구가 완료되면 자동으로 복구 모드를 종료하고 운영 모드로 전환됩니다.
8. 복구 검증
복구 후 데이터베이스 상태를 검증합니다:
SELECT * FROM critical_table WHERE id = 123;
잠재적 문제 해결
누락되거나 손상된 WAL 파일
문제
복구에 필요한 WAL 파일이 누락되었거나 손상되었습니다.
해결책
- 정기적으로
pg_verifybackup
와 같은 도구를 사용하여 백업 및 WAL 아카이브를 검증합니다. - WAL 아카이브에 대해 이중 저장소를 사용합니다.
잘못된 복구 대상
문제
복구가 의도하지 않은 상태에서 중단됩니다.
해결책
recovery_target_time
,recovery_target_lsn
, 또는recovery_target_name
을 다시 확인합니다.- 대상 이벤트에 대해 WAL 파일을 검사하려면
pg_waldump
를 사용합니다.
복구 중 성능 병목 현상
문제
대형 WAL 파일로 인해 복구가 너무 오래 걸립니다.
해결책
maintenance_work_mem
및max_parallel_workers
를 늘려 복구 성능을 최적화합니다.- 파일 크기를 줄이기 위해 WAL 압축을 사용합니다.
시계 불일치 문제
문제
시계 차이로 인해 복구 타임스탬프를 정렬해야 합니다.
해결책
NTP와 같은 도구를 사용하여 서버 시계를 동기화합니다.
잘못 구성된 WAL 아카이빙
문제
부적절한 archive_command
로 인해 WAL 아카이브 실패가 발생합니다.
해결책
archive_command
를 수동으로 테스트합니다:cp /path/to/test_wal /path/to/wal_archive/
.- 아카이브 디렉토리에 대한 충분한 권한을 확인합니다.
PITR 모범 사례
- 백업 자동화: pgBackRest 또는 Barman과 같은 도구를 사용하여 예약된 백업 및 WAL 아카이빙을 수행합니다.
- WAL 아카이브 모니터링: 문제를 확인하기 위해
pg_stat_archiver
를 정기적으로 확인합니다. - 백업 검증: 항상
pg_verifybackup
를 사용하여 백업 무결성을 확인합니다. - 복구 절차 테스트: 정기적으로 복구 시나리오를 시뮬레이션하여 준비 상태를 확인합니다.
- WAL 아카이브 보안: WAL 아카이브에는 클라우드 서비스나 RAID 구성된 디스크와 같은 안전하고 중복된 저장소를 사용합니다.
결론
시점 복구(PITR)는 데이터베이스 신뢰성을 유지하고 사건 발생 시 데이터 손실을 완화하는 데 중요합니다. pgEdge와 PostgreSQL 17의 향상 기능은 PITR을 더 빠르고 효율적이며 관리하기 쉽게 만들어, 특히 대규모 또는 고가용성 시스템에 적합합니다.
이 가이드의 단계와 모범 사례를 따르면 PostgreSQL 환경에서 PITR을 효과적으로 구현하고 관리하는 데 도움이 됩니다. 정기적인 테스트와 모니터링은 복구 프로세스가 필요할 때 사용할 수 있도록 보장하는 데 필수적입니다.
Source:
https://dzone.com/articles/point-in-time-recovery-pitr-in-postgresql