Cloud SQL을 사용하면 백업에서 또는 PITR (point-in-time recovery)을 수행하여 인스턴스를 복원할 수 있습니다. 이렇게 하면 기존 인스턴스로 백업을 복원하거나 새 인스턴스로 백업을 복원하여 인스턴스를 특정 기간 또는 시간으로 복구할 수 있습니다. 복원하려면 활성 상태이거나 삭제된 인스턴스의 백업을 사용하면 됩니다. 복원 작업은 소스 인스턴스의 설정, 데이터베이스, 사용자를 가져와 선택한 대상 인스턴스에 설정합니다.
새 인스턴스로 복원할 때 대상 인스턴스는 소스 인스턴스와 다른 리전 또는 프로젝트에 있을 수 있습니다. 대상 인스턴스는 소스 인스턴스와 다른 코어 수 또는 메모리 양을 사용할 수도 있습니다.
Cloud SQL은 항상 대상 인스턴스의 스토리지 용량을 구성된 디스크와 백업 디스크 모두의 최대 크기 값으로 설정합니다. 백업 디스크는 백업이 작성될 때의 디스크 크기입니다.
인스턴스를 복원할 때는 다음 사항을 고려하세요.
- 복원 작업은 대상 인스턴스의 모든 데이터를 덮어씁니다.
- 소스 인스턴스의 플래그는 복원되지 않습니다. 이전에 타겟 인스턴스에 설정된 플래그는 복원 후에도 유지됩니다.
- 복원 작업 중에는 대상 인스턴스에 연결할 수 없으며 기존 연결은 끊어집니다.
- 읽기 복제본이 있는 인스턴스로 복원하는 경우 복원 작업이 완료된 후 모든 복제본을 삭제하고 다시 만들어야 합니다.
- 복원 작업은 인스턴스를 다시 시작합니다.
- 백업에서 복원한 후 대상 인스턴스의 백업 구성이 기본값으로 설정됩니다. 소스 인스턴스에 맞춤 백업 구성이 있거나 고급 백업을 사용한 경우 복원이 완료된 후 백업 구성을 업데이트해야 합니다.
백업을 사용하여 복원
Cloud SQL을 사용하면 백업을 사용하여 인스턴스를 복원할 수 있습니다. 활성 또는 삭제된 인스턴스의 백업을 사용하여 새 인스턴스 또는 기존 인스턴스로 복원할 수 있습니다. 사용 가능한 백업을 사용하여 인스턴스를 복원할 수 있습니다. Cloud SQL에서 백업이 작동하는 방식에 대해 자세히 알아보려면 백업 개요를 참고하세요.
백업을 사용하여 인스턴스를 복원할 때 다음 작업을 할 수 있습니다.
- 새 인스턴스로 복원
- 기존 인스턴스로 복원
- 다른 프로젝트 또는 리전의 인스턴스로 복원
서비스 중단 시에도 특정 프로젝트의 백업 목록을 검색하여 복원할 수 있습니다.
백업을 사용하여 인스턴스를 복원하려면 백업을 사용하여 인스턴스 복원을 참고하세요.
PITR(point-in-time recovery)
PITR을 사용하면 인스턴스를 데이터베이스의 특정 시점으로 복원할 수 있습니다. 예를 들어 오류로 데이터가 손실된 경우 오류가 발생하기 전의 시점으로 데이터베이스를 복구할 수 있습니다. 백업을 사용하여 복원하는 것과 달리 PITR은 항상 새 인스턴스를 만듭니다. 기존 인스턴스에서 PITR을 수행할 수 없습니다. 새 인스턴스는 클론을 생성할 때와 마찬가지로 소스 인스턴스의 설정을 상속합니다.
Cloud SQL Enterprise Plus 버전 인스턴스를 만들면 기본적으로 PITR이 사용 설정됩니다. 수동으로 이 기능을 사용 중지해야 합니다.
Google Cloud 콘솔에서 Cloud SQL Enterprise 버전 인스턴스를 만들면 기본적으로 PITR이 사용 설정됩니다. 그렇지 않고 gcloud CLI, Terraform 또는 Cloud SQL Admin API를 사용하여 인스턴스를 만들면 기본적으로 PITR이 사용 중지됩니다. 이러한 인스턴스에 PITR을 사용 설정하려면 수동으로 사용 설정해야 합니다.
PITR 수행에 대한 단계별 안내는 PITR (point-in-time recovery) 사용을 참고하세요.
PITR의 로그 스토리지
PITR은 로그를 보관처리하는 데 사용됩니다. 백업을 사용하여 기존 인스턴스를 복원하면 이러한 보관 로그가 삭제되고 PITR을 실행할 수 없습니다. 복원이 완료된 후에 생성된 새 로그만 PITR에 사용할 수 있습니다.
2024년 5월 31일 PITR의 트랜잭션 로그 저장 기능이 Cloud Storage에 출시되었습니다. 이 출시 이후에는 다음 조건이 적용됩니다.
모든 Cloud SQL Enterprise Plus 버전 인스턴스는 PITR에 사용되는 트랜잭션 로그를 Cloud Storage에 저장합니다. 2024년 4월 1일 이전에 Cloud SQL Enterprise 버전에서 업그레이드하고 2024년 5월 31일 이전에 PITR을 사용 설정한 Cloud SQL Enterprise Plus 버전 인스턴스만 PITR에 대한 해당 로그를 디스크에 계속 저장합니다.
2024년 5월 31일 이전에 PITR이 사용 설정된 Cloud SQL Enterprise 버전 인스턴스는 PITR에 대한 해당 로그를 계속 디스크에 저장합니다.
2024년 5월 31일 이후에 디스크에 PITR의 트랜잭션 로그를 저장하는 Cloud SQL Enterprise 버전 인스턴스를 Cloud SQL Enterprise Plus 버전으로 업그레이드하는 경우 업그레이드 프로세스는 PITR에 사용되는 트랜잭션 로그의 스토리지 위치를 Cloud Storage로 전환합니다. 자세한 내용은 인플레이스 업그레이드를 사용하여 인스턴스를 Cloud SQL Enterprise Plus 버전으로 업그레이드를 참조하세요.
2024년 5월 31일 이후에 PITR을 사용 설정하여 만드는 모든 Cloud SQL Enterprise 버전 인스턴스는 Cloud Storage에서 PITR에 사용된 로그를 저장합니다.
인스턴스에서 Cloud Storage를 사용하여 트랜잭션 로그를 저장하는 경우 로그가 기본 인스턴스와 동일한 리전에 저장됩니다. 이러한 로그는 Cloud SQL Enterprise Plus 버전의 경우 최대 35일, Cloud SQL Enterprise 버전의 경우 7일 동안 저장되며 인스턴스당 추가 비용이 발생하지 않습니다.
PITR에 사용되는 트랜잭션 로그의 스토리지 위치를 확인하는 방법에 대한 자세한 내용은 인스턴스의 트랜잭션 로그가 저장된 위치 확인을 참고하세요.
트랜잭션 로그를 디스크에만 저장하는 인스턴스의 경우 gcloud CLI 또는 Cloud SQL Admin API를 사용하여 PITR에 사용되는 트랜잭션 로그의 스토리지 위치를 디스크에서 Cloud Storage로 전환할 수 있습니다. 자세한 내용은 트랜잭션 로그 스토리지를 Cloud Storage로 전환을 참조하세요.
인스턴스에 대한 로그가 디스크 대신 Cloud Storage에 저장되도록 하려면 다음 작업을 완료합니다.
- 인스턴스의 네트워크 아키텍처를 확인합니다. 인스턴스가 이전 네트워크 아키텍처에 있는 경우 새 네트워크 아키텍처로 업그레이드합니다.
디스크의 로그 크기로 인해 인스턴스에 성능 문제가 발생하면 PITR을 비활성화하고 다시 사용 설정합니다. 이 작업을 수행하면 새 로그가 디스크 대신 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으로 구성하지 않는 것이 좋습니다. 자세한 내용은 데이터베이스 플래그 구성을 참고하세요.
transactionLogRetentionDays구성 설정expire_logs_days데이터베이스 플래그binlog_expire_logs_seconds데이터베이스 플래그
예를 들어 성능 문제를 방지하려면 며칠에 걸쳐 매일 플래그 값을 하루씩 줄입니다. 따라서 Cloud SQL은 모든 트랜잭션 로그를 동시에 삭제하지 않습니다.
고객 관리 암호화 키 (CMEK) 사용 설정 인스턴스의 경우 트랜잭션 로그는 최신 버전의 CMEK를 사용하여 암호화됩니다. 복원을 수행하려면 retained-transaction-log-days 매개변수의 일부로 보관된 모든 날짜에 최신 키 버전이 필요합니다.
PITR 제한사항
인스턴스에 PITR이 사용 설정되어 있고 디스크의 트랜잭션 로그 크기로 인해 인스턴스에 문제가 발생한다면 다음과 같은 제한사항이 있기 때문입니다.
- PITR을 비활성화하고 다시 사용 설정하면 Cloud SQL이 인스턴스와 동일한 리전의 Cloud Storage에 로그를 저장하도록 할 수 있습니다. 그러나 Cloud SQL에서는 기존 로그를 삭제하므로 PITR을 다시 사용 설정한 시간 이전에는 PITR 작업을 수행할 수 없습니다.
- 인스턴스 스토리지 크기를 늘리면 됩니다. 하지만 트랜잭션 로그 크기에 따른 디스크 사용량 증가가 일시적인 것일 수도 있습니다.
- 예기치 않은 스토리지 문제가 발생하지 않도록 스토리지 용량 자동 증가를 사용 설정하는 것이 좋습니다. 이 권장사항은 인스턴스에 PITR이 사용 설정되어 있고 로그가 디스크에 저장된 경우에만 적용됩니다.
데이터베이스 스냅샷
PITR이 사용 설정된 인스턴스 내의 데이터베이스에서는 SQL Server 데이터베이스 스냅샷을 사용할 수 없습니다.
데이터베이스 스냅샷은 PITR에서 사용하는 전체 데이터베이스 백업 및 트랜잭션 로그 백업을 방해할 수 있습니다. 이러한 간섭으로 인해 인스턴스의 모든 데이터베이스에 대해 PITR 작업이 성공적으로 실행되지 않을 수 있습니다.
PITR의 데이터베이스 복구 모델
인스턴스에서 PITR을 사용 설정하면 Cloud SQL에서 자동으로 기존 및 후속 데이터베이스의 복구 모델을 전체 복구 모델로 설정합니다.
SQL Server 복구 모델에 대한 자세한 내용은 Microsoft 문서를 참조하세요.
PITR 수행에 대한 단계별 안내는 [PITR (point-in-time recovery) 사용][perform-pitr]을 참고하세요.
PITR을 사용하여 삭제된 인스턴스 복원
PITR을 사용하여 삭제된 후 Cloud SQL 인스턴스를 복원할 수 있습니다. 이 기능을 사용하려면 인스턴스를 삭제하기 전에 인스턴스에서 PITR 및 보관된 백업이 사용 설정되어 있어야 합니다. 사용 설정하면 인스턴스를 삭제한 후에도 PITR 로그가 보관됩니다.
인스턴스가 삭제된 후에도 PITR 로그는 인스턴스가 활성 상태일 때 정의된 보관 설정을 계속 따릅니다. PITR 로그는 인스턴스가 삭제된 후 보관 설정에 따라 순차적으로 만료됩니다. 연속 기간은 삭제 전 인스턴스에 설정된 PITR 보관 기간에 따라 정의됩니다. 예를 들어 Cloud SQL Enterprise Plus 버전 인스턴스의 PITR 보관 기간이 14일로 설정된 경우 인스턴스 삭제 후 14일이 지나면 최신 PITR 로그가 삭제됩니다. PITR 로그가 만료되면 복구할 수 없습니다.
Cloud SQL에서 인스턴스를 삭제한 후에도 인스턴스 이름을 재사용할 수 있으므로 보관된 PITR 로그는 Google Cloud 에서 다음 필드를 사용하여 식별할 수 있습니다.
instance_deletion_timelog_retention_days
이러한 필드를 사용하면 PITR 로그가 삭제된 인스턴스에 속하는지 식별할 수 있습니다.
PITR 복구 기간은 PITR을 사용하여 인스턴스를 복원할 수 있는 가장 이른 복구 시간과 가장 늦은 복구 시간으로 정의됩니다. 삭제된 인스턴스의 가장 빠른 복구 시간과 가장 늦은 복구 시간을 확인하려면 가장 빠른 복구 시간과 가장 늦은 복구 시간 가져오기를 참고하세요.
인스턴스 삭제 후 PITR을 사용하여 인스턴스를 복원하려면 삭제된 인스턴스에서 PITR 수행을 참고하세요.
새 인스턴스로 복원하기 위한 요구사항
인스턴스를 새 인스턴스로 복원할 때는 다음 요구사항에 유의하세요.
대상 인스턴스의 데이터베이스 버전은 백업이 실행된 인스턴스의 버전과 같아야 합니다.
대상 인스턴스의 스토리지 용량은 최소한 백업되는 인스턴스의 용량 이상이어야 합니다. 사용되는 스토리지의 크기는 중요하지 않습니다. 콘솔의 Cloud SQL 인스턴스 페이지에서 인스턴스의 스토리지 용량을 확인할 수 있습니다. 이 요구사항은 단일 데이터베이스 PITR을 수행하는지 여부에 적용됩니다.
대상 인스턴스는
RUNNABLE상태여야 합니다.
복원 비율 제한
프로젝트마다 리전별로 인스턴스당 30분 간격으로 복원 작업이 최대 3개까지 허용됩니다. 복원 작업이 실패하면 이 할당량에 포함되지 않습니다. 이 한도에 도달하면 작업이 실패하고 작업을 다시 실행할 수 있는 시기를 알려주는 오류 메시지가 표시됩니다.
Cloud SQL에서는 버킷의 토큰을 사용하여 한 번에 사용할 수 있는 복원 작업 수를 결정합니다. 백업마다 각 타겟 프로젝트와 타겟 리전에 대한 버킷이 있습니다. 동일한 프로젝트의 타겟 인스턴스가 같은 리전에 있으면 버킷 하나를 공유합니다. 버킷마다 복원 작업에 사용할 수 있는 토큰이 최대 3개 있습니다. 10분마다 새 토큰이 버킷에 추가됩니다. 버킷이 가득 차면 토큰이 오버플로됩니다.
복원 작업을 실행할 때마다 버킷에서 토큰이 부여됩니다. 작업이 성공하면 토큰이 버킷에서 삭제됩니다. 실패하면 토큰은 버킷으로 반환됩니다. 다음 다이어그램에서는 작동 방식을 보여줍니다.
예를 들어 다음 그림에서 Backup1, Backup2, Backup3은 동일한 소스 인스턴스의 백업입니다.
- 각 백업(Backup1, Backup2, Backup3)에는 리전 A의 프로젝트 1에 있는 여러 인스턴스(Bucket11A, Bucket21A, Bucket31A)를 타겟팅하는 복원 작업에 사용되는 자체 토큰 버킷이 있습니다. 각 백업에는 자체 버킷이 있으므로 30분마다 3회씩 각 백업을 동일한 인스턴스로 복원할 수 있습니다.
- 백업마다 별도의 프로젝트와 별도의 리전에 사용되는 버킷이 있습니다.
예를 들어 리전 하나에 프로젝트가 5개 있는 경우 해당 리전에는 프로젝트마다 백업 하나에 사용되는 버킷 5개가 있습니다. 앞의 그림에는 리전 A에 프로젝트 1과 프로젝트 n이라는 프로젝트 두 개가 있습니다.
- Backup1에는 리전 A의 복원 작업에 사용되는 토큰 버킷이 두 개 있습니다. 프로젝트 1(Bucket11A)에 버킷 하나, 프로젝트 n(Bucket1nA)에 버킷 하나가 있습니다.
- 마찬가지로 Backup3에는 리전 A의 복원 작업에 사용되는 버킷이 두 개 있습니다. 프로젝트 1(Bucket31A)에 하나, 프로젝트 n(Bucket3nA)에 하나가 있습니다.
- 동일한 타겟 프로젝트와 동일한 타겟 리전의 모든 인스턴스에서 버킷 하나를 공유하므로 Backup3에는 리전 B의 Project1에 사용되는 버킷이 하나 있습니다.