Cloud SQL 인스턴스의 유지보수 정보

이 페이지에서는 Cloud SQL 인스턴스에서 유지보수 업데이트를 수행하는 방법과 이러한 업데이트의 시기를 제어하는 방법을 설명합니다. 시작하려면 유지보수 기간 찾기 및 설정을 참조하세요.

개요

관리형 서비스인 Cloud SQL은 기본 하드웨어, 운영체제, 데이터베이스 엔진의 안정성, 성능, 보안, 최신 업데이트 상태를 보장하기 위해 인스턴스를 자동으로 업데이트합니다. 이러한 업데이트 대부분은 Cloud SQL 인스턴스가 실행되는 동안 수행됩니다. 그러나 특정 시스템 업데이트를 수행하려면 짧은 서비스 중단이 필요합니다. 이러한 업데이트를 유지보수라고 합니다.

유지보수는 데이터베이스 엔진을 업데이트하며 경우에 따라 운영체제도 업데이트합니다. 이러한 업데이트에서는 인스턴스를 다시 시작해야 하기 때문에 일부 다운타임이 발생합니다. 유지보수 업데이트를 사용하면 다음과 같은 이점이 있습니다.

• Cloud SQL 기능. 새로운 기능 출시를 위해 데이터베이스 엔진을 업데이트하고 데이터베이스에 새 플러그인을 설치합니다.

• 데이터베이스 버전 업그레이드. MySQL을 개발하는 데이터베이스 소프트웨어 제공업체는 1년에 몇 번 정도 새로운 부 버전을 출시합니다. 새 버전이 출시될 때마다 버그 수정, 보안 패치, 성능 향상, 새로운 데이터베이스 기능이 함께 제공됩니다. 출시 노트 또는 데이터베이스 버전 및 버전 정책을 검토하여 MySQL용 Cloud SQL에서 지원하는 최신 부 버전을 확인할 수 있습니다. Cloud SQL 인스턴스는 출시 후 곧 최신 데이터베이스 버전으로 업그레이드됩니다. 따라서 최신 데이터베이스 소프트웨어를 실행할 수 있는 이점이 있습니다.

  MySQL 8.0 부 버전 업그레이드를 수동으로 수행해야 합니다. 인스턴스의 MySQL 부 버전 설정을 참조하세요.

• 운영체제 패치. Google은 운영체제에서 새로 발견된 보안 취약점을 지속적으로 모니터링합니다. 취약점을 발견하면 새로운 위험으로부터 사용자를 보호하기 위해 운영체제 패치를 출시합니다.

유지보수 영향

Cloud SQL Enterprise Plus 버전의 경우 Cloud SQL은 다운타임이 0에 가까운 계획된 유지보수를 제공합니다.

Cloud SQL은 일반적으로 몇 개월에 한 번씩 유지보수 업데이트 이벤트를 예약합니다. 유지보수 업데이트는 인스턴스당 약 5~10분 정도 걸릴 수 있습니다. 인스턴스에 읽기 복제본이 있으면 전체 유지보수 업데이트 시간이 더 오래 걸릴 수 있습니다. 하지만 유지보수 업데이트 이벤트 중에 각 Cloud SQL Enterprise 버전 인스턴스 연결이 평균 60초 미만으로 끊어집니다. 유지보수 업데이트 이벤트 중에 진행 중인 활동이 많거나 데이터 세트가 매우 큰 인스턴스의 경우에는 다운타임이 더 길 수 있습니다.

유지보수 설정을 사용하고 일시적인 오류에 대해 복원력이 우수한 시스템을 만들어 유지보수가 작업에 미치는 영향을 가능한 한 최소화하는 조치를 취할 수 있습니다.

다운타임이 0에 가까운 계획된 유지보수

다운타임이 0에 가까운 계획된 유지보수를 사용하는 Cloud SQL Enterprise Plus 버전 인스턴스는 일반적으로 계획된 유지보수 중에 연결이 1초 미만으로 끊깁니다.

유지보수 중에 활동량이 많은 인스턴스의 경우 다운타임이 더 길 수 있습니다.

기본 요건 및 제약조건

• 인스턴스에서 바이너리 로깅을 사용 설정해야 합니다.

