Point-in-time recovery 사용

이 페이지에서는 PITR(point-in-time recovery)을 사용하여 Cloud SQL 인스턴스를 복원하는 방법을 설명합니다.

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

point-in-time recovery 사용 설정

Google Cloud Console에서 새 인스턴스를 만들면 자동 백업 및 PITR(point-in-time recovery) 사용 설정 모두 자동으로 사용 설정됩니다. 이 절차는 기존 인스턴스에 PITR(point-in-time recovery)을 사용 설정합니다.

Console

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

    Cloud SQL 인스턴스로 이동

  2. PITR(point-in-time recovery)을 사용 설정할 인스턴스의 추가 작업 메뉴 추가 작업 아이콘를 열고 수정을 클릭합니다.
  3. 인스턴스 맞춤설정에서 백업 섹션을 펼칩니다.
  4. PITR(point-in-time recovery) 사용 설정 체크박스를 선택합니다.
  5. 고급 옵션을 펼칩니다.
  6. 로그를 보관할 일수(1~7)를 추가합니다.
  7. 저장을 클릭합니다.

gcloud

  1. 인스턴스 개요를 표시합니다. 
    gcloud sql instances describe INSTANCE_NAME
  2. backupConfiguration 섹션에 enabled: false가 표시되면 예약된 백업을 사용 설정합니다. 
    gcloud sql instances patch INSTANCE_NAME \
--backup-start-time=HH:MM

    UTC±00 시간대의 24시간제를 사용하여 backup-start-time 매개변수를 지정합니다.

  3. point-in-time recovery 사용 설정: 
    gcloud sql instances patch INSTANCE_NAME \
--enable-bin-log

    기본 인스턴스에서 point-in-time recovery를 사용 설정하는 경우 다음 매개변수를 추가하여 트랜잭션 로그를 보관할 일수를 구성할 수도 있습니다.

    --retained-transaction-log-days=RETAINED_TRANSACTION_LOG_DAYS
  4. 변경사항을 확인합니다. 
    gcloud sql instances describe INSTANCE_NAME

    변경이 성공하면 backupConfiguration 섹션에 binaryLogEnabled: true가 표시됩니다.

Terraform

PITR(point-in-time recovery)을 사용 설정하려면 Terraform 리소스를 사용합니다.

sql_instance_pitr/main.tf 
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"
    }
  }
  deletion_protection =  "true"
}

REST v1

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

  • project-id: 프로젝트 ID
  • instance-id: 인스턴스 ID(기본 또는 복제본)
  • start-time 'HH:MM' 형식의 시간

HTTP 메서드 및 URL: 

PATCH https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id

JSON 요청 본문:

{
  "settings":
  {
    "backupConfiguration":
    {
      "startTime": "start-time",
      "enabled": true,
      "binaryLogEnabled": true
    }
  }
}

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

다음과 유사한 JSON 응답이 표시됩니다.

REST v1beta4

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

  • project-id: 프로젝트 ID
  • instance-id: 인스턴스 ID(기본 또는 복제본)
  • start-time 'HH:MM' 형식의 시간

HTTP 메서드 및 URL: 

PATCH https://sqladmin.googleapis.com/v1beta4/projects/project-id/instances/instance-id

JSON 요청 본문:

{
  "settings":
  {
    "backupConfiguration":
    {
      "startTime": "start-time",
      "enabled": true,
      "binaryLogEnabled": true
    }
  }
}

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

다음과 유사한 JSON 응답이 표시됩니다.

PITR(point-in-time recovery) 수행

Console

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

    Cloud SQL 인스턴스로 이동

  2. 복구할 인스턴스의 추가 작업 메뉴 (추가 작업 아이콘)을 열고 클론을 클릭합니다.
  3. 선택사항. 클론 만들기 페이지에서 새 인스턴스 이름을 업데이트합니다.
  4. 이전 시간에서 클론을 선택합니다.
  5. point-in-time recovery 시간을 입력합니다.
  6. 클론 만들기를 클릭합니다.

gcloud

PITR(point-in-time recovery)을 사용하여 클론을 만듭니다.

다음을 바꿉니다.

  • 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(point-in-time recovery) 중지

Console

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

    Cloud SQL 인스턴스로 이동

  2. 중지할 인스턴스의 추가 작업 메뉴 추가 작업 아이콘를 열고 수정을 선택합니다.
  3. 인스턴스 맞춤설정에서 백업 섹션을 펼칩니다.
  4. PITR(point-in-time recovery) 사용 설정을 선택 해제합니다.
  5. 저장을 클릭합니다.
  6. 인스턴스의 개요 페이지에 binaryLogEnabled가 false로 표시됩니다.

gcloud

  1. point-in-time recovery를 사용 중지합니다. 
    gcloud sql instances patch INSTANCE_NAME \
--no-enable-bin-log
  2. 변경사항을 확인합니다. 
    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
    }
  }
}

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

다음과 유사한 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,
      "binaryLogEnabled": false
    }
  }
}

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

다음과 유사한 JSON 응답이 표시됩니다.

디스크 사용량 및 point-in-time recovery

