이 페이지에서는 PITR(point-in-time recovery)을 사용하여 기본 Cloud SQL 인스턴스를 복원하는 방법을 설명합니다.
PITR에 대한 자세한 내용은 PITR(point-in-time recovery)을 참조하세요.
Cloud SQL Enterprise Plus 버전 인스턴스를 만들 때 Google Cloud 콘솔, gcloud CLI, Terraform, Cloud SQL Admin API를 사용하여 인스턴스를 만드는지 여부에 관계없이 기본적으로 PITR은 사용 설정됩니다.
Google Cloud 콘솔에서 Cloud SQL Enterprise 버전 인스턴스를 만들면 기본적으로 PITR이 사용 설정됩니다. 그렇지 않고 gcloud CLI, Terraform, Cloud SQL Admin API를 사용하여 인스턴스를 만들면 PITR을 수동으로 사용 설정해야 합니다.
PITR의 로그 스토리지
Cloud SQL은 PITR에 미리 쓰기 로깅(WAL) 보관처리를 사용합니다.2023년 1월 9일 PITR의 미리 쓰기 로그 저장 기능이 Cloud Storage에 출시되었습니다. 이 출시 이후에는 다음 조건이 적용됩니다.
- 모든 Cloud SQL Enterprise Plus 버전 인스턴스는 미리 쓰기 로그를 Cloud Storage에 저장합니다. Cloud SQL Enterprise 버전에서 업그레이드하고 2023년 1월 9일 이전에 PITR을 사용 설정한 Cloud SQL Enterprise Plus 버전 인스턴스만 로그를 계속 디스크에 저장합니다.
- 2023년 1월 9일 이전에 PITR이 사용 설정된 Cloud SQL Enterprise 버전 인스턴스는 해당 로그를 계속 디스크에 저장합니다.
- 2024년 8월 15일 이후에 디스크에 PITR의 트랜잭션 로그를 저장하는 Cloud SQL Enterprise 버전 인스턴스를 Cloud SQL Enterprise Plus 버전으로 업그레이드하는 경우 업그레이드 프로세스는 PITR에 사용되는 트랜잭션 로그의 스토리지 위치를 Cloud Storage로 전환합니다. 자세한 내용은 인플레이스 업그레이드를 사용하여 인스턴스를 Cloud SQL Enterprise Plus 버전으로 업그레이드를 참조하세요.
- 2023년 1월 9일 이후에 PITR을 사용 설정하여 만드는 모든 Cloud SQL Enterprise 버전 인스턴스는 로그를 Cloud Storage에 저장합니다.
미리 쓰기 로그를 디스크에만 저장하는 인스턴스의 경우 다운타임 없이 gcloud CLI 또는 Cloud SQL Admin API를 사용하여 PITR에 사용되는 트랜잭션 로그의 스토리지 위치를 디스크에서 Cloud Storage로 전환할 수 있습니다. 자세한 내용은 트랜잭션 로그 스토리지를 Cloud Storage로 전환을 참조하세요.
로그 보관 기간
인스턴스가 PITR에 사용되는 로그를 Cloud Storage에 저장하는지 여부를 확인하려면 PITR에 사용되는 트랜잭션 로그의 스토리지 위치 확인을 사용하세요.
psql
또는 pgAdmin
과 같은 PostgreSQL 클라이언트를 사용하여 인스턴스의 데이터베이스에 연결한 후 show archive_command
명령어를 실행합니다. 미리 쓰기 로그가 Cloud Storage에 보관처리되면 -async_archive -remote_storage
가 표시됩니다.
PITR이 사용 설정된 다른 모든 기존 인스턴스는 해당 로그가 계속 디스크에 저장됩니다.
로그가 Cloud Storage에 저장되는 경우 Cloud SQL은 최소 5분마다 로그를 업로드합니다. 따라서 Cloud SQL 인스턴스를 사용할 수 있는 경우 인스턴스를 최근 시간으로 복구할 수 있습니다. 하지만 인스턴스를 사용할 수 없는 경우 목표 복구 시간은 일반적으로 5분 이하입니다. gcloud CLI 또는 Admin API를 사용하여 인스턴스를 복원할 수 있는 최근 시간을 확인하고 해당 시점으로 복구를 수행합니다.
PITR과 함께 사용되는 미리 쓰기 로그는 일반적으로 transactionLogRetentionDays
에 설정된 값이 충족된 후에 관련 자동 백업과 함께 자동으로 삭제됩니다. Cloud SQL이 PITR을 위해 보관하는 트랜잭션 로그의 일수입니다. Cloud SQL Enterprise Plus 버전의 경우 보관되는 트랜잭션 로그의 일수로 1에서 35 사이의 값을 설정할 수 있고 Cloud SQL Enterprise 버전의 경우에는 1에서 7 사이의 값을 설정할 수 있습니다.
PITR을 사용 설정하기 전에 Cloud SQL 인스턴스에서 백업을 복원하면 PITR의 운영을 허용하는 미리 쓰기 로그가 손실됩니다.
고객 관리 암호화 키(CMEK) 사용 설정 인스턴스의 경우 미리 쓰기 로그는 최신 버전의 CMEK를 사용하여 암호화됩니다. 복원을 수행하려면 retained-transaction-log-days
매개변수에 대해 구성한 기간(일) 동안 모든 최신 키 버전을 사용할 수 있어야 합니다.
미리 쓰기 로그가 Cloud Storage에 저장된 인스턴스의 경우 로그가 기본 인스턴스와 동일한 리전에 저장됩니다. 이 로그 스토리지(Cloud SQL Enterprise Plus 버전의 경우 최대 35일, Cloud SQL Enterprise 버전의 경우 7일, PITR(point-in-time recovery) 최대 길이)에서는 인스턴스당 추가 비용이 발생하지 않습니다.
로그 및 디스크 사용량
인스턴스에 PITR이 사용 설정되어 있고 디스크의 미리 쓰기 로그 크기로 인해 인스턴스에 문제가 발생하는 경우 다음을 수행합니다.
gcloud CLI 또는 Cloud SQL Admin API를 사용하여 디스크에서 Cloud Storage로 다운타임 없이 PITR에 사용되는 로그의 스토리지 위치를 전환할 수 있습니다.
인스턴스 스토리지 크기를 늘리면 됩니다. 하지만 미리 쓰기 로그 크기에 따른 디스크 사용량 증가가 일시적인 것일 수도 있습니다.
예기치 않은 스토리지 문제를 막으려면 스토리지 용량 자동 증가를 사용 설정하는 것이 좋습니다. 이 권장사항은 인스턴스에 PITR이 사용 설정되어 있고 로그가 디스크에 저장된 경우에만 적용됩니다.
로그를 삭제하고 스토리지를 복구하려면 PITR을 비활성화하면 됩니다. 사용되는 미리 쓰기 로그를 줄여도 인스턴스에 프로비저닝된 디스크의 크기가 축소되는 것은 아닙니다.
로그는 매일 한 번씩 영구 삭제되며, 지속적으로 진행되지 않습니다. 로그 보관 기간을 2일로 설정하면 최소 2일 동안의 로그 및 최대 3일 동안의 로그가 보관됩니다. 백업 수를 로그 보관 일수보다 2 이상으로 설정하는 것이 좋습니다.
예를 들어
transactionLogRetentionDays
매개변의 값을7
로 설정하면backupRetentionSettings
매개변수의retainedBackups
수를8
로 설정합니다.
PITR 사용 설정
Google Cloud 콘솔에서 새 인스턴스를 만들면 자동 백업 및 PITR(point-in-time recovery) 사용 설정 모두 자동으로 사용 설정됩니다.다음 절차는 기존의 기본 인스턴스에서 PITR을 사용 설정합니다.
콘솔
-
Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.
- PITR을 사용 설정할 인스턴스의 추가 작업 메뉴()를 열고 수정을 클릭합니다.
- 인스턴스 맞춤설정에서 데이터 보호 섹션을 펼칩니다.
- point-in-time recovery 사용 설정 체크박스를 선택합니다.
- 로그 일수 필드에 로그를 보관할 일수(Cloud SQL Enterprise Plus 버전의 경우 1~35, Cloud SQL Enterprise 버전의 경우 1~7)를 입력합니다.
- 저장을 클릭합니다.
gcloud
- 인스턴스 개요를 표시합니다.
gcloud sql instances describe INSTANCE_NAME
backupConfiguration
섹션에enabled: false
가 표시되면 예약된 백업을 사용 설정합니다.gcloud sql instances patch INSTANCE_NAME \ --backup-start-time=HH:MM
UTC±00 시간대의 24시간제를 사용하여
backup-start-time
매개변수를 지정합니다.- PITR을 사용 설정합니다.
gcloud sql instances patch INSTANCE_NAME \ --enable-point-in-time-recovery
기본 인스턴스에서 PITR을 사용 설정하면 다음 매개변수를 추가하여 트랜잭션 로그 보관 일수를 구성할 수도 있습니다.
--retained-transaction-log-days=RETAINED_TRANSACTION_LOG_DAYS
- 변경사항을 확인합니다.
gcloud sql instances describe INSTANCE_NAME
변경이 성공하면
backupConfiguration
섹션에pointInTimeRecoveryEnabled: true
가 표시됩니다.
Terraform
PITR을 사용 설정하려면 Terraform 리소스를 사용합니다.
변경사항 적용
Google Cloud 프로젝트에 Terraform 구성을 적용하려면 다음 섹션의 단계를 완료하세요.
Cloud Shell 준비
- Cloud Shell을 실행합니다.
-
Terraform 구성을 적용할 기본 Google Cloud 프로젝트를 설정합니다.
이 명령어는 프로젝트당 한 번만 실행하면 되며 어떤 디렉터리에서도 실행할 수 있습니다.
export GOOGLE_CLOUD_PROJECT=PROJECT_ID
Terraform 구성 파일에서 명시적 값을 설정하면 환경 변수가 재정의됩니다.
디렉터리 준비
각 Terraform 구성 파일에는 자체 디렉터리(루트 모듈이라고도 함)가 있어야 합니다.
-
Cloud Shell에서 디렉터리를 만들고 해당 디렉터리 내에 새 파일을 만드세요. 파일 이름에는
.tf
확장자가 있어야 합니다(예:main.tf
). 이 튜토리얼에서는 파일을main.tf
라고 합니다.mkdir DIRECTORY && cd DIRECTORY && touch main.tf
-
튜토리얼을 따라 하는 경우 각 섹션이나 단계에서 샘플 코드를 복사할 수 있습니다.
샘플 코드를 새로 만든
main.tf
에 복사합니다.필요한 경우 GitHub에서 코드를 복사합니다. 이는 Terraform 스니펫이 엔드 투 엔드 솔루션의 일부인 경우에 권장됩니다.
- 환경에 적용할 샘플 매개변수를 검토하고 수정합니다.
- 변경사항을 저장합니다.
-
Terraform을 초기화합니다. 이 작업은 디렉터리당 한 번만 수행하면 됩니다.
terraform init
원하는 경우 최신 Google 공급업체 버전을 사용하려면
-upgrade
옵션을 포함합니다.terraform init -upgrade
변경사항 적용
-
구성을 검토하고 Terraform에서 만들거나 업데이트할 리소스가 예상과 일치하는지 확인합니다.
terraform plan
필요에 따라 구성을 수정합니다.
-
다음 명령어를 실행하고 프롬프트에
yes
를 입력하여 Terraform 구성을 적용합니다.terraform apply
Terraform에 '적용 완료' 메시지가 표시될 때까지 기다립니다.
- 결과를 보려면 Google Cloud 프로젝트를 엽니다. Google Cloud 콘솔에서 UI의 리소스로 이동하여 Terraform이 리소스를 만들었거나 업데이트했는지 확인합니다.
변경사항 삭제
변경사항을 삭제하려면 다음 단계를 따르세요.
- Terraform 구성 파일에서 삭제 보호를 사용 중지하려면
deletion_protection
인수를false
로 설정합니다.deletion_protection = "false"
- 다음 명령어를 실행하고 프롬프트에
yes
를 입력하여 업데이트된 Terraform 구성을 적용합니다.terraform apply
-
다음 명령어를 실행하고 프롬프트에
yes
를 입력하여 이전에 Terraform 구성에 적용된 리소스를 삭제합니다.terraform destroy
REST v1
요청 데이터를 사용하기 전에 다음을 바꿉니다.
- PROJECT_ID: 인스턴스가 포함된 Google Cloud 프로젝트의 ID 또는 프로젝트 번호
- INSTANCE_NAME: 고가용성으로 구성하려는 기본 또는 읽기 복제본 인스턴스의 이름
- START_TIME: 시간(시간 및 분)
HTTP 메서드 및 URL:
PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME
JSON 요청 본문:
{ "settings": { "backupConfiguration": { "startTime": "START_TIME", "enabled": true, "pointInTimeRecoveryEnabled": true } } }
요청을 보내려면 다음 옵션 중 하나를 펼칩니다.
다음과 비슷한 JSON 응답이 표시됩니다.
REST v1beta4
요청 데이터를 사용하기 전에 다음을 바꿉니다.
- PROJECT_ID: 인스턴스가 포함된 Google Cloud 프로젝트의 ID 또는 프로젝트 번호
- INSTANCE_NAME: 고가용성으로 구성하려는 기본 또는 읽기 복제본 인스턴스의 이름
- START_TIME: 시간(시간 및 분)
HTTP 메서드 및 URL:
PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME
JSON 요청 본문:
{ "settings": { "backupConfiguration": { "startTime": "START_TIME", "enabled": true, "pointInTimeRecoveryEnabled": true } } }
요청을 보내려면 다음 옵션 중 하나를 펼칩니다.
다음과 비슷한 JSON 응답이 표시됩니다.
사용할 수 없는 인스턴스에서 PITR 수행
콘솔
다음과 같은 이유로 다른 영역으로 사용할 수 인스턴스를 복구해야 할 수 있습니다.
- 인스턴스가 구성된 영역에 액세스할 수 없습니다. 이 인스턴스는
FAILED
상태입니다. - 인스턴스가 유지보수 중입니다. 이 인스턴스는
MAINTENANCE
상태입니다.
사용할 수 없는 인스턴스를 복구하려면 다음 단계를 완료합니다.
-
Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.
- 클론할 인스턴스의 행을 찾습니다.
- 작업 열에서 추가 작업 메뉴를 클릭합니다.
- 클론 만들기를 클릭합니다.
- 클론 만들기 페이지에서 다음 작업을 완료합니다.
- 필요한 경우 인스턴스 ID 필드에서 인스턴스 ID를 업데이트합니다.
- 이전 시점에서 클론을 클릭합니다.
- 특정 시점 필드에서 데이터를 클론할 날짜와 시간을 선택합니다. 이렇게 하면 해당 시점의 인스턴스 상태가 복구됩니다.
- 클론 만들기를 클릭합니다.
클론이 초기화되는 동안 인스턴스 등록 페이지로 돌아옵니다.
gcloud
인스턴스가 구성된 영역에 액세스할 수 없으므로 사용할 수 없는 인스턴스를 다른 영역으로 복구해야 할 수 있습니다.
gcloud sql instances clone SOURCE_INSTANCE_NAME TARGET_INSTANCE_NAME \ --point-in-time DATE_AND_TIME_STAMP \ --preferred-zone ZONE_NAME \ --preferred-secondary-zone SECONDARY_ZONE_NAME
gcloud sql instances clone
명령어를 실행하는 사용자 또는 서비스 계정에 cloudsql.instances.clone
권한이 있어야 합니다. gcloud CLI 명령어를 실행하는 데 필요한 권한에 대한 자세한 내용은 Cloud SQL 권한을 참조하세요.
REST v1
인스턴스가 구성된 영역에 액세스할 수 없으므로 사용할 수 없는 인스턴스를 다른 영역으로 복구해야 할 수 있습니다.
요청 데이터를 사용하기 전에 다음을 바꿉니다.
- PROJECT_ID: 프로젝트 ID
- SOURCE_INSTANCE_NAME: 소스 인스턴스의 이름입니다.
- TARGET_INSTANCE_NAME: 대상 (클론) 인스턴스의 이름입니다.
- DATE_AND_TIME_STAMP: 소스 인스턴스의 날짜 및 시간 스탬프로서 UTC 시간대 및 RFC 3339 형식입니다(예:
2012-11-15T16:19:00.094Z
). - ZONE_NAME: 선택사항. 대상 인스턴스의 기본 영역 이름입니다. 클론할 Cloud SQL 인스턴스에 다른 기본 영역을 지정하는 데 사용됩니다. 리전 인스턴스의 경우 이 영역이 기본 영역을 대체하지만 보조 영역이 인스턴스와 동일하게 유지됩니다.
- SECONDARY_ZONE_NAME: 선택사항. 대상 인스턴스의 보조 영역 이름입니다. 클론할 리전 Cloud SQL 인스턴스에 다른 보조 영역을 지정하는 데 사용됩니다.
HTTP 메서드 및 URL:
POST https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/SOURCE_INSTANCE_NAME/clone
JSON 요청 본문:
{ "cloneContext": { "destinationInstanceName": "TARGET_INSTANCE_NAME", "pointInTime": "DATE_AND_TIME_STAMP", "preferredZone": "ZONE_NAME", "preferredSecondaryZone": "SECONDARY_ZONE_NAME" } }
요청을 보내려면 다음 옵션 중 하나를 펼칩니다.
다음과 비슷한 JSON 응답이 표시됩니다.
instances.clone
API 메서드를 사용하는 사용자 또는 서비스 계정에는 cloudsql.instances.clone
권한이 있어야 합니다. API 메서드를 사용하는 데 필요한 권한에 대한 자세한 내용은 Cloud SQL 권한을 참조하세요.
REST v1beta4
인스턴스가 구성된 영역에 액세스할 수 없으므로 사용할 수 없는 인스턴스를 다른 영역으로 복구해야 할 수 있습니다.
요청 데이터를 사용하기 전에 다음을 바꿉니다.
- PROJECT_ID: 프로젝트 ID
- SOURCE_INSTANCE_NAME: 소스 인스턴스의 이름입니다.
- TARGET_INSTANCE_NAME: 대상 (클론) 인스턴스의 이름입니다.
- DATE_AND_TIME_STAMP: 소스 인스턴스의 날짜 및 시간 스탬프로서 UTC 시간대 및 RFC 3339 형식입니다(예:
2012-11-15T16:19:00.094Z
). - ZONE_NAME: 선택사항. 대상 인스턴스의 기본 영역 이름입니다. 클론할 Cloud SQL 인스턴스에 다른 기본 영역을 지정하는 데 사용됩니다. 리전 인스턴스의 경우 이 영역이 기본 영역을 대체하지만 보조 영역이 인스턴스와 동일하게 유지됩니다.
- SECONDARY_ZONE_NAME: 선택사항. 대상 인스턴스의 보조 영역 이름입니다. 클론할 리전 Cloud SQL 인스턴스에 다른 보조 영역을 지정하는 데 사용됩니다.
HTTP 메서드 및 URL:
POST https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/SOURCE_INSTANCE_NAME/clone
JSON 요청 본문:
{ "cloneContext": { "destinationInstanceName": "TARGET_INSTANCE_NAME", "pointInTime": "DATE_AND_TIME_STAMP", "preferredZone": "ZONE_NAME", "preferredSecondaryZone": "SECONDARY_ZONE_NAME" } }
요청을 보내려면 다음 옵션 중 하나를 펼칩니다.
다음과 비슷한 JSON 응답이 표시됩니다.
instances.clone
API 메서드를 사용하는 사용자 또는 서비스 계정에는 cloudsql.instances.clone
권한이 있어야 합니다. API 메서드를 사용하는 데 필요한 권한에 대한 자세한 내용은 Cloud SQL 권한을 참조하세요.
최근 복구 시간 확인
사용 가능한 인스턴스의 경우 PITR(포인트 인 타임 복구)을 최근 시간으로 수행할 수 있습니다. 인스턴스를 사용할 수 없고 인스턴스 로그가 Cloud Storage에 저장된 경우 최근 복구 시간을 가져와 해당 시점으로 PITR을 수행하면 됩니다. 두 경우 모두 선호하는 영역의 값을 제공하여 다른 기본 또는 보조 영역으로 인스턴스를 복원할 수 있습니다.
gcloud
사용할 수 없는 Cloud SQL 인스턴스를 복구할 수 있는 최근 시간을 가져옵니다.
INSTANCE_NAME을 쿼리중인 인스턴스의 이름으로 바꿉니다.
gcloud sql instances get-latest-recovery-time INSTANCE_NAME
REST v1
요청 데이터를 사용하기 전에 다음을 바꿉니다.
- PROJECT_ID: 프로젝트 ID입니다.
- INSTANCE_NAME: 최근 복구 시간을 쿼리하는 인스턴스의 이름입니다.
HTTP 메서드 및 URL:
GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME/getLatestRecoveryTime
요청을 보내려면 다음 옵션 중 하나를 펼칩니다.
다음과 비슷한 JSON 응답이 표시됩니다.
{ "kind": "sql#getLatestRecoveryTime", "latestRecoveryTime": "2023-06-20T17:23:59.648821586Z" }
REST v1beta4
요청 데이터를 사용하기 전에 다음을 바꿉니다.
- PROJECT_ID: 프로젝트 ID입니다.
- INSTANCE_NAME: 최근 복구 시간을 쿼리하는 인스턴스의 이름입니다.
HTTP 메서드 및 URL:
GET https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME/getLatestRecoveryTime
요청을 보내려면 다음 옵션 중 하나를 펼칩니다.
다음과 비슷한 JSON 응답이 표시됩니다.
{ "kind": "sql#getLatestRecoveryTime", "latestRecoveryTime": "2023-06-20T17:23:59.648821586Z" }
PITR 수행
콘솔
-
Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.
- 복구할 인스턴스의 추가 작업 메뉴()를 열고 클론 만들기를 클릭합니다.
- 필요한 경우 클론 만들기 페이지에서 새 클론의 ID를 업데이트합니다.
- 이전 시점에서 클론을 선택합니다.
- PITR 시간을 입력합니다.
- 클론 만들기를 클릭합니다.
gcloud
PITR을 사용하여 클론을 만듭니다.
다음을 바꿉니다.
- SOURCE_INSTANCE_NAME - 복원할 인스턴스의 이름입니다.
- NEW_INSTANCE_NAME - 클론 이름입니다.
- TIMESTAMP - RFC 3339 형식의 소스 인스턴스 UTC 시간대입니다. 예를 들면 2012-11-15T16:19:00.094Z입니다.
gcloud sql instances clone SOURCE_INSTANCE_NAME \ NEW_INSTANCE_NAME \ --point-in-time 'TIMESTAMP'
REST v1
요청 데이터를 사용하기 전에 다음을 바꿉니다.
- project-id: 프로젝트 ID
- target-instance-id: 대상 인스턴스 ID
- source-instance-id: 소스 인스턴스 ID
- restore-timestamp 복원할 특정 시점
HTTP 메서드 및 URL:
POST https://sqladmin.googleapis.com/v1/projects/project-id/instances/source-instance-id/clone
JSON 요청 본문:
{ "cloneContext": { "kind": "sql#cloneContext", "destinationInstanceName": "target-instance-id", "pointInTime": "restore-timestamp" } }
요청을 보내려면 다음 옵션 중 하나를 펼칩니다.
다음과 비슷한 JSON 응답이 표시됩니다.
REST v1beta4
요청 데이터를 사용하기 전에 다음을 바꿉니다.
- project-id: 프로젝트 ID
- target-instance-id: 대상 인스턴스 ID
- source-instance-id: 소스 인스턴스 ID
- restore-timestamp 복원할 특정 시점
HTTP 메서드 및 URL:
POST https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/source-instance-id/clone
JSON 요청 본문:
{ "cloneContext": { "kind": "sql#cloneContext", "destinationInstanceName": "target-instance-id", "pointInTime": "restore-timestamp" } }
요청을 보내려면 다음 옵션 중 하나를 펼칩니다.
다음과 비슷한 JSON 응답이 표시됩니다.
PITR 비활성화
콘솔
-
Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.
- 비활성화할 인스턴스의 추가 작업 메뉴 를 열고 수정을 선택합니다.
- 인스턴스 맞춤설정에서 데이터 보호 섹션을 펼칩니다.
- point-in-time recovery 사용 설정을 선택 해제합니다.
- 저장을 클릭합니다.
gcloud
- PITR(point-in-time recovery) 비활성화:
gcloud sql instances patch INSTANCE_NAME \ --no-enable-point-in-time-recovery
- 변경사항을 확인합니다.
gcloud sql instances describe INSTANCE_NAME
변경이 성공하면
backupConfiguration
섹션에pointInTimeRecoveryEnabled: false
가 표시됩니다.
REST v1
요청 데이터를 사용하기 전에 다음을 바꿉니다.
- project-id: 프로젝트 ID
- instance-id: 인스턴스 ID
HTTP 메서드 및 URL:
PATCH https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id
JSON 요청 본문:
{ "settings": { "backupConfiguration": { "enabled": false, "pointInTimeRecoveryEnabled": false } } }
요청을 보내려면 다음 옵션 중 하나를 펼칩니다.
다음과 비슷한 JSON 응답이 표시됩니다.
REST v1beta4
요청 데이터를 사용하기 전에 다음을 바꿉니다.
- project-id: 프로젝트 ID
- instance-id: 인스턴스 ID
HTTP 메서드 및 URL:
PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id
JSON 요청 본문:
{ "settings": { "backupConfiguration": { "enabled": false, "pointInTimeRecoveryEnabled": false } } }
요청을 보내려면 다음 옵션 중 하나를 펼칩니다.
다음과 비슷한 JSON 응답이 표시됩니다.
PITR에 사용되는 트랜잭션 로그의 스토리지 위치 확인
Cloud SQL 인스턴스가 PITR에 사용되는 트랜잭션 로그를 저장하는 위치를 확인할 수 있습니다.
gcloud
인스턴스가 PITR 로그를 디스크 또는 Cloud Storage에 저장하는지 확인하려면 다음 명령어를 사용합니다.
gcloud sql instances describe INSTANCE_NAME
INSTANCE_NAME을 인스턴스 이름으로 바꿉니다.
또한 동일한 프로젝트에 있는 여러 인스턴스에 대해 트랜잭션 로그의 스토리지 위치를 확인할 수 있습니다. 여러 인스턴스 위치를 확인하려면 다음 명령어를 사용합니다.
gcloud sql instances list --show-transactional-log-storage-state
응답 예:
NAME DATABASE_VERSION LOCATION TRANSACTIONAL_LOG_STORAGE_STATE my_01 POSTGRES_12 us-central-1 DISK my_02 POSTGRES_12 us-central-1 CLOUD_STORAGE ...
명령어 출력의 transactionalLogStorageState
필드나 TRANSACTIONAL_LOG_STORAGE_STATE
열은 PITR의 트랜잭션 로그가 인스턴스에 대해 저장되는 위치에 대한 정보를 제공합니다.
가능한 트랜잭션 로그 스토리지 상태는 다음과 같습니다.
DISK
: 인스턴스가 PITR에 사용되는 트랜잭션 로그를 디스크에 저장합니다. Cloud SQL Enterprise 버전 인스턴스를 Cloud SQL Enterprise Plus 버전으로 업그레이드하는 경우 업그레이드 프로세스에서 로그 스토리지 위치를 자동으로 Cloud Storage로 전환합니다. 자세한 내용은 인플레이스 업그레이드를 사용하여 인스턴스를 Cloud SQL Enterprise Plus 버전으로 업그레이드를 참조하세요. 인스턴스 버전 업그레이드 및 다운타임 없이 gcloud CLI 또는 Cloud SQL Admin API를 사용하여 스토리지 위치를 전환할 수도 있습니다. 자세한 내용은 트랜잭션 로그 스토리지를 Cloud Storage로 전환을 참조하세요.SWITCHING_TO_CLOUD_STORAGE
: 인스턴스가 PITR 트랜잭션 로그의 스토리지 위치를 Cloud Storage로 전환하고 있습니다.SWITCHED_TO_CLOUD_STORAGE
: 인스턴스가 PITR 트랜잭션 로그의 스토리지 위치를 디스크에서 Cloud Storage로 전환하는 작업을 완료하였습니다.CLOUD_STORAGE
: 인스턴스가 PITR에 사용되는 트랜잭션 로그를 Cloud Storage에 저장합니다.
트랜잭션 로그 스토리지를 Cloud Storage로 전환
인스턴스에서 PITR에 사용되는 트랜잭션 로그를 디스크에 저장하는 경우 다운타임 없이 스토리지 위치를 Cloud Storage로 전환할 수 있습니다. 스토리지 위치 전환 전체 프로세스가 완료되는 데 트랜잭션 로그 보관 기간(일)과 비슷한 시간이 소요됩니다. 전환을 시작하자마자 Cloud Storage에 트랜잭션 로그가 누적되기 시작합니다. 작업 중에 PITR에 사용되는 트랜잭션 로그의 스토리지 위치 확인에서 명령어를 사용하여 전체 프로세스 상태를 확인할 수 있습니다.
Cloud Storage로 전환 전체 프로세스가 완료되면 Cloud SQL은 PITR에 Cloud Storage의 트랜잭션 로그를 사용합니다.
gcloud
스토리지 위치를 Cloud Storage로 전환하려면 다음 명령어를 사용합니다.
gcloud sql instances patch INSTANCE_NAME \ --switch-transaction-logs-to-cloud-storage
INSTANCE_NAME을 인스턴스 이름으로 바꿉니다. 인스턴스는 복제본 인스턴스가 아닌 기본 인스턴스여야 합니다. 응답은 다음 예시와 유사합니다.
The following message is used for the patch API method. {"name": "INSTANCE_NAME", "project": "PROJECT_NAME", "switchTransactionalLogsToCloudStorageEnabled": "true"} Patching Cloud SQL instance...done. Updated [https://sqladmin.prod.googleapis.com/v1/projects/PROJECT_NAME/instances/INSTANCE_NAME].
명령어에서 오류를 반환하는 경우 다음 단계는 Cloud Storage로의 전환 문제 해결을 참조하세요.
REST v1
요청 데이터를 사용하기 전에 다음을 바꿉니다.
- PROJECT_ID: 프로젝트 ID
- INSTANCE_ID: 인스턴스 ID입니다. 인스턴스는 복제본 인스턴스가 아닌 기본 인스턴스여야 합니다.
HTTP 메서드 및 URL:
PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID
JSON 요청 본문:
{ "switchTransactionLogsToCloudStorageEnabled": true }
요청을 보내려면 다음 옵션 중 하나를 펼칩니다.
다음과 비슷한 JSON 응답이 표시됩니다.
요청에서 오류를 반환하는 경우 다음 단계는 Cloud Storage로의 전환 문제 해결을 참조하세요.
REST v1beta4
요청 데이터를 사용하기 전에 다음을 바꿉니다.
- PROJECT_ID: 프로젝트 ID
- INSTANCE_ID: 인스턴스 ID입니다. 인스턴스는 복제본 인스턴스가 아닌 기본 인스턴스여야 합니다.
HTTP 메서드 및 URL:
PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID
JSON 요청 본문:
{ "switchTransactionLogsToCloudStorageEnabled": true }
요청을 보내려면 다음 옵션 중 하나를 펼칩니다.
다음과 비슷한 JSON 응답이 표시됩니다.
요청에서 오류를 반환하는 경우 다음 단계는 Cloud Storage로의 전환 문제 해결을 참조하세요.
트랜잭션 로그 보관 설정
미리 쓰기 로그를 보관할 일수를 설정하려면 다음 안내를 따르세요.
콘솔
-
Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.
- 트랜잭션 로그를 설정할 인스턴스의 추가 작업 메뉴 를 열고 수정을 선택합니다.
- 인스턴스 맞춤설정에서 데이터 보호 섹션을 펼칩니다.
- point-in-time recovery 사용 설정 섹션에서 고급 옵션을 확장합니다.
- 로그를 보관할 일수(Cloud SQL Enterprise Plus 버전의 경우 1~35, Cloud SQL Enterprise 버전의 경우 1~7)를 입력합니다.
- 저장을 클릭합니다.
gcloud
인스턴스를 수정하여 미리 쓰기 로그를 보관할 일수를 설정합니다.
다음을 바꿉니다.
- INSTANCE_NAME: 트랜잭션 로그를 설정할 인스턴스의 이름입니다.
DAYS_TO_RETAIN: 트랜잭션 로그 보관 일수입니다. Cloud SQL Enterprise Plus 버전의 경우 유효 범위는 1~35일이며 기본값은 14일입니다. Cloud SQL Enterprise 버전의 경우 유효 범위는 1~7일이며 기본값은 7일입니다.
값을 지정하지 않으면 기본값이 사용됩니다. PITR이 사용 설정된 경우에만 유효합니다. 트랜잭션 로그 보관 일수를 늘리려면 더 큰 스토리지 크기가 필요합니다.
gcloud sql instances patch INSTANCE_NAME \ --retained-transaction-log-days=DAYS_TO_RETAIN
REST v1
요청 데이터를 사용하기 전에 다음을 바꿉니다.
- PROJECT_ID: 프로젝트 ID
- INSTANCE_ID: 인스턴스 ID입니다.
DAYS_TO_RETAIN: 트랜잭션 로그 보관 일수입니다. Cloud SQL Enterprise Plus 버전의 경우 유효 범위는 1~35일이며 기본값은 14일입니다. Cloud SQL Enterprise 버전의 경우 유효 범위는 1~7일이며 기본값은 7일입니다.
값을 지정하지 않으면 기본값이 사용됩니다. PITR이 사용 설정된 경우에만 유효합니다. 트랜잭션 로그 보관 일수를 늘리려면 더 큰 스토리지 크기가 필요합니다.
HTTP 메서드 및 URL:
PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID
JSON 요청 본문:
{ "settings": { "backupConfiguration": { "transactionLogRetentionDays": "DAYS_TO_RETAIN" } } }
요청을 보내려면 다음 옵션 중 하나를 펼칩니다.
다음과 비슷한 JSON 응답이 표시됩니다.
REST v1beta4
요청 데이터를 사용하기 전에 다음을 바꿉니다.
- PROJECT_ID: 프로젝트 ID
- INSTANCE_ID: 인스턴스 ID입니다.
DAYS_TO_RETAIN: 트랜잭션 로그 보관 일수입니다. Cloud SQL Enterprise Plus 버전의 경우 유효 범위는 1~35일이며 기본값은 14일입니다. Cloud SQL Enterprise 버전의 경우 유효 범위는 1~7일이며 기본값은 7일입니다.
값을 지정하지 않으면 기본값이 사용됩니다. PITR이 사용 설정된 경우에만 유효합니다. 트랜잭션 로그 보관 일수를 늘리려면 더 큰 스토리지 크기가 필요합니다.
HTTP 메서드 및 URL:
PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID
JSON 요청 본문:
{ "settings": { "backupConfiguration": { "transactionLogRetentionDays": "DAYS_TO_RETAIN" } } }
요청을 보내려면 다음 옵션 중 하나를 펼칩니다.
다음과 비슷한 JSON 응답이 표시됩니다.
문제 해결
문제 | 문제 해결 |
---|---|
또는
|
입력한 타임스탬프가 잘못되었습니다. |
또는
|
입력한 타임스탬프는 백업 또는 바이너리 좌표를 찾을 수 없는 경우의 시간입니다. |
Cloud Storage로 전환 문제 해결
다음 표에는 트랜잭션 로그의 스토리지 위치를 디스크에서 Cloud Storage로 전환할 때 INVALID REQUEST
코드와 함께 반환될 수 있는 오류가 나와 있습니다.
문제 | 문제 해결 |
---|---|
Switching the storage location of the transaction logs
used for PITR is not supported for instances with database type %s.
|
MySQL용 Cloud SQL 또는 PostgreSQL용 Cloud SQL 인스턴스에서 gcloud CLI 명령어를 실행하거나 API 요청을 보내고 있는지 확인합니다. SQL 서버용 Cloud SQL에서는 gcloud CLI 또는 Cloud SQL Admin API를 사용하여 트랜잭션 로그의 스토리지 위치를 전환할 수 없습니다. |
PostgreSQL transactional logging is not enabled on this instance.
|
PostgreSQL은 PITR (point-in-time recovery)의 트랜잭션 로그로 미리 쓰기 로깅을 사용합니다. PITR을 지원하려면 PostgreSQL에서 인스턴스에 미리 쓰기 로깅을 사용 설정해야 합니다. 미리 쓰기 로깅을 사용 설정하는 방법에 관한 자세한 내용은 PITR 사용 설정을 참고하세요. |
This instance is already storing transaction logs used for PITR in
Cloud Storage
|
트랜잭션 로그의 스토리지 위치를 확인하려면 PITR에 사용되는 트랜잭션 로그의 스토리지 위치 확인에서 명령어를 실행합니다. |
The instance is already switching transaction logs used for PITR from disk
to Cloud Storage.
|
전환 작업이 완료될 때까지 기다립니다. 작업 상태와 트랜잭션 로그의 스토리지 위치를 확인하려면 PITR에 사용되는 트랜잭션 로그의 스토리지 위치 확인에서 명령어를 실행합니다. |
다음 단계
- 클론에 플래그 구성