• 다음 플래그 중 하나를 사용하는 경우 기본값으로 설정해야 합니다.

  • sync_binlog, 값: 1
  • innodb_flush_log_at_trx_commit, 값: 1
  • replica_skip_errors, 값: OFF
  • binlog_order_commit, 값: ON

  자세한 내용은 데이터베이스 플래그 구성을 참조하세요.

• Cloud SQL 인증 프록시 또는 Cloud SQL 언어 커넥터를 사용하는 경우 최신 버전으로 업데이트되었는지 확인합니다.

• GTID가 사용 설정된 외부 복제본이 있는 경우 복제본에서 GTID 기반 자동 배치를 사용하도록 구성해야 합니다. 그렇지 않으면 유지보수 후에 복제가 중단됩니다. 자세한 내용은 GTID 자동 배치를 참고하세요.

• MySQL 서버 UID가 유지보수 중에 변경됩니다.

• 유지보수 중에는 데이터베이스 로그에 서로 다른 두 VM의 메시지가 포함됩니다.
• 계획된 유지보수 중에 DDL이 실행되는 경우 유지보수 타임스탬프 이후의 생성 또는 수정 타임스탬프가 변경사항에 포함될 수 있습니다.

사실상 다운타임이 거의 없는 계획된 유지보수 시뮬레이션

데이터베이스 인스턴스를 업데이트하지 않고 Cloud SQL Enterprise Plus 버전 기본 인스턴스의 계획된 유지보수 다운타임을 테스트하려면 사실상 다운타임이 거의 없는 계획된 유지보수를 시뮬레이션할 수 있습니다.

이렇게 하려면 사실상 다운타임이 거의 없는 계획된 유지보수가 가능한 Cloud SQL Enterprise Plus 버전 인스턴스에서 유지보수 이벤트 시뮬레이션을 호출합니다. 시뮬레이션 요청으로 인해 작업 이전과 동일한 유지보수 버전으로 인스턴스 업데이트 작업이 수행됩니다.

인스턴스에서 대기 중인 유지보수 업데이트가 있는 경우에도 시뮬레이션을 수행할 수 있습니다. 인스턴스 버전은 시뮬레이션 내내 동일하게 유지됩니다.

사실상 다운타임이 거의 없는 계획된 유지보수 이벤트를 시뮬레이션하려면 다음 gcloud CLI 명령어를 사용합니다.

gcloud sql instances patch INSTANCE_NAME --simulate-maintenance-event

INSTANCE_NAME을 시뮬레이션된 유지보수 이벤트를 실행할 인스턴스의 이름으로 바꿉니다.

유지보수 설정

Cloud SQL은 일련의 유지보수 설정을 통해 유지보수 업데이트를 구성할 수 있는 기능을 제공합니다.

짧은 다운타임으로 애플리케이션에 미치는 영향이 가장 적은 시간에 유지보수를 예약하도록 구성할 수 있습니다. 각 Cloud SQL 인스턴스에 대해 다음을 구성할 수 있습니다.

• 유지보수 시점(이전의 업데이트 순서). Cloud SQL 인스턴스를 업데이트하는 출시 기간 주입니다. 다음 중 한 가지 방법을 사용하시기 바랍니다.

  • Any: 유지보수 업데이트가 언제든지 진행될 수 있지만 일반적으로 1주 차 내에 진행됩니다.
  • Week 1: 유지보수 알림이 전송된 지 7~14일 후에 유지보수가 진행됩니다.
  • Week 2: 알림이 전송된 후 15~21일 후에 유지보수 업데이트가 수행됩니다.
  • Week 5: 알림이 전송된 후 35~42일 후에 유지보수 업데이트가 수행됩니다.

  유지보수 기간을 구성할 때 유지보수 업데이트 일정을 설정합니다.

• 유지보수 기간. Cloud SQL에서 유지보수를 예약하는 요일과 시간입니다. 유지보수 기간은 1시간 동안 지속됩니다. 유지보수 기간 구성 방법을 알아보세요.

• 유지보수 거부 기간. Cloud SQL이 유지보수를 예약하지 않는 기간(일 수)입니다. 유지보수 거부 기간은 최대 90일까지 설정할 수 있습니다. 유지보수 거부 기간을 구성하는 방법을 알아보세요.

