이 가이드에서는 데모 데이터베이스를 만들고 애플리케이션 워크로드를 실행합니다. 그리고 보관처리 및 백업 프로세스를 구성합니다. 그런 다음 백업, 보관처리, 복구 프로세스를 확인하는 방법을 알아봅니다. 마지막으로 데이터베이스를 특정 시점으로 복구하는 방법을 알아봅니다.
이 가이드는 PostgreSQL 데이터베이스의 백업 및 복구 전략을 구성하는 데 관심이 있는 데이터베이스 관리자, 시스템 운영자, DevOps 전문가, 클라우드 설계자를 대상으로 작성되었습니다.
이 가이드에서는 사용자가 Docker 컨테이너뿐 아니라 Linux 명령어, PostgreSQL 데이터베이스 엔진, Compute Engine에 익숙하다고 가정합니다.
목표
- 백업 및 보관처리 프로세스 설정
- PITR 수행
- 백업 모니터링
- 복구 확인
비용
이 문서에서는 비용이 청구될 수 있는 다음과 같은 Google Cloud 구성요소를 사용합니다.
프로젝트 사용량을 기준으로 예상 비용을 산출하려면 가격 계산기를 사용하세요.
이 문서에 설명된 태스크를 완료했으면 만든 리소스를 삭제하여 청구가 계속되는 것을 방지할 수 있습니다. 자세한 내용은 삭제를 참조하세요.
시작하기 전에
- Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Make sure that billing is enabled for your Google Cloud project.
-
Enable the Compute Engine and Cloud Storage APIs.
- Install the Google Cloud CLI.
-
To initialize the gcloud CLI, run the following command:
gcloud init -
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Make sure that billing is enabled for your Google Cloud project.
-
Enable the Compute Engine and Cloud Storage APIs.
- Install the Google Cloud CLI.
-
To initialize the gcloud CLI, run the following command:
gcloud init -
In the Google Cloud console, activate Cloud Shell.
At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
개념
가이드를 시작하기 전에 다음 PostgreSQL 개념을 검토하세요.
- 지속적 보관처리. 데이터베이스에서 연속 트랜잭션을 파일에 지속적으로 저장하는 경우를 의미합니다.
- 미리 쓰기 로그(WAL). 파일이 변경되기 전에 데이터 파일의 변경사항이 WAL에 기록됩니다.
- WAL 레코드. 데이터베이스에 적용된 각 트랜잭션이 WAL 레코드로 형식이 지정되어 저장됩니다.
- 세그먼트 파일. 세그먼트 파일은 단조 증가하는 파일 이름을 사용하고 가급적 많은 WAL 레코드를 포함합니다. 파일 크기는 구성 가능하며 기본값은 16MiB입니다. 크기 또는 개수 측면에서 대량 트랜잭션이 예상되는 경우 생성되는 세그먼트 파일의 총 수를 줄이고 파일 관리 부담을 줄이기 위해 더 큰 크기를 선택할 수 있습니다.
자세한 내용은 안정성 및 미리 쓰기 로그를 참조하세요.
다음 다이어그램은 WAL이 2단계로 유지되는 방식을 보여줍니다.
위 다이어그램에서 영구 WAL의 첫 번째 단계는 테이블에 쓰기와 동시에 실행되는 WAL 버퍼에서의 쓰기 트랜잭션을 기록하는 데이터베이스 엔진으로 구성됩니다. 트랜잭션이 커밋되면 두 번째 단계에서 WAL 세그먼트 추가와 함께 WAL 버퍼가 디스크에 기록되거나 디스크에서 삭제됩니다.
PITR 선택
PITR은 다음과 같은 시나리오에 적합합니다.
- 복구 지점 목표(RPO) 최소화. RPO는 비즈니스 프로세스에 큰 영향을 미치기 전에 허용되는 최대 데이터 손실 시간입니다. 백업 스냅샷 사이의 WAL에 있는 모든 트랜잭션을 저장하면 데이터베이스에 적용할 마지막 전체 백업 이후의 트랜잭션을 갖게 되므로 손실되는 데이터의 양이 크게 줄어듭니다.
- 복구 시간 목표(RTO) 최소화. RTO는 중단 이벤트가 발생하는 경우 데이터베이스를 복구하는 데 필요한 시간입니다. 바이너리 백업 및 로그 보관처리를 설정한 경우 데이터베이스를 복구하는 데 필요한 시간이 최소화됩니다.
- 데이터 손상 버그 또는 관리상의 실수에 대한 구제 조치. 코드 출시로 치명적인 데이터 손상이 발생하거나 정기 유지보수 중 복구 불가능한 오류가 발생하면 해당 시점 이전으로 복구할 수 있습니다.
마이크로서비스 아키텍처와 같은 일부 애플리케이션 아키텍처에는 독립적으로 복구해야 하는 동시 실행 데이터베이스가 있을 수 있습니다. 예를 들어 소매 관련 애플리케이션의 경우 하나의 데이터베이스에 고객 데이터를 저장하고 다른 데이터베이스에는 소매 주문 세부정보와 재고 정보를 저장할 수 있습니다. 전체 데이터베이스의 상태에 따라 1개, 2개 또는 모든 데이터베이스를 동시에 복구해야 할 수 있습니다.
다음과 같은 시나리오에서는 PITR이 적합하지 않습니다.
- RPO가 클 경우. 재해 복구 정책이 최근 스냅샷 이후 수신된 트랜잭션의 손실에 적합하다면 추가 단계 없이 데이터 복구 시간을 줄이는 데 집중할 수 있습니다.
- 완전한 데이터베이스 복구가 필요한 경우. 가장 최근의 트랜잭션으로 복구하는 것이 목표인 경우 복구 대상은 마지막으로 지속된 트랜잭션의 타임스탬프입니다. 이 시나리오는 특정한 PITR 사례이지만, 이 목표를 의미상 완전 복구라고 합니다.
성능에 대한 고려사항
보관처리 과정에서 데이터베이스 서버에 추가 I/O 부하가 발생합니다. 부하는 트랜잭션 볼륨의 쓰기, 업데이트, 삭제에 비례하므로 추가 부하는 워크로드의 특성에 따라 달라집니다.
WAL 보관처리 활동으로 인해 기본 데이터베이스에서 발생할 수 있는 기본 I/O 영향을 줄이려면 읽기 전용 복제본을 사용하여 주기적 WAL 보관처리를 수행하면 됩니다.
이 구성은 WAL 파일의 전송과 관련된 일괄 처리 I/O 활동에서 기본 데이터베이스를 분리합니다. 읽기 전용 복제본이 대상으로 지정된 트랜잭션은 기본 데이터베이스에서 상수 값의 스트림으로 전송되므로 안정적인 상태 처리량에 미치는 영향이 훨씬 적습니다.
또한 프로덕션 데이터베이스 토폴로지에 이미 읽기 전용 복제본이 포함되어 있으면 이 구성으로 인해 관리, 가격 등의 추가 부담이 발생하지 않습니다.
참조 아키텍처
다음 다이어그램은 이 가이드에서 구현하는 아키텍처를 보여줍니다.
이 가이드에서는 다음 구성요소를 사용하는 PITR을 관찰하는 클라우드 인프라를 만듭니다.
- Compute Engine에서 실행되는 PostgreSQL 데이터베이스 서버
- 스냅샷 및 트랜잭션 로그를 저장하는 Cloud Storage
다음 다이어그램은 PostgreSQL 데이터베이스 가상 머신(VM)에서 실행되는 2개의 Docker 컨테이너를 보여줍니다. 문제를 구분하기 위해 데이터베이스 서버가 두 컨테이너 중 하나에서 실행되고 WAL 보관처리가 나머지 컨테이너에서 실행됩니다.
이 다이어그램은 각 컨테이너의 Docker 볼륨이 호스트 VM의 영구 디스크 마운트 지점에 어떻게 매핑되는지 보여줍니다.
환경 변수 설정
이 가이드에서 사용되는 스크립트와 명령어는 셸 환경 변수를 사용합니다.
Cloud Shell에서 프로젝트, 인스턴스 이름, 데모 PostgreSQL 데이터베이스의 환경 변수를 설정합니다.
export PROJECT_ID=your-gcp-project export PG_INSTANCE_NAME=instance-pg-pitr export POSTGRES_PASSWORD=PasswordIsThis export POSTGRES_PITR_DEMO_DBNAME=pitr_demo
다음을 바꿉니다.
your-gcp-project: 이 가이드용으로 만든 프로젝트의 이름PasswordIsThis: PostgreSQL 데이터베이스용 보안 비밀번호
Google Cloud 영역의 환경 변수를 설정합니다.
choose-an-appropriate-zone을 Google Cloud 영역으로 바꿉니다.export ZONE=choose-an-appropriate-zone export REGION=${ZONE%-[a-z]}영역의 리전에 기본 가상 프라이빗 클라우드(VPC) 서브넷의 환경 변수를 설정합니다.
export SUBNETWORK_URI=$(gcloud compute networks subnets \ describe default --format=json --region=$REGION | \ jq --raw-output '.ipCidrRange')Cloud Storage 버킷의 환경 변수를 설정합니다.
archive-bucket을 WAL이 저장된 Cloud Storage 버킷의 고유한 이름으로 바꿉니다.export ARCHIVE_BUCKET=archive-bucket
Cloud Storage 버킷 만들기
PostgreSQL 데이터베이스에서 WAL 파일을 보관처리할 Cloud Storage 버킷을 만듭니다.
gcloud storage buckets create gs://${ARCHIVE_BUCKET}
비공개 IP 주소 인스턴스에 대한 액세스 허용
이 가이드에서 사용되는 인스턴스의 경우 많은 프로덕션 사용 사례와 마찬가지로 VM 인스턴스에서 공개 IP 주소를 가져올 필요가 없습니다. 그러나 인스턴스에는 예시 컨테이너 이미지를 가져오기 위해 공용 인터넷에 대한 액세스 권한이 필요하며 사용자는 보안 셸을 사용하여 연결하기 위한 액세스 권한이 필요합니다. 네트워크 주소 변환(NAT) 게이트웨이를 구성하고 TCP 전달을 위해 IAP(Identity-Aware Proxy)를 구성합니다.
NAT 게이트웨이 만들기
만들 VM 인스턴스에는 공개 IP 주소가 없으므로 인스턴스가 Docker Hub에서 컨테이너 이미지를 가져올 수 있도록 NAT 게이트웨이를 만들어야 합니다.
Cloud Shell에서 Cloud Router를 만듭니다.
export CLOUD_ROUTER_NAME=${PROJECT_ID}-nat-router gloud compute routers create $CLOUD_ROUTER_NAME \ --network=default --region=$REGIONNAT 게이트웨이를 만듭니다.
gcloud compute routers nats create ${PROJECT_ID}-nat-gateway \ --region=$REGION \ --router=$CLOUD_ROUTER_NAME \ --auto-allocate-nat-external-ips \ --nat-all-subnet-ip-ranges
TCP 전달을 위한 IAP 구성
IAP는 Google Cloud에서 실행되는 클라우드 애플리케이션 및 VM에 대한 액세스를 제어합니다. IAP는 사용자가 VM에 액세스할 수 있는지 여부를 확인하기 위해 사용자 ID와 요청의 컨텍스트를 확인합니다.
Cloud Shell에서 TCP 전달 네트워크 블록에서 프로젝트의 인스턴스로 이동하는 트래픽을 허용합니다.
export IAP_FORWARDING_CIDR=35.235.240.0/20 gcloud compute --project=$PROJECT_ID firewall-rules create \ cloud-iap-tcp-forwarding --direction=INGRESS \ --priority=1000 --network=default \ --action=ALLOW --rules=all \ --source-ranges=$IAP_FORWARDING_CIDRTCP 전달 터널을 사용하여 연결하려면 Identity and Access Management(IAM) 정책 바인딩을 추가합니다.
your-email-address를 Google Cloud Console에 로그인할 때 사용하는 이메일 주소로 바꿉니다.export GRANT_EMAIL_ADDRESS=your-email-address gcloud projects add-iam-policy-binding $PROJECT_ID \ --member=user:$GRANT_EMAIL_ADDRESS \ --role=roles/iap.tunnelResourceAccessor
PostgreSQL 데이터베이스 인프라 만들기
Cloud Shell에서 구성 스크립트가 포함된 소스 저장소를 클론하고 셸 컨텍스트를 로컬 저장소로 변경합니다.
git clone https://github.com/GoogleCloudPlatform/gcs-postgresql-recovery-tutorial cd gcs-postgresql-recovery-tutorial데이터베이스 VM 인스턴스를 만들고 구성하기 위해 다음 스크립트를 실행합니다.
cd bin ./create_postgres_instance.sh이 가이드에서 이 스크립트는 Container-Optimized OS 및 연결된 2개의 영구 디스크가 있는 선택된 영역에서 VM 인스턴스를 시작합니다. 이 경우 스크립트 실행 시 작은 영구 디스크를 만들기 때문에 API에서 반환된 I/O 성능 저하와 관련된 경고 메시지는 무시해도 됩니다.
cloud-init 구성 검토
cloud-init는 클라우드 인스턴스를 초기화하는 멀티 배포 패키지입니다.
다음 cloud-init 코드 샘플을 검토하세요.
이 가이드에서는 cloud-init를 사용하여 다음을 수행합니다.
- 영구 디스크 블록 스토리지 기기를 2개 만듭니다.
- 데이터와 보관처리 로그용으로 하나씩 기기 2개에 파일 시스템을 만듭니다.
- Docker 컨테이너와 공유되는 VM 인스턴스의 논리적 마운트 지점에 기기를 마운트합니다.
- 다음과 같이 PostgreSQL Docker 컨테이너를 시작하는
systemd서비스(postgres.service)를 만들어 시작합니다.- 볼륨으로 마운트된 영구 디스크
- VM 호스트에 게시된 PostgreSQL 포트(
5432)
/var/tmp/docker-entrypoint-initdb.d/init-pitr-demo-db.sql파일을 만들어 데모 데이터베이스 및 스키마에 간단한 테이블 집합을 만듭니다.- 볼륨으로 마운트된 WAL 디스크로 Google Cloud CLI Docker 컨테이너를 실행하는 두 번째
systemd서비스(wal_archive.service)를 만들고 시작합니다. 이 서비스는 보관처리된 WAL 파일을 Cloud Storage에 백업합니다. wal_archive.service를 주기적으로 실행하는systemd타이머(wal_archive.timer)를 만들어 사용 설정한 다음 시작합니다.- 트랜잭션 생성기가 데이터베이스 포트에 도달할 수 있도록 VPC 서브넷에 PostgreSQL 포트(
5432)가 열려 있는지 확인합니다.
데이터베이스 인스턴스 구성 수정
데이터베이스 서버가 실행 중이지만 네트워크 액세스를 구성하고 WAL 보관처리 프로세스를 시작해야 합니다.
데이터베이스 VM 인스턴스에 연결
Google Cloud Console에서 VM 인스턴스 페이지로 이동합니다.
터미널 셸을 열려면 생성된
instance-pg-pitr인스턴스 옆에 있는 SSH를 클릭합니다.터미널 셸에서 Docker 컨테이너(
docker ps)가 시작되었는지 확인합니다.출력은 다음과 비슷합니다.
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 8bb65d8c1197 postgres:11-alpine "docker-entrypoint.s…" About a minute ago Up About a minute postgres-db
컨테이너가 아직 실행되지 않은 경우 잠시 기다린 후 동일한 명령어를 사용하여 다시 확인합니다.
데이터베이스에 대한 인바운드 네트워크 연결 허용
instance-pg-pitr인스턴스의 터미널 셸에서 편집할 PostgreSQL 호스트 기반 인증 구성 파일을 엽니다.sudoedit /mnt/disks/data/pgdata/pg_hba.conf데이터베이스에 대한 모든 기본 IP 주소 액세스 권한을 삭제하려면 줄의 시작 부분에
#을 추가하여 파일 끝에서 다음 줄을 주석 처리합니다. 파일의 줄은 다음과 유사합니다.#host all all all md510.0.0.0/8CIDR 블록의 호스트에서 비밀번호로 보호된 연결을 허용하려면 파일 끝에 다음 줄을 추가합니다.host all all 10.0.0.0/8 md5이 항목은 나중에 트랜잭션 생성기가 생성되는 VPC 서브넷에서 연결을 사용 설정합니다.
파일을 저장한 후 닫습니다.
WAL 보관처리 구성
instance-pg-pitr인스턴스의 터미널 셸에서postgresql.conf파일을 수정합니다.sudoedit /mnt/disks/data/pgdata/postgresql.conf주석 처리된 기존의
archive_mode,archive_command,archive_timeout줄을 다음으로 바꿉니다.archive_mode=on archive_command = '( ARCHIVE_PATH=/var/lib/postgresql/wal/pg_wal_archive; test ! -f $ARCHIVE_PATH/%f && cp %p $ARCHIVE_PATH/%f.cp && mv $ARCHIVE_PATH/%f.cp $ARCHIVE_PATH/%f ) ' archive_timeout = 120
수정된 파일의 줄을 바꾼 경우 코드 스니펫은 다음과 유사합니다.
파일을 저장한 후 닫습니다.
구성 변경사항 적용 및 확인
instance-pg-pitr인스턴스의 터미널 셸에서 컨테이너를 다시 시작하여 변경사항을 적용합니다.sudo systemctl restart postgresWAL 세그먼트 파일을 확인합니다.
sudo ls -l /mnt/disks/wal/pg_wal출력은 다음과 비슷합니다.
total 16388 -rw------- 1 postgres 70 16777216 Sep 5 23:07 000000010000000000000001 drwx------ 2 postgres 70 4096 Sep 5 23:05 archive_status
데이터베이스에 대한 네트워크 연결을 확인합니다.
export LOCAL_IP=127.0.0.1 docker exec postgres-db psql -w --host=$LOCAL_IP \ --command='SELECT 1'출력은 다음과 비슷합니다.
?column? ---------- 1 (1 row)인스턴스에 대한 SSH 연결을 닫습니다.
트랜잭션 생성기에서 데이터베이스 입력 시작
다음 단계에서는 이 튜토리얼에서 사용할 트랜잭션을 생성하는 Go 프로그램을 시작합니다. 이 프로그램은 VM 인스턴스의 컨테이너 내부에서 실행됩니다.
컨테이너의 이미지는 이미 공개 Container Registry가 있는 프로젝트에서 빌드되고 호스팅됩니다.
Cloud Shell에서 트랜잭션 생성기 디렉터리로 변경합니다.
cd ~/gcs-postgresql-recovery-tutorial/bin환경 변수를 설정합니다.
export TRANS_GEN_INSTANCE_NAME=instance-trans-gen export POSTGRES_HOST_IP=$(gcloud compute instances describe \ --format=json --zone=${ZONE} ${PG_INSTANCE_NAME} | \ jq --raw-output '.networkInterfaces[0].networkIP')트랜잭션 생성기를 실행하려면 인스턴스를 시작합니다.
./run_trans_gen_instance.shI/O 성능 저하와 관련된 경고 메시지는 무시해도 됩니다.
잠시 기다린 후 트랜잭션이 PostgreSQL 데이터베이스에 도달하는지 확인합니다.
gcloud compute ssh $PG_INSTANCE_NAME \ --tunnel-through-iap \ --zone=$ZONE \ --command="docker exec postgres-db psql \ --dbname=$POSTGRES_PITR_DEMO_DBNAME \ --command='SELECT COUNT(*) FROM pitr_db_schema.customer;'"트랜잭션 생성기에서 데이터베이스에 레코드를 추가할 때 출력에 0보다 큰 수가 포함됩니다.
count ------- 413 (1 row)
바이너리 스냅샷 백업 일정 구성
일정에 따라 영구 디스크를 백업하고 리소스 정책에 정의된 시간 동안 보관할 수 있습니다.
스냅샷 일정 만들기
Cloud Shell에서 환경 변수를 설정합니다.
export ZONE=zone-of-your-instance export SNAPSHOT_SCHEDULE_NAME=pg-disk-schedule export REGION=${ZONE%-[a-z]} export SNAPSHOT_WINDOW_START=$(TZ=":GMT" date "+%H:00") export SNAPSHOT_RETENTION_DAYS=2 export SNAPSHOT_FREQUENCY_HOURS=1zone-of-your-instance를 이전에 데이터베이스 VM을 시작한 Google Cloud 영역으로 바꿉니다.
스냅샷 일정을 만듭니다.
gcloud compute resource-policies create snapshot-schedule \ $SNAPSHOT_SCHEDULE_NAME \ --region=$REGION \ --max-retention-days=$SNAPSHOT_RETENTION_DAYS \ --on-source-disk-delete=apply-retention-policy \ --hourly-schedule=$SNAPSHOT_FREQUENCY_HOURS \ --start-time=$SNAPSHOT_WINDOW_START \ --storage-location=$REGION
디스크에 스냅샷 일정 연결
스크립트를 실행하여 인스턴스를 만들 때 데이터와 WAL 볼륨이 2개의 독립적인 영구 디스크로 생성되었습니다. 정의된 일정에 따라 영구 디스크 스냅샷을 만들려면 리소스 정책을 각 영구 디스크에 연결합니다. 이 경우 디스크 스냅샷을 동시 실행하려면 Compute Engine VM에 연결된 두 영구 디스크에 동일한 정책을 사용합니다.
Cloud Shell에서 환경 변수를 설정합니다.
export SNAPSHOT_SCHEDULE_NAME=pgdata-disk-schedule export PG_INSTANCE_NAME=instance-pg-pitr export ZONE=zone-of-your-instance
일정 정책을 영구 데이터 디스크에 연결합니다.
gcloud beta compute disks add-resource-policies ${PG_INSTANCE_NAME}-data \ --resource-policies $SNAPSHOT_SCHEDULE_NAME \ --zone $ZONE일정 정책을 영구 WAL 디스크에 연결합니다.
gcloud beta compute disks add-resource-policies ${PG_INSTANCE_NAME}-wal \ --resource-policies $SNAPSHOT_SCHEDULE_NAME \ --zone $ZONE
수동으로 스냅샷 실행
(선택사항) 예약된 스냅샷은 일정 창에서 생성되므로 일정을 만든 즉시 스냅샷이 생성될 가능성이 낮습니다. 예약된 스냅샷을 기다리지 않으려면 초기 스냅샷을 수동으로 실행하세요.
Cloud Shell에서 환경 변수를 설정합니다.
export ZONE=zone-of-your-instance export PG_INSTANCE_NAME=instance-pg-pitr export REGION=${ZONE%-[a-z]}PostgreSQL 인스턴스 영구 디스크 2개에 대한 스냅샷을 만듭니다.
gcloud compute disks snapshot \ ${PG_INSTANCE_NAME}-data ${PG_INSTANCE_NAME}-wal \ --snapshot-names=${PG_INSTANCE_NAME}-data-`date+%s`,${PG_INSTANCE_NAME}-wal-`date +%s` \ --zone=$ZONE --storage-location=$REGION생성한 스냅샷을 확인합니다.
gcloud compute snapshots list출력은 다음과 비슷합니다.
NAME DISK_SIZE_GB SRC_DISK STATUS instance-pg-pitr-data-1578339767 200 us-central1-f/disks/instance-pg-pitr-data READY instance-pg-pitr-wal-1578339767 100 us-central1-f/disks/instance-pg-pitr-wal READY
PITR 수행
운영상의 실수 또는 프로그래매틱 방식의 오류로 손실된 데이터를 복구하기 위해 PITR이 수행되는 경우가 많습니다.
이 섹션에서는 데이터베이스 업데이트를 수행하여 치명적인 데이터 손실을 시뮬레이션합니다. 그런 다음 패닉 반응을 시뮬레이션한 후 오류 명령어가 실행되기 전 시점으로 복구를 시작합니다.
PITR 수행 가능 여부 확인
PITR을 수행하기 전 다음 단계가 실행될 때까지 충분한 시간을 갖고 기다려야 합니다.
- 바이너리 백업(디스크 스냅샷)
- WAL 보관처리
이 가이드에서는 WAL 파일의 잦은 순환을 위해 이례적으로 archive_timeout을 120초로 설정했습니다. 또한 1개 이상의 예약된 디스크 스냅샷이 수행될 때까지 기다려야 합니다. 그렇지 않으면 디스크 스냅샷을 수동으로 수행해야 합니다.
스냅샷이 1개 이상 생성되었는지 확인합니다.
Google Cloud 콘솔에서 스냅샷 페이지로 이동합니다.
데이터 볼륨과 WAL 볼륨(예:
instance-pg-pitr--us-central1-a-20190805023535-i3hpw7kn)용으로 하나씩 최소 2개의 스냅샷이 있는지 확인합니다.
세그먼트 파일이 Cloud Storage에 보관처리되었는지 확인합니다.
Google Cloud Console에서 Cloud Storage 브라우저 페이지로 이동합니다.
archive-bucket을 클릭합니다.
데이터 손상
치명적인 데이터 손실을 시뮬레이션하려면 PostgreSQL 데이터베이스에 대한 명령줄 셸을 열고 트랜잭션 생성기가 입력한 테이블의 데이터를 손상시킵니다.
Google Cloud Console에서 VM 인스턴스 페이지로 이동합니다.
instance-pg-pitr인스턴스의 경우 SSH를 클릭합니다.SSH 터미널에서 Docker 컨테이너의 PostgreSQL 터미널 기반 프런트엔드를 실행합니다.
docker exec -it postgres-db psql --dbname=pitr_demo고객 테이블의 행을 수정하려면 PostgreSQL 셸에 의도적인 오타가 포함된 SQL DML 문을 제출합니다.
UPDATE pitr_db_schema.customer SET name = 'New Name for customer id=1'; WHERE id = 1;출력은 다음과 비슷합니다.
UPDATE 999 pitr_demo=# WHERE id = 1; ERROR: syntax error at or near "WHERE" LINE 1: WHERE id = 1; ^WHERE절 앞에 세미콜론이 추가로 삽입되어 오류가 발생했습니다. 데이터베이스의 모든 행이 업데이트되었습니다. 이제 부정확한 문을 수정한 행을 복구하기 위해 PITR을 수행할 수 있습니다.
복구 대상 시간 결정
PITR의 첫 번째 단계는 복구 대상 시간을 결정하는 것입니다. 이 시간은 데이터 손상이 발생하기 전의 특정 시점을 식별하기 위해 데이터를 검사하여 결정합니다.
instance-pg-pitr인스턴스의 터미널 셸에서 손상된 행의 최대 타임스탬프를 가져옵니다.SELECT MAX(create_timestamp)::timestamptz FROM pitr_db_schema.customer WHERE name = 'New Name for customer id=1';출력은 다음과 비슷합니다.
max . ------------------------------- 2019-08-05 18:14:58.226511+00 (1 row)프로덕션 데이터베이스에서는 특히 영향을 받은 테이블이 크고 지시 열의 색인이 지정되지 않은 경우 복구 대상을 결정하는 쿼리가 더 복잡해집니다.
결과를 복사합니다. 다음 단계에서 이 쿼리에서 반환된 값을 사용합니다.
데이터베이스 복구
이 가이드에서는 복구 스크립트를 실행하여 PITR을 자동화합니다. 데이터베이스를 복구하는 자동화된 프로세스가 있다면 이 프로세스를 주기적으로 테스트하는 것이 좋습니다.
Cloud Shell에서 현재 작업 디렉터리를 복구 스크립트의 위치로 변경합니다.
cd ~/gcs-postgresql-recovery-tutorial/bin스크립트에 필요한 환경 변수를 설정합니다.
YYYY-MM-DD HH:MM:SS.999999+00을 앞에서 복사한 쿼리 출력으로 바꿉니다.export PROJECT_ID=$(gcloud config get-value project) export PG_INSTANCE_NAME=instance-pg-pitr export POSTGRES_PASSWORD=PasswordIsThis export PG_INSTANCE_NAME=instance-pg-pitr export RECOVER_BUCKET=archive-bucket export PIT_RECOVERY_TARGET="YYYY-MM-DD HH:MM:SS.999999+00" export ZONE=zone-of-your-instance
복구 스크립트를 실행합니다.
./recover_to_point_in_time.sh
복구 스크립트 이해하기
이 섹션에서는 입력 매개변수와 스크립트로 실행되는 단계에 대해 자세히 설명합니다.
스크립트를 실행하려면 다음 환경 변수를 설정해야 합니다.
PIT_RECOVERY_TARGET: 복구 대상 시간PROJECT_ID:PG_INSTANCE_NAME인스턴스가 있는 프로젝트ZONE:PG_INSTANCE_NAME인스턴스가 있는 영역PG_INSTANCE_NAME: 프로덕션 PostgreSQL 인스턴스가 실행되는 인스턴스RECOVER_BUCKET: WAL 세그먼트 파일이 보관처리되는 Cloud Storage 버킷POSTGRES_PASSWORD: PostgreSQL 데이터베이스 사용자용 비밀번호
스크립트는 다음 단계를 수행합니다.
- 복구 대상 날짜 및 시간을 기준으로 최근의 디스크 스냅샷을 결정합니다.
PITR 데이터베이스를 실행하는 컨테이너 최적화 스토리지 VM에 제공되는
cloud-init.yaml파일을 만듭니다.cloud-init.yaml파일은 구성 파일을 만들고 여러 시스템 명령어를 실행하여 다음 환경을 설정합니다.gcsfuse컨테이너: WAL 세그먼트 파일 보관처리 버킷을 볼륨으로 마운트 한 후 Docker 결합 마운트 지점이 있는 호스트에 노출시킵니다.postgres-db컨테이너: 데이터베이스 엔진이 다음을 실행하는 위치입니다.- 영구 디스크가 볼륨으로 연결된 호스트 파일 시스템
- Cloud Storage 버킷이 볼륨으로 연결된 호스트 파일 시스템
PostgreSQL 데이터 디렉터리에 있는 다음 정보가 포함된
recovery.conf복구 파일- 대상 날짜
restore명령어: 데이터베이스가 필요에 따라 보관처리 파일 시스템에서 WAL 세그먼트 파일을 복사하는 데 사용하는 매개변수화된 복사 명령어입니다.%f는 세그먼트 파일이고%p는 데이터베이스가 복구 중에 파일을 처리하는 데 사용하는 경로입니다.
archive_설정은 WAL 아카이브 디렉터리가 손상되지 않도록postgresql.conf설정 파일에서 주석 처리됩니다.
다음 정보를 사용하여 PITR 인스턴스를 시작합니다.
$PG_INSTANCE_NAME환경 변수와$PIT_RECOVERY_TARGET환경 변수의 영숫자 값을 결합해 만든 이름- 앞에서 식별한 디스크 스냅샷을 기반으로 만든 영구 디스크
다음은 recovery.conf 파일의 예시입니다.
restore_command = '(test -d /var/lib/postgresql/wal/pg_wal_recover && cp /var/lib/postgresql/wal/pg_wal_recover/%f %p ) '
recovery_target_time='YYYY-MM-DD HH:MM:SS UTC'
recovery_target_inclusive=true
복구 검증
Google Cloud Console에서 VM 인스턴스 페이지로 이동합니다.
instance-pg-pitr-YYYYMMDDHHMMSS인스턴스의 경우 SSH를 클릭합니다.SSH 터미널에서 Docker 컨테이너의 PostgreSQL 터미널 기반 프런트엔드를 실행합니다.
docker exec -it postgres-db psql --dbname=pitr_demo다음 오류가 발생하면 PostgreSQL 컨테이너가 시작될 때까지 잠시 기다린 후 명령어를 다시 실행하세요.
Error: No such container: postgres-db
고객 테이블의 데이터를 확인합니다.
SELECT * FROM pitr_db_schema.customer WHERE id > (SELECT MAX(id)-10 FROM pitr_db_schema.customer);출력은 다음과 비슷합니다.
id | name | create_timestamp ------+---------------------------+---------------------------- 711 | customer_name_from_golang | 2019-12-06 18:03:51.229444 712 | customer_name_from_golang | 2019-12-06 18:03:52.531755 713 | customer_name_from_golang | 2019-12-06 18:03:53.555441 714 | customer_name_from_golang | 2019-12-06 18:03:54.581872 715 | customer_name_from_golang | 2019-12-06 18:03:55.607459 716 | customer_name_from_golang | 2019-12-06 18:03:56.633362 717 | customer_name_from_golang | 2019-12-06 18:03:57.658523 718 | customer_name_from_golang | 2019-12-06 18:03:58.685469 719 | customer_name_from_golang | 2019-12-06 18:03:59.706939
이름에 트랜잭션 생성기에서 만든 값이 표시됩니다. 마지막 행에는 복구 대상(환경 변수의 복구 스크립트에 제공)보다 빠른 타임스탬프가 있습니다. 복구해야 하는 레코드 수에 따라 모든 행이 업데이트될 때까지 잠시 기다려야 할 수 있습니다.
삭제
비용이 청구되지 않도록 하는 가장 쉬운 방법은 가이드에서 만든 Google Cloud 프로젝트를 삭제하는 것입니다. 또는 개별 리소스를 삭제할 수 있습니다.
프로젝트 삭제
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.
다음 단계
- Container-Optimized OS 자세히 알아보기
- cloud-init 자세히 알아보기
- Cloud Storage Fuse 자세히 알아보기
- Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항 살펴보기. Cloud 아키텍처 센터를 확인하세요. .