point-in-time recovery

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

point-in-time recovery에 대한 자세한 내용은 이 페이지를 참조하세요.

시작하기 전에

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

  • 인스턴스에 바이너리 로깅 및 백업이 사용 설정되어 있으며, 복구하려는 이벤트 이전의 마지막 백업 이후로 지속적인 바이너리 로그가 있어야 합니다. 자세한 내용은 바이너리 로깅 사용 설정하기를 참조하세요.

  • 바이너리 로그 파일 이름과 복구하려는 이벤트의 위치(해당 이벤트와 그 이후의 모든 이벤트는 새 인스턴스에 반영되지 않음). 자세한 내용은 바이너리 로그 위치 확인하기를 참조하세요.

    바이너리 로그 파일과 위치가 식별되면 point-in-time recovery를 수행할 수 있습니다.

바이너리 로그 사용 설정

Console

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

    Cloud SQL 인스턴스 페이지로 이동

  2. point-in-time recovery를 사용 설정할 인스턴스를 선택합니다.
  3. 수정을 클릭합니다.
  4. 백업, 복구, 고가용성 섹션에서 백업 자동화를 선택하고 point-in-time recovery 사용 설정을 선택합니다.
  5. 저장을 클릭합니다.
  6. 인스턴스의 인스턴스 세부정보 페이지에 binaryLogEnabledtrue로 표시됩니다.

gcloud

  1. 인스턴스 세부정보를 표시합니다.
    gcloud sql instances describe [INSTANCE_NAME]
    
  2. backupConfigurationenabled: 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
    
    
  4. 변경사항 확인:
    gcloud sql instances describe [INSTANCE_NAME]
    

    backupConfiguration 아래에서 binaryLogEnabled: true를 찾습니다.

REST

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

  • project-id: 프로젝트 ID
  • instance-id: 인스턴스 ID
  • start-time 'HH:MM' 형식의 시간

HTTP 메서드 및 URL:

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

JSON 요청 본문:

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

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

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

복구 위치 확인

특정 시점 복구를 수행하려면 인스턴스를 복구하려는 특정 시점에 해당하는 바이너리 로그 파일 이름과 위치를 확인해 두어야 합니다.

MySQL 클라이언트를 사용하여 이 작업을 수행할 수 있습니다.

  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로 표시됨)와 로그 파일의 이름을 기록합니다.

    로그 파일 이름과 위치는 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 문과 그 다음의 모든 작업은 새 인스턴스에 반영되지 않습니다.

point-in-time recovery 수행하기

Console

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

    Cloud SQL 인스턴스 페이지로 이동

  2. 복구할 인스턴스의 추가 작업 메뉴 추가 작업 아이콘를 열고 클론을 클릭합니다.
  3. 클론 만들기 창에서 필요한 경우 새 인스턴스의 이름을 업데이트합니다.
  4. 이전 시간에서 클론을 선택합니다.
  5. 바이너리 로그 파일 이름에 이전에 식별한 바이너리 로그의 이름을 입력합니다.
  6. 복구 위치에 이벤트의 위치를 입력합니다.
  7. 클론 만들기를 클릭합니다.

gcloud

  1. 확인한 바이너리 로그 파일 이름과 복구 위치를 사용하여 새 인스턴스를 만듭니다.
    gcloud sql instances clone [SOURCE_INSTANCE_NAME] [NEW_INSTANCE_NAME] \
           --bin-log-file-name=[BINLOG_FILE_NAME] --bin-log-position=[POSITION]
    

    예를 들어 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 상태가 반환됩니다.

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

REST

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

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

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

HTTP 메서드 및 URL:

POST https://www.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 응답이 표시됩니다.

바이너리 로그 사용 중지

Console

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

    Cloud SQL 인스턴스 페이지로 이동

  2. point-in-time recovery를 사용 중지할 인스턴스를 선택합니다.
  3. 수정을 클릭합니다.
  4. 백업, 복구, 고가용성 섹션에서 point-in-time recovery 사용 설정을 선택 해제합니다.
  5. 저장을 클릭합니다.
  6. 인스턴스의 인스턴스 세부정보 페이지에 binaryLogEnabledfalse로 표시됩니다.

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

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

  • project-id: 프로젝트 ID
  • instance-id: 인스턴스 ID

HTTP 메서드 및 URL:

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

JSON 요청 본문:

{
  "settings":
  {
    "backupConfiguration":
    {
      "enabled": false,
      "binaryLogEnabled": false
    }
  }
}

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

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

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

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

바이너리 로그 크기로 인해 인스턴스에 문제가 발생하면 인스턴스 저장용량 크기를 늘리면 됩니다. 하지만 바이너리 로그 크기에 따른 디스크 사용량 증가가 일시적인 것일 수도 있습니다. PITR을 사용할 때는 예기치 않은 저장용량 문제가 발생하지 않도록 저장용량 자동 증가를 사용 설정하는 것이 좋습니다.

로그를 삭제하고 저장용량을 복구하려면 point-in-time recovery를 사용 중지하면 됩니다. 하지만 사용되는 저장용량을 줄여도 인스턴스에 프로비저닝된 저장용량의 크기가 축소되는 것은 아닙니다.