기본 유지보수 기간

유지보수 기간을 설정하지 않으면 Cloud SQL이 인스턴스의 시간대에 따라 다음 기본 기간으로 인스턴스를 업데이트합니다.

• 평일 기간(월요일~금요일): 오후 10시~오전 6시
• 주말 기간: 금요일 오후 10시~월요일 오전 6시

유지보수 예시

장바구니 서비스를 관리하는 소매업체의 개발자라고 가정해보세요. 프로덕션 환경과 스테이징 환경을 위해 각각 하나의 Cloud SQL 인스턴스가 있습니다. 일요일 자정과 같이 인스턴스가 가장 적은 양의 트래픽을 처리하는 시간에 유지보수를 수행하려고 합니다. 또한 사용량이 많은 연말 연휴 쇼핑 시즌 중에는 유지보수를 건너뛰어야 합니다.

여기에서는 프로덕션 인스턴스 유지보수 설정을 다음과 같이 설정합니다.

• 유지보수 기간: 동부시간 기준 매주 일요일 오전 12시부터 오전 1시까지
• 유지보수 시점: Week 2
• 유지보수 거부 기간: 11월 1일~1월 15일

스테이징 환경의 유지보수 설정은 유지보수 시점이 Week 2로 설정된다는 점을 제외하고 동일합니다. 이렇게 하면 유지보수가 프로덕션에 출시되기 최소 7일 전에 스테이징에서 유지보수 출시에 대해 운영 승인 테스트를 실행할 수 있습니다. 스테이징 환경에서 오류가 발생해도 문제를 진단하고 수정하거나 유지보수 거부 기간을 설정할 시간이 있어 프로덕션 환경이 영향을 받지 않습니다.

예정된 유지보수 알림

유지보수 예정 최소 1주일 전 예정된 유지보수에 대한 알림이 이메일로 전송되도록 설정할 수 있습니다. 알림에 대한 이메일 필터를 설정하기 위해 이메일 제목은 Upcoming maintenance for your Cloud SQL instance instancename(Cloud SQL 인스턴스 instancename의 예정된 유지보수)이 됩니다.

기본적으로 유지보수 알림은 전송되지 않습니다. 유지보수 알림을 수신 동의해야 합니다. 알림을 수신하려면 유지보수 기간도 선택해야 합니다.

알림은 Google 계정과 연결된 이메일 주소로 전송됩니다. 커스텀 이메일 별칭(예: 팀 이메일 별칭)은 구성할 수 없습니다.

지정된 프로젝트에서 유지보수 기간이 있는 모든 Cloud SQL 인스턴스에 대해 유지보수 알림을 수신 동의합니다. 인스턴스당 하나의 알림을 받습니다. 읽기 복제본에 대해서는 예정된 유지보수 알림이 전송되지 않습니다.

또한 Google Cloud 콘솔에서 예정된 유지보수 정보를 확인할 수도 있습니다.

• 인스턴스 목록의 유지보수 열. 유지보수가 예약되면 시작이 예약된 날짜와 시간이 표시됩니다. 유지보수라는 용어로 인스턴스 목록을 필터링하면 유지보수가 예약된 모든 인스턴스를 찾을 수 있습니다. 유지보수 열은 프로젝트의 인스턴스 한 개 이상에 유지보수가 예약된 경우에만 표시됩니다. 예약된 유지보수가 없으면 이 열은 표시되지 않습니다.
• 유지보수 창의 인스턴스 세부정보 페이지. 유지보수가 예약되면 예정 아래에 시작 예약 날짜와 시간이 표시됩니다.

• Google Cloud 콘솔의 활동 페이지에서 유지보수를 위해 예약한 인스턴스 목록을 확인할 수 있습니다. 유지보수가 예약되면 인스턴스에 SQL 유지보수 메시지와 시작 예약 날짜와 시간이 표시됩니다.

유지보수 일정 변경

인스턴스에 대한 유지보수 기간이 있는 경우 유지보수 업데이트가 발생하기 24시간 전까지 유지보수 업데이트 일정을 변경할 수 있습니다. 예를 들어 예약된 유지보수 기간 중에 새 서비스를 출시하는 경우 유지보수 업데이트를 출시 후 며칠 뒤로 연기할 수 있습니다.

