이 페이지는 Cloud Translation API를 통해 번역되었습니다.

point-in-time recovery(PITR) 사용

MySQL | PostgreSQL | SQL Server

이 페이지에서는 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에 바이너리 로그를 사용합니다.

2023년 8월 11일 PITR의 트랜잭션 로그 저장 기능이 Cloud Storage에 출시되었습니다. 이 출시 이후에는 다음 조건이 적용됩니다.

모든 Cloud SQL Enterprise Plus 버전 인스턴스는 PITR에 사용되는 바이너리 로그를 Cloud Storage에 저장합니다. 2024년 4월 1일 이전에 Cloud SQL Enterprise 버전에서 업그레이드하고 2023년 8월 11일 이전에 PITR을 사용 설정한 Cloud SQL Enterprise Plus 버전 인스턴스만 PITR에 대한 해당 로그를 디스크에 계속 저장합니다..
2023년 8월 11일 이전에 PITR이 사용 설정된 Cloud SQL Enterprise 버전 인스턴스는 PITR에 대한 해당 로그를 계속 디스크에 저장합니다.

참고: 2023년 8월 11일 이전에 생성된 인스턴스의 경우 Cloud SQL은 PITR에 사용되는 트랜잭션 로그의 위치를 자동으로 전환합니다. gcloud CLI 또는 Cloud SQL Admin API를 사용하여 인스턴스의 트랜잭션 로그가 저장되는 위치를 확인할 수 있습니다.
2024년 4월 1일 이후에 디스크에 PITR의 트랜잭션 로그를 저장하는 Cloud SQL Enterprise 버전 인스턴스를 Cloud SQL Enterprise Plus 버전으로 업그레이드하는 경우 업그레이드 프로세스는 PITR에 사용되는 트랜잭션 로그의 스토리지 위치를 Cloud Storage로 전환합니다. 자세한 내용은 인플레이스 업그레이드를 사용하여 인스턴스를 Cloud SQL Enterprise Plus 버전으로 업그레이드를 참조하세요.
2023년 8월 11일 이후에 PITR을 사용 설정하여 만드는 모든 Cloud SQL Enterprise 버전 인스턴스는 Cloud Storage에서 PITR에 사용된 로그를 저장합니다.

PITR에 사용되는 트랜잭션 로그의 스토리지 위치를 확인하는 방법에 대한 자세한 내용은 PITR에 사용되는 트랜잭션 로그의 스토리지 위치 확인을 참조하세요.

바이너리 로그를 디스크에만 저장하는 인스턴스의 경우 다운타임 없이 gcloud CLI 또는 Cloud SQL Admin API를 사용하여 PITR에 사용되는 트랜잭션 로그의 스토리지 위치를 디스크에서 Cloud Storage로 전환할 수 있습니다. 자세한 내용은 트랜잭션 로그 스토리지를 Cloud Storage로 전환을 참조하세요.

로그 보관 기간

Cloud SQL은 Cloud Storage의 트랜잭션 로그를 transactionLogRetentionDays PITR 구성 설정에 설정된 값까지 보관합니다. 이 값은 Cloud SQL Enterprise Plus 버전의 경우 1~35일, Cloud SQL Enterprise 버전의 경우 1~7일입니다. 이 매개변수의 값이 설정되지 않은 경우 기본 트랜잭션 로그 보관 기간은 Cloud SQL Enterprise Plus 버전 인스턴스의 경우 14일, Cloud SQL Enterprise 버전 인스턴스의 경우 7일입니다. 트랜잭션 로그 보관 기간을 설정하는 방법에 대한 자세한 내용은 트랜잭션 로그 보관 설정을 참조하세요.

인스턴스는 Cloud Storage에서 PITR에 사용되는 바이너리 로그를 저장하지만 로그를 Cloud Storage로 복제할 수 있도록 디스크에 더 적은 수의 중복 바이너리 로그도 보존합니다. 기본적으로 PITR이 사용 설정된 인스턴스를 만들면 인스턴스는 PITR에 대한 바이너리 로그를 Cloud Storage에 저장합니다. 또한 Cloud SQL은 expire_logs_days 및 binlog_expire_logs_seconds 플래그의 값을 하루에 해당하는 값으로 자동 설정합니다. 즉, 디스크에 1일 동안의 로그가 있는 것입니다.