PITR(point-in-time recovery)에서는 바이너리 로그를 사용합니다. 이 로그는 정기적으로 업데이트되고 저장공간을 사용합니다. 일반적으로 약 7일 후에 관련된 자동 백업과 함께 자동으로 삭제됩니다.

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

  • 인스턴스 스토리지 크기를 늘리면 됩니다. 하지만 바이너리 로그 크기에 따른 디스크 사용량 증가가 일시적인 것일 수도 있습니다.

  • 예기치 않은 스토리지 문제를 막으려면 스토리지 용량 자동 증가를 사용 설정하는 것이 좋습니다.

  • 로그를 삭제하고 스토리지를 복구하려면 PITR(point-in-time recovery)을 중지하면 됩니다. 사용되는 스토리지를 줄여도 인스턴스에 프로비저닝된 스토리지의 크기는 줄어들지 않습니다.

  • 로그는 매일 한 번씩 영구 삭제되며, 지속적으로 진행되지 않습니다. 로그 보관 기간을 2일로 설정하면 최소 2일 동안의 로그 및 최대 3일 동안의 로그가 보관됩니다. 지정된 최소 로그 보관 일수를 보장하려면 백업 수를 로그 보존 일수보다 2 이상으로 설정하는 것이 좋습니다.

트랜잭션 로그 보관 설정

바이너리 로그를 보존할 일 수(1~7)를 설정하려면 다음 안내를 따르세요.

콘솔

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

    Cloud SQL 인스턴스로 이동

  2. 트랜잭션 로그를 설정할 인스턴스의 추가 작업 메뉴 추가 작업 아이콘를 열고 수정을 선택합니다.
  3. 인스턴스 맞춤설정에서 백업 섹션을 펼칩니다.
  4. point-in-time recovery 사용 설정 섹션에서 고급 옵션을 확장합니다.
  5. 로그를 보관할 일수(1~7)를 추가합니다.
  6. 저장을 클릭합니다.

gcloud

인스턴스를 수정하여 바이너리 로그를 보관할 일수를 설정합니다.

다음을 바꿉니다.

  • INSTANCE-NAME - 트랜잭션 로그를 설정할 인스턴스의 이름입니다.
  • DAYS-TO-RETAIN - 트랜잭션 로그 보관 일수입니다. 유효 범위는 1~7입니다. 지정하지 않으면 기본값은 7입니다. PITR(point-in-time recovery)이 사용 설정된 경우에만 유효합니다. 트랜잭션 로그 보관 일수를 올리려면 더 큰 스토리지 크기가 필요합니다.
gcloud sql instances patch INSTANCE-NAME 

--retained-transaction-log-days=DAYS-TO-RETAIN

REST v1beta4

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

  • days-to-retain: 트랜잭션 로그를 보관할 일수(1~7일)
  • project-id: 프로젝트 ID
  • instance-id: 인스턴스 ID

HTTP 메서드 및 URL: 

PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id

JSON 요청 본문:

{
  "settings":
  {
    "backupConfiguration":
    {
      "transactionLogRetentionDays": "days-to-retain"
    }
  }
}

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

다음과 유사한 JSON 응답이 표시됩니다.

바이너리 로그 위치를 사용하여 PITR(point-in-time recovery) 수행

이전 절차의 설명대로 타임스탬프를 사용하여 PITR(point-in-time recovery)을 수행하는 것이 좋지만 바이너리 로그 파일에 특정 바이너리 로그 위치를 제공하여 PITR(point-in-time recovery)을 수행할 수도 있습니다.

바이너리 로그 위치를 사용한 PITR(point-in-time recovery)에 대한 자세한 내용은 MySQL 참조 자료인 바이너리 로그를 사용한 PITR(point-in-time recovery)을 참조하세요.

시작하기 전에

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

복구 위치 식별

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

    이렇게 하려면 Cloud Shell 또는 로컬 클라이언트 머신을 사용합니다. 자세한 내용은 외부 애플리케이션 연결 옵션을 참조하세요.

  2. 인스턴스의 바이너리 로그 파일을 표시합니다.

    SHOW BINARY LOGS;

  3. 최근 로그 파일의 최초 이벤트 100개를 표시합니다.

    SHOW BINLOG EVENTS IN '<BINARY_LOG_FILE>' LIMIT 100;

    표시할 행의 수를 조정할 수 있지만 파일의 크기를 알기 전까지는 파일 내의 모든 이벤트를 표시하지 않는 것이 좋습니다. 대량의 이벤트를 표시하면 시스템 성능이 저하될 수 있습니다.

  4. 찾고 있는 이벤트가 표시되지 않으면 시작 지점으로 표시된 마지막 위치를 사용하여 다음 이벤트 집합을 검색합니다.

    SHOW BINLOG EVENTS IN '<BINARY_LOG_FILE>' FROM <POSITION> LIMIT 100;

  5. 복원하려는 특정 시점을 표시하는 이벤트를 찾으면 위치(Pos로 표시됨)와 바이너리 로그 파일 이름을 기록합니다.

    바이너리 로그 파일 이름과 위치는 PITR(point-in-time recovery)에 사용되는 값입니다.

아래는 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(point-in-time recovery) 수행

gcloud

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

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

    다음을 바꿉니다.

    • 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 \
  2. 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"
    }
  }
}

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

다음과 유사한 JSON 응답이 표시됩니다.

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

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

다음과 유사한 JSON 응답이 표시됩니다.

문제해결

문제 문제 해결하기

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

OR

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.

OR

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

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

다음 단계