유지보수 업데이트 일정 변경에는 몇 가지 제한사항이 있습니다. Cloud SQL에서 알림 이메일을 전송한 후에는 다음 Cloud SQL 유지보수 업데이트와 겹치지 않도록 7주 이내에 유지보수 업데이트를 수행합니다. 예를 들어 1주 차 또는 2주 차를 유지보수 시점으로 선택하면 원래 예약된 날짜로부터 최대 4주(28일)까지 유지보수 업데이트 일정을 변경할 수 있습니다. 인스턴스의 유지보수 시점을 5주 차로 설정하면 원래 날짜로부터 최대 1주일(7일)까지만 유지보수 이벤트 일정을 변경할 수 있습니다. 재예약된 유지보수 이벤트가 인스턴스에 구성한 유지보수 시점에서 정의된 재예약 기간 내에 있는 한 유지보수를 여러 번 재예약할 수 있습니다.

기타 모든 제한사항은 재예약 제한사항을 참조하세요.

새 유지보수 기간에는 다음과 같은 몇 가지 일정 옵션이 있습니다.

• 즉시 업데이트 적용. 예약된 유지보수 기간을 기다리지 않고 인스턴스에 즉시 업데이트를 적용할 수 있습니다. 이 경우 일반적으로 유지보수가 5분 내에 시작합니다.

• 다른 시간으로 일정 변경. 다음 두 가지 방법으로 예약된 유지보수 이벤트를 연기할 수 있습니다.

  • 다음 가용 기간. 현재 예약된 유지보수 시간 이후 다음으로 사용 가능한 유지보수 기간으로(일반적으로 1주일 후) 유지보수를 연기하는 옵션입니다.
  • 특정 시간. 이 옵션을 사용하면 인스턴스에 구성한 유지보수 시기별로 정의된 재예약 기간에 특정 시간을 선택할 수 있습니다.
    • 1주 차 또는 2주 차 유지보수 시기를 선택한 경우 28일
    • 5주 차 유지보수 시기를 선택한 경우 7일

유지보수 일정을 변경하는 방법은 예정된 유지보수 일정 변경을 참조하세요.

유지보수 작동 방법

유지보수를 짧은 시간 내에 마치기 위해 Cloud SQL은 대부분 가용성이 높은 인스턴스를 위한 자동 장애 조치 워크플로와 비슷한 유지보수 장애 조치 워크플로를 사용합니다.

요약하면 다음과 같은 단계를 따릅니다.

1. 새 소프트웨어로 업데이트된 VM을 설정합니다.
2. 기존 VM에서 데이터베이스를 중지합니다.
3. 디스크 및 고정 IP를 업데이트된 VM으로 전환합니다.
4. 업데이트된 VM에서 데이터베이스를 시작합니다.

다음 탭을 통해 유지보수 전과 유지보수 후를 포함하여 워크플로를 자세히 확인하세요.

유지보수 영향 최소화

일반적으로 Google Cloud에서는 클라우드에서 애플리케이션을 실행하는 사용자가 일시적인 사용 불가능 상태로 인해 발생하는 순간적인 서비스 간 통신 문제에 해당하는 일시적인 오류에 대해 복원력이 우수한 시스템을 만들 것을 권장합니다. 가끔 발생하는 일시적인 오류는 클라우드에서 피할 수 없는 것들입니다.

유지보수 기간 동안 발생하는 일부 일시적인 오류에는 연결 끊김 및 실행 중인 트랜잭션 실패 등이 있습니다. 또한 일시적인 오류에 대해 복원력이 우수하도록 시스템을 설계하고 애플리케이션을 조정하면 데이터베이스 유지보수로 인한 영향도 최소화하는 데 유리합니다.

끊긴 연결의 영향을 최소화하기 위해 연결 풀을 사용할 수 있습니다. 유지보수 기간 동안 풀러와 데이터베이스 간 연결이 끊기더라도 애플리케이션과 풀러 사이의 연결이 보존됩니다. 이렇게 하면 연결 재설정 작업이 애플리케이션에 대해 투명하게 수행되고 대신 연결 풀러로 오프로드됩니다.