디스크에 저장되거나 Cloud Storage로 전환 중이거나 이미 Cloud Storage로 전환된 PITR 바이너리 로그의 경우 Cloud SQL은 다음 구성 중 하나에 설정된 최솟값에 대한 로그를 보관합니다.

transactionLogRetentionDays 백업 구성 설정
expire_logs_days 또는 binlog_expire_logs_seconds 플래그

바이너리 로그가 디스크에 저장되어 있거나 Cloud Storage로 전환 중이거나 이미 Cloud Storage로 전환된 경우 Cloud SQL은 이러한 플래그에 값을 설정하지 않습니다. 로그가 디스크에 저장된 경우 이러한 플래그 값을 수정하면 PITR 복구 동작과 디스크에 저장되는 로그 기간(일)이 영향을 받을 수 있습니다. 로그 스토리지 위치가 Cloud Storage로 전환되는 동안에는 이러한 값을 수정할 수 없습니다. 이러한 플래그 중 하나의 값을 0으로 구성하지 않는 것이 좋습니다. 이러한 플래그에 대한 자세한 내용은 데이터베이스 플래그 구성을 참조하세요.

고객 관리 암호화 키(CMEK) 사용 설정 인스턴스의 경우 바이너리 로그는 최신 버전의 CMEK를 통해 암호화됩니다. 복원을 수행하려면 retained-transaction-log-days 매개변수에 대해 구성한 기간(일) 동안 모든 최신 버전 키 버전을 사용할 수 있어야 합니다.

로그 및 디스크 사용량

로그가 정기적으로 생성되고 저장공간을 사용합니다. 바이너리 로그가 연결된 자동 백업을 사용하여 자동으로 삭제되며 이 작업은 transactionLogRetentionDays에 대해 설정된 값이 충족된 후에 삭제됩니다.

바이너리 로그에서 사용 중인 디스크 양을 확인하려면 인스턴스의 bytes_used_by_data_type 측정항목을 확인합니다. binlog 데이터 유형 값에서 디스크의 binlog 크기를 반환합니다. PITR에 사용되는 트랜잭션 로그를 디스크에 저장하는 인스턴스의 경우 Cloud SQL은 자동 백업 및 트랜잭션 로그 보존에 설명된 대로 transactionLogRetentionDays PITR 설정을 충족하도록 디스크의 데이터를 매일 삭제합니다. 그러나 expire_logs_days 또는 binlog_expire_logs_seconds 플래그를 트랜잭션 로그 보관 일수보다 작은 값으로 설정하면 Cloud SQL에서 바이너리 로그를 더 빨리 영구 삭제할 수 있습니다.

바이너리 로그 크기가 인스턴스에 문제를 일으키는 경우 다음 안내를 따르세요.

인스턴스에서 로그를 디스크에 저장하고 있는지 확인합니다. gcloud CLI 또는 Cloud SQL Admin API를 사용하여 디스크에서 Cloud Storage로 다운타임 없이 PITR에 사용되는 로그의 스토리지 위치를 전환할 수 있습니다. Cloud SQL Enterprise 버전을 사용하는 경우 Cloud SQL Enterprise Plus 버전으로 업그레이드하여 PITR 로그의 스토리지 위치를 전환할 수도 있습니다.
인스턴스 스토리지 크기를 늘리면 됩니다. 하지만 바이너리 로그 크기에 따른 디스크 사용량 증가가 일시적인 것일 수도 있습니다.
예기치 않은 스토리지 문제를 막으려면 스토리지 용량 자동 증가를 사용 설정하는 것이 좋습니다.
로그를 삭제하고 디스크의 저장공간을 복구하려면 PITR을 다시 사용 설정하지 않고 중지하면 됩니다. 하지만 사용되는 저장용량을 줄여도 인스턴스에 프로비저닝된 디스크의 크기는 줄어들지 않습니다.
로그는 매일 한 번씩 영구 삭제되며, 지속적으로 진행되지 않습니다. 로그 보관 기간을 2일로 설정하면 최소 2일 동안의 로그 및 최대 3일 동안의 로그가 보관됩니다. 백업 수를 로그 보관 일수보다 2 이상으로 설정하는 것이 좋습니다.

