point-in-time recovery

개요

Cloud Spanner point-in-time recovery(PITR)는 실수로 삭제되거나 삭제되는 것을 방지합니다. 예를 들어 운영자가 실수로 데이터를 쓰거나 애플리케이션 출시로 인해 데이터베이스가 손상될 경우, PITR을 사용하면 최대 7일 이내의 과거 시점으로 데이터를 원활하게 복구할 수 있습니다. 데이터를 장기간 보존해야 하는 경우 백업 및 복원 또는 내보내기 및 가져오기를 사용할 수 있습니다.

PITR은 데이터베이스의 모든 버전을 최소 1시간에서 최대 7일까지 보관하도록 데이터베이스의 version_retention_period를 구성하여 사용할 수 있습니다. Cloud Spanner는 이전 버전의 데이터를 마이크로초 단위로 저장하고 데이터베이스에서 이전 버전의 데이터를 복구할 수 있는 가장 이른 시간을 나타내는 earliest_version_time을 유지합니다.

데이터 복구 방법

데이터를 복구하는 방법에는 두 가지가 있습니다.

  • 데이터베이스 일부를 복구하려면 이전에 쿼리 조건 및 타임스탬프를 지정하여 비활성 읽기를 수행한 후 결과를 실시간 데이터베이스에 다시 작성합니다. 이는 일반적으로 실시간 데이터베이스의 수술 작업에 사용됩니다. 예를 들어 특정 행을 실수로 삭제하거나 데이터의 하위 집합을 잘못 업데이트한 경우 이 방법으로 복구할 수 있습니다. 자세한 내용은 데이터베이스 일부 복구를 참조하세요.

  • 전체 데이터베이스를 복구하려면 과거의 타임스탬프를 지정하여 데이터베이스를 백업하거나 내보내기한 다음 복원하거나 새 데이터베이스로 가져옵니다. 이는 일반적으로 손상이 발생하기 전에 전체 데이터베이스를 특정 시점으로 되돌려야 하는 경우 데이터 손상 문제를 복구하는 데 사용됩니다. 데이터베이스 백업 또는 내보내기에 몇 시간이 소요될 수 있으며 기존 데이터베이스로 복원하거나 가져올 수 없습니다. 자세한 내용은 전체 데이터베이스 복구를 참조하세요.

성능에 대한 고려사항

보관 기간이 긴 데이터베이스, 특히 데이터를 자주 덮어쓰는 데이터베이스는 더 많은 시스템 리소스를 사용합니다. 특히 인스턴스에 충분한 노드가 프로비저닝되지 않은 경우 데이터베이스 성능에 영향을 미칠 수 있습니다. 데이터베이스의 덮어쓰기 비율이 매우 높은 경우(예: 데이터베이스를 하루에 여러 번 덮어쓰는 경우) 보관 기간을 점진적으로 늘리고 시스템을 모니터링하는 것이 좋습니다. 다음은 몇 가지 주의해야 할 사항입니다.

  • 스토리지 사용량 증가. 노드당 2TB의 제한을 초과하지 않도록 스토리지 알림을 설정하는 것이 좋습니다. 보관 기간을 늘리면 데이터베이스에서 이전 버전의 데이터가 누적되므로 스토리지 사용량이 점진적으로 증가한다는 것에 유의합니다. 이전 보관 기간에 만료되었을 이전 데이터가 더 이상 만료되지 않기 때문입니다. 따라서 예를 들어 보관 기간을 3일에서 7일로 늘리면 데이터베이스 스토리지 사용량이 안정화될 때까지 4일을 기다려야 합니다. 스토리지 사용량을 추정하는 방법도 안내합니다.

  • CPU 사용량 및 지연 시간 증가. Cloud Spanner는 추가 컴퓨팅 리소스를 사용하여 이전 버전의 데이터를 압축하고 유지합니다. 인스턴스 및 데이터베이스를 모니터링하여 지연 시간과 CPU 사용률이 허용 가능한 수준으로 유지되도록 합니다.

  • 스키마 업데이트 수행 시간 단축 보관 기간이 길어지면 서버 리소스를 기다리는 동안 스키마 업데이트가 throttled 상태가 될 수 있도록 스키마 버전을 더 오래 유지해야 합니다. 스키마 업데이트 권장사항을 따르고 스키마 업데이트 한도를 따라야 합니다.