트랜잭션 오류를 줄이기 위해서는 장기 실행 트랜잭션 수를 제한할 수 있습니다. 쿼리를 더 작고 더 효율적으로 다시 작성하면 유지보수 다운타임이 줄어들 뿐만 아니라 데이터베이스 성능과 안정성도 향상됩니다.

연결 중단 및 트랜잭션 오류를 효율적으로 복구하려면 데이터베이스 연결을 효율적으로 관리하면 됩니다. 애플리케이션 및 연결 풀러에 지수 백오프를 사용하여 연결을 설정하고 재시도 로직을 쿼리할 수 있습니다. 쿼리가 실패하거나 연결이 끊어지면 시스템은 재시도하기 전에 대기 기간을 설정하며, 이후 재시도할 때마다 대기 시간이 늘어납니다. 예를 들어 첫 번째 재시도는 몇 초 정도 걸릴 수 있지만 네 번째 재시도는 최대 1분이 걸릴 수 있습니다. 이 패턴을 따르면 서비스에 과부하가 발생하지 않으면서 이러한 오류를 수정할 수 있습니다.

또한 유지보수 이후 데이터베이스 캐시 워밍을 위한 스크립트 사용부터 데이터베이스의 테이블 수 간소화까지 다른 창의적인 솔루션을 통해 유지보수 영향을 최소화할 수도 있습니다. 유지보수가 원활하게 진행될 수 있도록 다음과 같은 데이터베이스 관리 권장사항 및 운영 가이드라인을 따를 것을 권장합니다.

시간에 민감한 유지보수

매우 드문 경우지만 Cloud SQL에서 심각한 안정성 문제 또는 시간에 민감한 취약점 문제를 패치하기 위해 유지보수 설정을 벗어나서 유지보수를 예약해야 할 수 있습니다. 이러한 업데이트는 신속하게 제공되며 Cloud SQL은 이를 SLA에 대한 다운타임으로 계산합니다.

셀프서비스 유지보수

Cloud SQL은 인스턴스에 설치할 수 있는 새로운 유지보수 버전을 통해 소프트웨어 개선 및 보안 취약점 패치를 정기적으로 출시합니다. Cloud SQL은 각 데이터베이스 엔진 주 버전에 대해 Cloud SQL 유지보수 변경 로그를 유지합니다. 자세한 내용은 Cloud SQL 유지보수 변경 로그를 참조하세요.

Cloud SQL은 최신 소프트웨어를 사용하도록 몇 개월에 한 번씩 유지보수 업데이트를 예약하지만 다음과 같은 경우에는 셀프서비스 유지보수를 사용하여 인스턴스를 업데이트할 수 있습니다.

• 다음에 예약된 유지보수 이벤트보다 빨리 업데이트해야 합니다.
• 최신 유지보수 업데이트를 건너뛴 후 최신 소프트웨어를 가져오려고 합니다.

읽기 복제본을 사용하는 경우 셀프서비스 유지보수를 사용하여 모든 읽기 복제본을 업데이트할 수 있습니다. 기본 인스턴스를 지정하면 유지보수 요청에서 기본 인스턴스의 모든 읽기 복제본을 지정된 유지보수 버전으로 업데이트합니다. 그러면 기본 인스턴스가 유지보수 버전으로 업데이트됩니다.

유지보수 제한사항

이 섹션에서는 Cloud SQL 유지보수의 제한사항을 설명합니다.

재예약 제한사항

재예약 방법에 대해 알아야 할 몇 가지 사항이 있습니다.

• 원래 예약된 유지보수 이벤트가 발생하기 최소 24시간 전에 유지보수 일정을 변경해야 합니다.

• 프로젝트의 인스턴스 한 개 또는 여러 개에서 유지보수 일정을 변경할 수 있습니다. 그러나 한 번에 인스턴스 하나만 일정을 변경할 수 있습니다(일괄 재예약을 사용할 수 없음).

• 재예약 기간이 인스턴스에 구성한 유지보수 시점으로 정의된 기간 내에 있는 한 유지보수 거부 기간 내에 있거나 유지보수 기간 밖에 있는 시간으로 유지보수 일정을 변경할 수 있습니다.