예를 들어 transactionLogRetentionDays 파라미터 값에 7을 지정하면 backupRetentionSettings 파라미터의 retainedBackups 수를 8로 설정합니다.

PITR에 대한 자세한 내용은 PITR(point-in-time recovery)을 참고하세요.

트랜잭션 로그의 스토리지 위치를 Cloud Storage로 전환을 완료한 후에는 expire_logs_days 또는 binlog_expire_logs_seconds 플래그의 값을 줄여 디스크 공간을 확보할 수 있습니다. 전환 상태를 확인하려면 PITR에 사용되는 트랜잭션 로그의 스토리지 위치 확인을 참조하세요. 하지만 디스크에서 로그를 추가로 사용할 수 있게 하려면(예: mysqlbinlog 유틸리티로 바이너리 로그 탐색) 이러한 플래그의 값을 늘립니다. Cloud SQL은 최소 트랜잭션 로그 보관 일수나 플래그에 설정된 값 동안 바이너리 로그를 디스크에 보관합니다. 전환 후 PITR 로그 저장 방식과 디스크 공간 확보 방법에 대한 자세한 내용은 Cloud Storage로 전환 후 로그를 참조하세요.

PITR 사용 설정

Google Cloud 콘솔에서 새 인스턴스를 만들면 자동 백업 및 PITR(point-in-time recovery) 사용 설정 모두 자동으로 사용 설정됩니다.

다음 절차는 기존의 기본 인스턴스에서 PITR을 사용 설정합니다.

