이 페이지에서는 point-in-time recovery를 사용하여 Cloud SQL 인스턴스 작업을 복원하는 방법을 설명합니다.
point-in-time recovery에 대한 자세한 내용은 이 페이지를 참조하세요.
시작하기 전에
이 작업을 완료하려면 다음이 필요합니다.
인스턴스에 바이너리 로깅 및 백업이 사용 설정되어 있으며, 복구하려는 이벤트 이전의 마지막 백업 이후로 지속적인 바이너리 로그가 있어야 함 자세한 내용은 바이너리 로깅 사용 설정하기를 참조하세요.
바이너리 로그 파일 이름과 복구하려는 이벤트의 위치(해당 이벤트와 그 이후의 모든 이벤트는 새 인스턴스에 반영되지 않음) 자세한 내용은 바이너리 로그 위치 확인하기를 참조하세요.
바이너리 로그 파일과 위치가 식별되면 point-in-time recovery를 수행할 수 있습니다.
point-in-time recovery 사용 설정
Console
- Google Cloud Console의 Cloud SQL 인스턴스 페이지로 이동합니다.
- point-in-time recovery를 사용 설정할 인스턴스를 선택합니다.
- 수정을 클릭합니다.
- 백업, 복구, 고가용성 섹션에서 백업 자동화를 선택하고 point-in-time recovery 사용 설정을 선택합니다.
- 저장을 클릭합니다.
- 인스턴스의 인스턴스 세부정보 페이지에 binaryLogEnabled가 true로 표시됩니다.
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매개변수를 지정합니다.- point-in-time recovery 사용 설정:
gcloud sql instances patch [INSTANCE_NAME] --enable-bin-log
- 변경사항을 확인합니다.
gcloud sql instances describe [INSTANCE_NAME]
backupConfiguration아래에서binaryLogEnabled: true를 찾습니다.
REST v1beta4
아래의 요청 데이터를 사용하기 전에 다음을 바꿉니다.
- project-id: 프로젝트 ID
- instance-id: 인스턴스 ID(기본 또는 복제본)
- start-time 'HH:MM' 형식의 시간
- enabled: 기본 인스턴스의 경우 true로 설정합니다. 복제본 인스턴스의 경우 false로 설정합니다.
HTTP 메서드 및 URL:
PATCH https://www.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id
JSON 요청 본문:
{
"settings":
{
"backupConfiguration":
{
"startTime": "start-time",
"enabled": enabled,
"binaryLogEnabled": true
}
}
}
요청을 보내려면 다음 옵션 중 하나를 펼칩니다.
다음과 유사한 JSON 응답이 표시됩니다.
복구 위치 확인
특정 point-in-time recovery를 수행하려면 인스턴스를 복구하려는 특정 시점에 해당하는 바이너리 로그 파일 이름과 위치를 확인해 두어야 합니다.
MySQL 클라이언트를 사용하여 이 작업을 수행할 수 있습니다.
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로 표시됨)와 로그 파일의 이름을 기록합니다.로그 파일 이름과 위치는 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
- Google Cloud Console의 Cloud SQL 인스턴스 페이지로 이동합니다.
- 복구할 인스턴스의 추가 작업 메뉴
를 열고 클론을 클릭합니다. - 클론 만들기 창에서 필요한 경우 새 인스턴스의 이름을 업데이트합니다.
- 이전 시간에서 클론을 선택합니다.
- 바이너리 로그 파일 이름에 이전에 식별한 바이너리 로그의 이름을 입력합니다.
- 복구 위치에 이벤트의 위치를 입력합니다.
- 클론 만들기를 클릭합니다.
gcloud
- 확인한 바이너리 로그 파일 이름과 복구 위치를 사용하여 새 인스턴스를 만듭니다.
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 clone명령어에서 반환된 작업 ID를 사용하여 복원 작업의 상태를 확인합니다.gcloud sql operations describe [OPERATION_ID]
작업이 진행 중이면RUNNING상태가 반환됩니다. 작업이 완료되었으면DONE상태가 반환됩니다.
특정 시점 복구에 대한 자세한 내용은 MySQL 참조 자료인 바이너리 로그를 사용한 특정 시점 복구를 참조하세요.
REST v1beta4
확인한 바이너리 로그 파일 이름과 복구 위치를 사용하여 새 인스턴스를 만듭니다.
아래의 요청 데이터를 사용하기 전에 다음을 바꿉니다.
- 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
- Google Cloud Console의 Cloud SQL 인스턴스 페이지로 이동합니다.
- point-in-time recovery를 중지할 인스턴스를 선택합니다.
- 수정을 클릭합니다.
- 백업, 복구, 고가용성 섹션에서 point-in-time recovery 사용 설정을 선택 해제합니다.
- 저장을 클릭합니다.
- 인스턴스의 인스턴스 세부정보 페이지에 binaryLogEnabled가 false로 표시됩니다.
gcloud
- point-in-time recovery를 사용 중지합니다.
gcloud sql instances patch [INSTANCE_NAME] --no-enable-bin-log - 변경사항을 확인합니다.
gcloud sql instances describe [INSTANCE_NAME]
backupConfiguration아래에서binaryLogEnabled: false를 찾습니다.
REST v1beta4
아래의 요청 데이터를 사용하기 전에 다음을 바꿉니다.
- 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를 사용 중지하면 됩니다. 하지만 사용되는 저장용량을 줄여도 인스턴스에 프로비저닝된 저장용량의 크기가 축소되는 것은 아닙니다.
로그는 매일 한 번씩 영구 삭제되며, 지속적으로 진행되지 않습니다. 로그 보관 기간을 2일로 설정하면 최소 2일 동안의 로그 및 최대 3일 동안의 로그가 유지됩니다. 백업 보관 기간은 로그 보관 일수보다 최소 1일 이상으로 설정해야 로그 보관 기간을 지정된 최소 일수 이상으로 유지할 수 있습니다.
트랜잭션 로그 보관 설정
바이너리 로그를 보관할 일수(1~7)를 설정하려면 다음 안내를 따르세요.
gcloud
인스턴스를 수정하여 바이너리 로그를 보관할 일수를 설정합니다.
gcloud sql instances patch instance-name --retained-transaction-log-days days-to-retain
보관할 트랜잭션 로그의 일수입니다. 유효한 범위는 1~7입니다. 지정되지 않은 경우 기본값은 7입니다. point-in-time recovery가 사용 설정된 경우에만 유효합니다. 더 많은 트랜잭션 로그를 보관하려면 더 큰 스토리지 크기가 필요합니다.
REST
아래의 요청 데이터를 사용하기 전에 다음을 바꿉니다.
- days-to-retain: 트랜잭션 로그를 보관할 일수(1~7일)
- project-id: 프로젝트 ID
- instance-id: 인스턴스 ID
HTTP 메서드 및 URL:
PATCH https://www.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id
JSON 요청 본문:
{
"settings":
{
"backupConfiguration":
{
"transactionLogRetentionDays": "days-to-retain"
}
}
}
요청을 보내려면 다음 옵션 중 하나를 펼칩니다.
다음과 유사한 JSON 응답이 표시됩니다.