• 유지보수 작업이 진행 중인 경우 작업이 완료될 때까지 재예약이 지연됩니다.

유지보수 거부 기간 제한사항

유지보수 거부 기간에 대해 알아야 할 몇 가지 사항이 있습니다.

• 인스턴스에 유지보수 기간이 구성되지 않은 경우에도 유지보수 거부 기간을 가질 수 있습니다. 유지보수 거부 기간은 1~90일입니다.

• 유지보수 거부 기간이 예약된 유지보수 기간보다 우선 적용됩니다. 유지보수 기간과 유지보수 거부 기간 사이에 충돌이 있으면 유지보수 거부 기간이 유지보수 기간보다 우선 적용됩니다.

• 유지보수 거부 기간과 유지보수 시기는 독립적인 기능입니다. 유지보수 시점이 Week 1인 인스턴스의 유지보수 거부 기간을 만들어도 유지보수 시점이 Week 2인 인스턴스의 예약된 업데이트를 결정하는 데는 영향을 미치지 않습니다. 예약된 유지보수 업데이트가 유지보수 거부 기간 내에 있으면 Cloud SQL이 유지보수 시점으로 구성한 인스턴스에 대한 알림을 전송하지 않습니다.

• 기본 인스턴스에 거부 기간이 설정되면 기본 인스턴스와 연결된 모든 복제본의 유지보수도 거부됩니다. 예를 들어 리전 A에 있는 기본 인스턴스에는 리전 A에 2개와 리전 B에 1개 등 3개의 읽기 복제본이 있습니다. 기본 인스턴스에 거부 기간이 설정된 경우 기본 인스턴스의 거부 기간이 만료될 때까지 리전 B의 복제본을 포함한 각 복제본의 유지보수는 진행되지 않습니다.

• 유지보수 거부 기간이 예약된 유지보수 시간과 겹치는 등과 같이 유지보수가 계획된 후에 유지보수 거부 기간이 설정되면 업데이트를 건너뜁니다.

• 시작 및 종료일 매개변수에 연도를 포함하지 않음으로써 매년 반복되도록 유지보수 거부 기간을 설정할 수 있습니다. 연도가 지정된 경우 해당 연도에만 유지보수 거부 기간이 설정됩니다.

• 1년에 여러 유지보수 거부 기간을 설정할 수 있습니다. 연속 예약 유지보수 이벤트를 건너뛰려면 여러 거부 기간을 연결하지 않는 것이 좋습니다. 인스턴스가 안정적으로 작동하도록 하려면 Cloud SQL 유지보수를 최신 상태로 유지하는 것이 중요합니다. 일반적으로 Cloud SQL 유지보수는 몇 달에 한 번으로 예약됩니다.

• 서비스 안정성을 보장하기 위해 Cloud SQL은 12개월이 지난 유지보수 출시 버전이 실행 중인 인스턴스를 사용하는 사용자에게 다음 유지보수 출시가 필요함을 알릴 수 있습니다.

• 유지보수 거부 기간이 종료되면 정기 유지보수 동작이 다시 시작합니다.

• 유지보수 거부 기간은 셀프서비스 유지보수와 같은 사용자가 트리거한 작업에 영향을 주지 않습니다.

유지보수 FAQ

• 유지보수는 기존 HA 장애 조치 인스턴스에 어떤 영향을 주나요?
• 유지보수 다운타임이 SLA에 포함되나요?
• 유지보수는 읽기 복제본에 어떤 영향을 주나요?
• 예약된 유지보수를 취소할 수 있나요?
• 유지보수 이벤트가 취소되면 어떻게 되나요?
• Cloud SQL 유지보수는 누적되나요?
• 예약된 유지보수 업데이트 중에 인스턴스가 중지되면 어떻게 되나요?
• 기본 인스턴스의 모든 읽기 복제본에서 셀프서비스 유지보수 시간은 얼마나 걸리나요?
• 기본 인스턴스에 읽기 복제본이 여러 개 있는 경우 단일 읽기 복제본에 대해 셀프서비스 유지보수를 수행할 수 있나요?

유지보수는 기존 HA 장애 조치 인스턴스에 어떤 영향을 주나요?