콘솔

Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.

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-bin-log
```
기본 인스턴스에서 PITR을 사용 설정하면 다음 매개변수를 추가하여 트랜잭션 로그 보관 일수를 구성할 수도 있습니다.
```
--retained-transaction-log-days=RETAINED_TRANSACTION_LOG_DAYS
```
변경사항을 확인합니다.
```
gcloud sql instances describe INSTANCE_NAME
```
변경이 성공하면 backupConfiguration 섹션에 binaryLogEnabled: true가 표시됩니다.

Terraform

PITR을 사용 설정하려면 Terraform 리소스를 사용합니다.

resource "google_sql_database_instance" "default" {
  name             = "mysql-instance-pitr"
  region           = "asia-northeast1"
  database_version = "MYSQL_8_0"
  settings {
    tier = "db-f1-micro"
    backup_configuration {
      enabled                        = true
      binary_log_enabled             = true
      start_time                     = "20:55"
      transaction_log_retention_days = "3"
    }
  }
  # set `deletion_protection` to true, will ensure that one cannot accidentally delete this instance by
  # use of Terraform whereas `deletion_protection_enabled` flag protects this instance at the GCP level.
  deletion_protection = false
}

변경사항 적용

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,
      "binaryLogEnabled": true
    }
  }
}

요청을 보내려면 다음 옵션 중 하나를 펼칩니다.

cURL(Linux, macOS, Cloud Shell)

참고: 다음 명령어는 gcloud init 또는 gcloud auth login을 실행하거나 gcloud CLI에 자동으로 로그인하는 Cloud Shell을 사용하여 사용자 계정으로 gcloud CLI에 로그인했다고 가정합니다. gcloud auth list를 실행하면 현재 활성 계정을 확인할 수 있습니다.

요청 본문을 request.json 파일에 저장하고 다음 명령어를 실행합니다.

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME"

PowerShell(Windows)

참고: 다음 명령어는 gcloud init 또는 gcloud auth login을 실행하여 사용자 계정으로 gcloud CLI에 로그인했다고 가정합니다. gcloud auth list를 실행하면 현재 활성 계정을 확인할 수 있습니다.

요청 본문을 request.json 파일에 저장하고 다음 명령어를 실행합니다.

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME" | Select-Object -Expand Content

다음과 비슷한 JSON 응답이 표시됩니다.

응답

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_NAME",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

REST v1beta4

요청 데이터를 사용하기 전에 다음을 바꿉니다.

PROJECT_ID: 인스턴스가 포함된 Google Cloud 프로젝트의 ID 또는 프로젝트 번호
INSTANCE_NAME: 고가용성으로 구성하려는 기본 또는 읽기 복제본 인스턴스의 이름
START_TIME: 시간(시간 및 분)

HTTP 메서드 및 URL:

PATCH https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME

JSON 요청 본문:

{
  "settings":
  {
    "backupConfiguration":
    {
      "startTime": "START_TIME",
      "enabled": true,
      "binaryLogEnabled": true
    }
  }
}

요청을 보내려면 다음 옵션 중 하나를 펼칩니다.

cURL(Linux, macOS, Cloud Shell)

요청 본문을 request.json 파일에 저장하고 다음 명령어를 실행합니다.

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME"

PowerShell(Windows)

요청 본문을 request.json 파일에 저장하고 다음 명령어를 실행합니다.

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME" | Select-Object -Expand Content

다음과 비슷한 JSON 응답이 표시됩니다.

응답

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_NAME",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

타임스탬프를 사용하여 PITR 수행

PITR을 수행하기 위해서는 타임스탬프를 사용하는 것이 좋습니다. Cloud SQL에서는 mysqlbinlog 유틸리티를 사용하여 인스턴스를 특정 시간까지 복원합니다. mysqlbinlog 유틸리티에 대한 자세한 내용은 MySQL 참고 문서를 확인하세요.

다음 태스크를 완료하려면 다음이 있어야 합니다.

인스턴스에 바이너리 로깅 및 백업이 사용 설정되어 있으며, 복구하려는 이벤트 이전의 마지막 백업 이후로 지속적인 바이너리 로그가 있어야 합니다. 자세한 내용은 바이너리 로깅 사용 설정을 참조하세요.
복구 지점을 정의하는 타임스탬프. 이 타임스탬프와 그 이후에 발생한 이벤트는 새 인스턴스에 반영되지 않습니다.

Console

Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.

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"
  }
}

요청을 보내려면 다음 옵션 중 하나를 펼칩니다.

cURL(Linux, macOS, Cloud Shell)

요청 본문을 request.json 파일에 저장하고 다음 명령어를 실행합니다.

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/v1/projects/project-id/instances/source-instance-id/clone"

PowerShell(Windows)

요청 본문을 request.json 파일에 저장하고 다음 명령어를 실행합니다.

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1/projects/project-id/instances/source-instance-id/clone" | Select-Object -Expand Content

다음과 비슷한 JSON 응답이 표시됩니다.

응답

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/project-id/instances/target-instance-id",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "CREATE",
  "name": "operation-id",
  "targetId": "target-instance-id",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

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"
  }
}

요청을 보내려면 다음 옵션 중 하나를 펼칩니다.

cURL(Linux, macOS, Cloud Shell)

요청 본문을 request.json 파일에 저장하고 다음 명령어를 실행합니다.

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/source-instance-id/clone"

PowerShell(Windows)

요청 본문을 request.json 파일에 저장하고 다음 명령어를 실행합니다.

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/source-instance-id/clone" | Select-Object -Expand Content

다음과 비슷한 JSON 응답이 표시됩니다.

응답

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/target-instance-id",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "CREATE",
  "name": "operation-id",
  "targetId": "target-instance-id",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

PITR 비활성화

콘솔

Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.

Cloud SQL 인스턴스로 이동
비활성화할 인스턴스의 추가 작업 메뉴 를 열고 수정을 선택합니다.
인스턴스 맞춤설정에서 데이터 보호 섹션을 펼칩니다.
point-in-time recovery 사용 설정을 선택 해제합니다.
저장을 클릭합니다.

gcloud

PITR(point-in-time recovery) 비활성화:

gcloud sql instances patch INSTANCE_NAME \
--no-enable-bin-log

변경사항을 확인합니다.
```
gcloud sql instances describe INSTANCE_NAME
```
변경이 성공하면 backupConfiguration 섹션에 binaryLogEnabled: 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,
      "binaryLogEnabled": false
    }
  }
}

요청을 보내려면 다음 옵션 중 하나를 펼칩니다.

cURL(Linux, macOS, Cloud Shell)

요청 본문을 request.json 파일에 저장하고 다음 명령어를 실행합니다.

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id"

PowerShell(Windows)

요청 본문을 request.json 파일에 저장하고 다음 명령어를 실행합니다.

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id" | Select-Object -Expand Content

다음과 비슷한 JSON 응답이 표시됩니다.

응답

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "operation-id",
  "targetId": "instance-id",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

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,
      "binaryLogEnabled": false
    }
  }
}

요청을 보내려면 다음 옵션 중 하나를 펼칩니다.

cURL(Linux, macOS, Cloud Shell)

요청 본문을 request.json 파일에 저장하고 다음 명령어를 실행합니다.

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id"

PowerShell(Windows)

요청 본문을 request.json 파일에 저장하고 다음 명령어를 실행합니다.

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id" | Select-Object -Expand Content

다음과 비슷한 JSON 응답이 표시됩니다.

응답

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "operation-id",
  "targetId": "instance-id",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

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 MYSQL_8_0        us-central-1     DISK
my_02 MYSQL_8_0        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
}

요청을 보내려면 다음 옵션 중 하나를 펼칩니다.

cURL(Linux, macOS, Cloud Shell)

요청 본문을 request.json 파일에 저장하고 다음 명령어를 실행합니다.

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID"

PowerShell(Windows)

요청 본문을 request.json 파일에 저장하고 다음 명령어를 실행합니다.

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID" | Select-Object -Expand Content

다음과 비슷한 JSON 응답이 표시됩니다.

응답

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2024-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

요청에서 오류를 반환하는 경우 다음 단계는 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
}

요청을 보내려면 다음 옵션 중 하나를 펼칩니다.

cURL(Linux, macOS, Cloud Shell)

요청 본문을 request.json 파일에 저장하고 다음 명령어를 실행합니다.

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID"

PowerShell(Windows)

요청 본문을 request.json 파일에 저장하고 다음 명령어를 실행합니다.

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID" | Select-Object -Expand Content

다음과 비슷한 JSON 응답이 표시됩니다.

응답

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2024-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

요청에서 오류를 반환하는 경우 다음 단계는 Cloud Storage로의 전환 문제 해결을 참조하세요.

전환 후 트랜잭션 로그 스토리지 및 구성

인스턴스에서 Cloud Storage로 전환 전체 프로세스가 완료된 후에도 Cloud SQL은 복제 목적으로 바이너리 로그 사본을 디스크에 계속 보관합니다. 디스크에 바이너리 로그를 저장하는 것은 mysqlbinlog 유틸리티로 바이너리 로그를 탐색하려는 경우에 유용할 수 있습니다.

전환 전에 인스턴스에서 expire_logs_days 또는 binlog_expire_logs_seconds 플래그를 구성한 경우 구성된 값은 그대로 유지됩니다.

전환 후에는 PITR을 수행하는 데 사용되는 바이너리 로그가 Cloud Storage에 저장되므로 플래그 값이 예상 디스크에 트랜잭션 로그 보관을 반영하는지 확인합니다. Cloud SQL은 다음 중 하나의 최솟값에 대한 로그를 디스크에만 보관합니다.

전환 전 transactionLogRetentionDays PITR 구성 설정 이 설정의 기본값은 7일입니다.
인스턴스에 수동으로 설정된 expire_logs_days 또는 binlog_expire_logs_seconds 플래그

디스크 공간을 절약하려면 전환 프로세스가 완료된 후에 expire_logs_days 또는 binlog_expire_logs_seconds 플래그의 값을 1일로 구성하여 할당된 디스크 크기와 디스크 스토리지 비용을 줄이세요. 트랜잭션 로그 스토리지와 PITR에 대한 자세한 내용은 PITR의 로그 스토리지를 참조하세요.

디스크 사용량을 확인하는 방법에 대한 자세한 내용은 로그 및 디스크 사용량을 참조하세요.

트랜잭션 로그 보관 설정

바이너리 로그를 보관할 일수를 설정하려면 다음 안내를 따르세요.

콘솔

Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.

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"
    }
  }
}

요청을 보내려면 다음 옵션 중 하나를 펼칩니다.

cURL(Linux, macOS, Cloud Shell)

요청 본문을 request.json 파일에 저장하고 다음 명령어를 실행합니다.

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID"

PowerShell(Windows)

요청 본문을 request.json 파일에 저장하고 다음 명령어를 실행합니다.

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID" | Select-Object -Expand Content

다음과 비슷한 JSON 응답이 표시됩니다.

응답

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

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"
    }
  }
}

요청을 보내려면 다음 옵션 중 하나를 펼칩니다.

cURL(Linux, macOS, Cloud Shell)

요청 본문을 request.json 파일에 저장하고 다음 명령어를 실행합니다.

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID"

PowerShell(Windows)

요청 본문을 request.json 파일에 저장하고 다음 명령어를 실행합니다.

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID" | Select-Object -Expand Content

다음과 비슷한 JSON 응답이 표시됩니다.

응답

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

바이너리 로그 위치를 사용하여 PITR 수행

타임스탬프를 사용하여 PITR 수행에 설명된 대로 타임스탬프를 사용하여 PITR을 수행하는 것이 좋지만 바이너리 로그 파일에 특정 바이너리 로그 위치를 제공하여 PITR을 수행할 수도 있습니다.

바이너리 로그 위치를 사용하는 PITR에 대한 자세한 내용은 MySQL 참조인 바이너리 로그를 사용한 PITR을 참조하세요.

시작하기 전에

이 작업을 완료하려면 다음이 필요합니다.

인스턴스에 바이너리 로깅 및 백업이 사용 설정되어 있으며, 복구하려는 이벤트 이전의 마지막 백업 이후로 지속적인 바이너리 로그가 있어야 함 자세한 내용은 바이너리 로깅 사용 설정을 참조하세요.
이벤트를 찾아보려면 디스크에서 바이너리 로그를 사용할 수 있어야 합니다. 디스크의 바이너리 로그 보관 기간을 확인하려면 로그 보관 기간을 참조하세요. mysqlbinlog 유틸리티로는 Cloud Storage에 저장된 바이너리 로그를 찾아볼 수 없습니다.
바이너리 로그 파일 이름과 복구하려는 이벤트의 위치(해당 이벤트와 그 이후의 모든 이벤트는 새 인스턴스에 반영되지 않음). 자세한 내용은 바이너리 로그 위치 식별을 참조하세요.

바이너리 로그 파일 이름과 위치를 식별한 후에는 바이너리 로그 이벤트 위치를 사용하여 PITR을 수행합니다.

복구 위치 식별

MySQL 클라이언트를 사용하여 복원하려는 인스턴스에 연결합니다.

이렇게 하려면 Cloud Shell 또는 로컬 클라이언트 머신을 사용합니다. 자세한 내용은 외부 애플리케이션 연결 옵션을 참조하세요.
인스턴스의 바이너리 로그 파일을 표시합니다.
```
SHOW BINARY LOGS;
```
최근 로그 파일의 최초 이벤트 100개를 표시합니다.
```
SHOW BINLOG EVENTS IN '<BINARY_LOG_FILE>' LIMIT 100;
```
표시할 행의 수를 조정할 수 있지만 파일의 크기를 알기 전까지는 파일 내의 모든 이벤트를 표시하지 않는 것이 좋습니다. 대량의 이벤트를 표시하면 시스템 성능이 저하될 수 있습니다.
찾고 있는 이벤트가 표시되지 않으면 시작 지점으로 표시된 마지막 위치를 사용하여 다음 이벤트 집합을 검색합니다.
```
SHOW BINLOG EVENTS IN '<BINARY_LOG_FILE>' FROM <POSITION> LIMIT 100;
```
복원하려는 특정 시점을 표시하는 이벤트를 찾으면 위치(Pos로 표시됨)와 바이너리 로그 파일 이름을 기록합니다.

바이너리 로그 파일 이름과 위치는 PITR에 사용되는 값입니다.

아래는 SHOW BINLOG EVENTS 명령어로 출력된 샘플입니다.

+------------------+-----+-------------+-----------+-------------+-----------------------------------------------------+
| Log_name         | Pos | Event_type  | Server_id | End_log_pos | Info                                                |
+------------------+-----+-------------+-----------+-------------+-----------------------------------------------------+
| mysql-bin.000011 |   4 | Format_desc |  88955285 |         120 | Server ver: 5.6.30-log, Binlog ver: 4               |
| mysql-bin.000011 | 120 | Query       |  88955285 |         211 | create database db1                                 |
| mysql-bin.000011 | 211 | Query       |  88955285 |         310 | use `db1`; CREATE TABLE t (c CHAR(20))              |
| mysql-bin.000011 | 310 | Query       |  88955285 |         381 | BEGIN                                               |
| mysql-bin.000011 | 381 | Table_map   |  88955285 |         426 | table_id: 18 (db1.t)                                |
| mysql-bin.000011 | 310 | Query       |  88955285 |         381 | BEGIN                                               |

| mysql-bin.000011 | 426 | Write_rows  |  88955285 |         464 | table_id: 18 flags: STMT_END_F                      |
| mysql-bin.000011 | 464 | Xid         |  88955285 |         495 | COMMIT /* xid=56 */                                 |
| mysql-bin.000011 | 495 | Query       |  88955285 |         566 | BEGIN                                               |
| mysql-bin.000011 | 566 | Table_map   |  88955285 |         611 | table_id: 18 (db1.t)                                |
| mysql-bin.000011 | 611 | Write_rows  |  88955285 |         649 | table_id: 18 flags: STMT_END_F                      |
| mysql-bin.000011 | 649 | Xid         |  88955285 |         680 | COMMIT /* xid=57 */                                 |
| mysql-bin.000011 | 680 | Query       |  88955285 |         751 | BEGIN                                               |
| mysql-bin.000011 | 751 | Table_map   |  88955285 |         796 | table_id: 18 (db1.t)                                |
| mysql-bin.000011 | 796 | Write_rows  |  88955285 |         834 | table_id: 18 flags: STMT_END_F                      |
| mysql-bin.000011 | 834 | Xid         |  88955285 |         865 | COMMIT /* xid=58 */                                 |
| mysql-bin.000011 | 865 | Query       |  88955285 |         977 | use `db1`; DROP TABLE `t` /* generated by server */ |
+------------------+-----+-------------+-----------+-------------+-----------------------------------------------------+
16 rows in set (0.04 sec)

위에서 굵게 표시되어 있는 DROP TABLE 문까지 복원하려면 'mysql-bin.000011'에 복구 위치로 '865'를 사용합니다. DROP TABLE 문과 그 다음의 모든 작업은 새 인스턴스에 반영되지 않습니다.

바이너리 로그 이벤트 위치를 사용하여 PITR 수행

gcloud

gcloud sql instances clone 명령어를 --bin-log-file-name 및 --bin-log-position 플래그와 함께 사용합니다.

바이너리 로그 파일 이름과 복구 위치를 사용하여 새 인스턴스를 만듭니다.

다음을 바꿉니다.
- SOURCE_INSTANCE_NAME: 복원할 인스턴스의 이름입니다.
- NEW_INSTANCE_NAME: 클론 이름입니다.
- BINLOG_FILE_NAME: 바이너리 로그 이름입니다(예: mysql-bin.187288).
- POSITION: 복원할 바이너리 로그 위치입니다(예: 50001356).
```
gcloud sql instances clone SOURCE_INSTANCE_NAME \
NEW_INSTANCE_NAME \
--bin-log-file-name="BINLOG_FILE_NAME" \
--bin-log-position=POSITION
```
예를 들어 gcloud sql instances clone 명령어는 다음과 비슷하게 표시됩니다.
```
gcloud sql instances clone instance1 \
instance1-clone \
--bin-log-file-name=mysql-bin.0000031 \
--bin-log-position=107 \
```
clone 명령어에서 반환된 작업 ID를 사용하여 복원 작업 상태를 확인합니다.
```
gcloud sql operations describe OPERATION_ID
```
작업이 진행 중이면 RUNNING 상태가 반환됩니다. 작업이 완료되면 DONE 상태가 반환됩니다.

REST v1

식별한 바이너리 로그 파일 이름과 복구 위치를 사용하여 새 인스턴스를 만듭니다.

요청 데이터를 사용하기 전에 다음을 바꿉니다.

project-id: 프로젝트 ID
target-instance-id: 대상 인스턴스 ID
source-instance-id: 소스 인스턴스 ID
binary-log-file-name: 바이너리 로그 파일의 이름
binary-log-position: 바이너리 로그 파일 내 위치

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",
    "binLogCoordinates":
    {
      "kind": "sql#binLogCoordinates",
      "binLogFileName": "binary-log-file-name",
      "binLogPosition": "binary-log-position"
    }
  }
}

요청을 보내려면 다음 옵션 중 하나를 펼칩니다.

cURL(Linux, macOS, Cloud Shell)

요청 본문을 request.json 파일에 저장하고 다음 명령어를 실행합니다.

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/v1/projects/project-id/instances/source-instance-id/clone"

PowerShell(Windows)

요청 본문을 request.json 파일에 저장하고 다음 명령어를 실행합니다.

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1/projects/project-id/instances/source-instance-id/clone" | Select-Object -Expand Content

다음과 비슷한 JSON 응답이 표시됩니다.

응답

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/project-id/instances/target-instance-id",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "CREATE",
  "name": "operation-id",
  "targetId": "target-instance-id",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

REST v1beta4

확인한 바이너리 로그 파일 이름과 복구 위치를 사용하여 새 인스턴스를 만듭니다.

요청 데이터를 사용하기 전에 다음을 바꿉니다.

project-id: 프로젝트 ID
target-instance-id: 대상 인스턴스 ID
source-instance-id: 소스 인스턴스 ID
binary-log-file-name: 바이너리 로그 파일의 이름
binary-log-position: 바이너리 로그 파일 내 위치

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",
    "binLogCoordinates":
    {
      "kind": "sql#binLogCoordinates",
      "binLogFileName": "binary-log-file-name",
      "binLogPosition": "binary-log-position"
    }
  }
}

요청을 보내려면 다음 옵션 중 하나를 펼칩니다.

cURL(Linux, macOS, Cloud Shell)

요청 본문을 request.json 파일에 저장하고 다음 명령어를 실행합니다.

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/source-instance-id/clone"

PowerShell(Windows)

요청 본문을 request.json 파일에 저장하고 다음 명령어를 실행합니다.

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/source-instance-id/clone" | Select-Object -Expand Content

다음과 비슷한 JSON 응답이 표시됩니다.

응답

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/target-instance-id",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "CREATE",
  "name": "operation-id",
  "targetId": "target-instance-id",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

문제 해결

문제 문제 해결

문제	문제 해결
`argument --point-in-time: Failed to parse date/time: Unknown string format: 2021-0928T30:54:03.094; received: 2021-0928T30:54:03.094Z` 또는 `Invalid value at 'body.clone_context.point_in_time' (type.googleapis.com/google.protobuf.Timestamp), Field 'pointInTime', Invalid time format: Failed to parse input,`	입력한 타임스탬프가 잘못되었습니다.
`HTTP Error 400: Successful backup required for carrying out the operation was not found.` 또는 `Successful backup required for carrying out the operation was not found. or Time where no backups can be found.`	입력한 타임스탬프는 백업 또는 바이너리 좌표를 찾을 수 없는 경우의 시간입니다.

argument --point-in-time: Failed to parse date/time: Unknown string format: 2021-0928T30:54:03.094; received: 2021-0928T30:54:03.094Z

또는

Invalid value at 'body.clone_context.point_in_time' (type.googleapis.com/google.protobuf.Timestamp), Field 'pointInTime', Invalid time format: Failed to parse input,

입력한 타임스탬프가 잘못되었습니다.

HTTP Error 400: Successful backup required for carrying out the operation was not found.

또는

Successful backup required for carrying out the operation was not found. or Time where no backups can be found.

입력한 타임스탬프는 백업 또는 바이너리 좌표를 찾을 수 없는 경우의 시간입니다.

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를 사용하여 트랜잭션 로그의 스토리지 위치를 전환할 수 없습니다.
`MySQL transactional logging is not enabled on this instance.`	MySQL은 PITR(point-in-time recovery)의 트랜잭션 로그로 바이너리 로깅을 사용합니다. PITR을 지원하려면 MySQL에서 인스턴스에 바이너리 로깅을 사용 설정해야 합니다. 바이너리 로깅을 사용 설정하는 방법에 대한 자세한 내용은 PITR 사용 설정을 참조하세요.
`This command is not supported on replica instances. Run the command on the primary instance instead.`	명령어를 실행하거나 API 요청을 보낼 때 기본 인스턴스를 지정해야 합니다.
`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에 사용되는 트랜잭션 로그의 스토리지 위치 확인에서 명령어를 실행합니다.

다음 단계

클론에 플래그 구성