기존 HA 장애 조치 인스턴스는 유지보수 업데이트를 위해 중지됩니다. 이 인스턴스는 기본 인스턴스 직전에 유지보수 업데이트를 수신합니다. 기존 HA 장애 조치 인스턴스는 기본 인스턴스의 유지보수 기간을 공유하므로 기존 HA 장애 조치 인스턴스에 유지보수 기간을 직접 설정할 수 없습니다.

유지보수 다운타임이 SLA에 포함되나요?

일반적인 유지보수로 인한 다운타임은 SLA에 포함되지 않습니다. 하지만 Cloud SQL에서 시간에 민감한 유지보수 다운타임은 SLA에 포함됩니다.

유지보수는 읽기 복제본에 어떤 영향을 주나요?

• Cloud SQL은 항상 기본 인스턴스 전에 읽기 복제본을 유지합니다. 기본 인스턴스에 유지보수 기간이 있으면 읽기 복제본은 동일한 유지보수 기간을 준수합니다.
• 기본 인스턴스에 읽기 복제본이 여러 개 있는 경우 Cloud SQL은 일부 복제본을 동시에 업데이트할 수 있습니다.
• 읽기 복제본도 기본 인스턴스에 설정된 유지보수 거부 기간을 준수합니다.

예약된 유지보수를 취소할 수 있나요?

예약된 유지보수 기간을 취소할 수는 없지만 재예약할 수 있습니다. 또한 예약된 유지보수 시간과 겹치는 유지보수 거부 기간을 구성하여 유지보수를 효과적으로 건너뛸 수도 있습니다.

유지보수 이벤트가 취소되면 어떻게 되나요?

Cloud SQL이 유지보수 이벤트를 취소하면 가능한 경우 유지보수가 취소되었다는 알림이 미리 수신됩니다.

유지보수 이벤트가 재예약되면 예정된 유지보수 알림을 새로 받게 됩니다.

Cloud SQL 유지보수는 누적되나요?

유지보수 업데이트는 누적됩니다. 누락했을 수 있는 유지보수 업데이트를 각각 적용할 필요가 없습니다. 최신 유지보수 버전은 다음 예약 유지보수 업데이트에 적용됩니다. 또는 셀프서비스 유지보수를 통해 최신 유지보수 업데이트를 적용할 수 있습니다.

예약된 유지보수 업데이트 중에 인스턴스가 중지되면 어떻게 되나요?

예약된 유지보수 업데이트 중에 인스턴스가 중지되면 Cloud SQL은 유지보수 업데이트를 건너뜁니다. 하지만 다음에 인스턴스를 다시 시작하면 Cloud SQL에서 인스턴스를 최신 유지보수 업데이트로 자동 업데이트합니다.

기본 인스턴스의 모든 읽기 복제본에서 셀프서비스 유지보수 시간은 얼마나 걸리나요?

셀프서비스 유지보수 업데이트에 걸리는 시간은 기본 인스턴스의 총 읽기 복제본 수에 따라 다릅니다. 셀프서비스 유지보수 업데이트에 걸리는 시간을 줄이기 위해서는 읽기 복제본 몇 개를 개별적으로 업데이트한 다음 기본 인스턴스에서 업데이트를 수행하여 나머지 읽기 복제본을 업데이트하면 됩니다.

두 번째 업데이트는 이미 대상 유지보수 버전이 있는 복제본을 건너뜁니다.

기본 인스턴스에 읽기 복제본이 여러 개 있는 경우 단일 읽기 복제본에 대해 셀프서비스 유지보수를 수행할 수 있나요?

예. 개별 읽기 복제본 인스턴스에서 셀프서비스 유지보수를 수행할 수 있습니다. 하지만 나머지 읽기 복제본과 기본 인스턴스를 빠른 시일 내에 동일한 유지보수 버전으로 업데이트하는 것이 좋습니다. 모든 읽기 복제본과 기본 인스턴스를 동일한 유지보수 버전으로 운영하는 것이 좋습니다.

다음 단계

• 유지보수 알림 수신 동의 방법을 참조하세요.
• 유지보수 기간 설정 방법을 참조하세요.
• 유지보수 알림을 보는 방법을 참조하세요.