고가용성 구성 개요

이 페이지에서는 MySQL 2세대 인스턴스에 대한 고가용성 구성을 간략히 설명합니다. HA를 위한 새 인스턴스 또는 기존 인스턴스를 구성하려면 고가용성 인스턴스 구성을 참조하세요.

HA 구성 개요

클러스터라고도 하는 HA 구성은 데이터 중복 기능을 제공합니다. 이 구성은 기본 영역의 기본 인스턴스(마스터)와 보조 영역의 장애 조치 복제본으로 이루어집니다. 기본 인스턴스의 데이터와 사용자 테이블에 대한 모든 변경사항은 일부 동기 복제를 통해 장애 조치 복제본에 복사됩니다. 이렇게 구성하면 인스턴스 또는 영역에 장애가 발생할 경우 다운타임이 감소하고 클라이언트 애플리케이션에서 데이터를 계속 사용할 수 있습니다.

HA 장애 조치 복제본은 별도의 인스턴스로 청구됩니다. 자세한 내용은 가격 페이지를 참조하세요.

MySQL HA 구성의 다이어그램 개요아래에 텍스트로 설명됨

장애 조치 복제본

장애 조치 복제본은 기본 인스턴스와 동일한 데이터베이스 플래그, 사용자(루트 사용자 포함) 및 비밀번호, 승인된 애플리케이션 및 네트워크, 데이터베이스로 구성됩니다.

제한사항

장애 조치 복제본에는 다음과 같은 제한사항이 있습니다.

  • 장애 조치 복제본은 기본 인스턴스와 동일한 리전에 있되, 다른 영역에 있어야 합니다.
  • 각 기본 인스턴스에 대해 장애 조치 복제본을 하나씩만 만들 수 있습니다.
  • 장애 조치 복제본의 활성화 정책 또는 유지보수 기간은 변경할 수 없습니다. 장애 조치 복제본의 유지보수 기간은 기본 인스턴스와 동일합니다.
  • 장애 조치 복제본에서는 백업을 사용 설정할 수 없습니다. 백업은 기본 인스턴스에서 수행해야 합니다.
  • 장애 조치 복제본은 기본 인스턴스에서만 만들 수 있고 읽기 복제본에서는 만들 수 없습니다.

장애 조치 개요

HA가 구성된 인스턴스가 응답하지 않을 경우 Cloud SQL은 장애 조치 복제본에서 데이터를 제공하도록 자동으로 전환됩니다. 이것을 장애 조치라고 합니다. 장애 조치가 발생했는지 확인하려면 작업 로그의 장애 조치 내역을 확인하세요.

장애 조치가 인스턴스에 미치는 영향을 확인하려면 아래의 탭을 클릭하세요.

정상

장애 조치 전 정상 인스턴스의 MySQL 다이어그램

장애 조치

장애 조치 수행 시 인스턴스의 MySQL 다이어그램

결과

장애 조치 후 결과 및 인스턴스의 MySQL 다이어그램

과정

장애 조치 과정은 다음과 같습니다.

  1. 기본 인스턴스에서 장애가 발생합니다.

    기본 인스턴스는 하트비트 신호로 1초마다 시스템 데이터베이스에 쓰기를 수행합니다. 여러 개의 하트비트가 감지되지 않고 장애 조치 복제본이 정상 상태이면 장애 조치가 시작됩니다. 기본 인스턴스가 약 60초 동안 응답하지 않거나 기본 영역에서 중단이 발생하는 경우가 이에 해당합니다.

  2. Cloud SQL은 장애 조치 복제본이 기본 인스턴스의 상태를 반영할 때까지 대기합니다.

    이 단계에 소요되는 시간은 복제 지연의 영향을 받습니다.

  3. 장애 조치 복제본이 기본 인스턴스 역할로 승격됩니다.

    이제 장애 조치 복제본이 보조 영역에서 데이터를 제공하며 기본 인스턴스의 이름과 IP 주소가 이전의 장애 조치 복제본으로 이동합니다. 기본 인스턴스의 IP 주소가 자동으로 이동했으므로 클라이언트 애플리케이션은 연결 문자열을 변경할 필요 없이 새 기본 인스턴스에 다시 연결합니다. 현재 인스턴스가 데이터를 제공하고 있는 소스 영역을 확인하려면 GCP Console의 개요 페이지로 이동합니다.

  4. 장애 조치 복제본이 재생성됩니다.

    새 장애 조치 복제본은 수신되는 장애 조치 복제본 IP 주소를 유지하며 정상 영역에서 자동으로 재생성됩니다.

  5. 읽기 복제본이 재생성됩니다.

    새 읽기 복제본은 수신되는 읽기 복제본 IP 주소를 유지하며 정상 영역에서 자동으로 재생성됩니다.

요구사항

Cloud SQL에서 장애 조치를 허용하기 위해서는 다음과 같은 구성 요구사항을 충족해야 합니다.

  • 복제본이 정상 상태여야 합니다.
  • 기본 인스턴스가 정상 작동 상태(중단되거나 유지관리 작업 중이거나 장기 실행 작업을 수행하고 있지 않음)여야 합니다.
  • 장애 조치 복제본에서 진행 중인 관리 작업이 없어야 합니다. 내보내기 같은 관리 작업의 직후 또는 도중에 장애 조치가 시작되면 장애 조치 요청이 실패합니다.
  • 장애 조치 복제본이 사용 가능해야 합니다. 장애 조치 복제본을 사용할 수 없는 상태에서 장애 조치가 시작되면 장애 조치 요청이 실패합니다. 기본 인스턴스의 상태가 비정상이어서 장애 조치 요청이 발생한 경우에는 기본 인스턴스가 중단됩니다.
  • 복제 지연이 허용 가능한 수준이어야 합니다. 복제 지연 시간이 10분을 초과할 경우 Cloud SQL은 비정상 인스턴스에 대해 장애 조치를 시작하지 않습니다. 사용자가 시작한 장애 조치와 영역 중단으로 인한 장애 조치는 여전히 시도됩니다.

구성 상태

장애 조치 복제본 가용성

장애 조치 복제본 가용성은 다음과 같이 장애 조치 복제본 측정항목이 아니라 기본 인스턴스 측정항목으로 제공됩니다.

cloudsql.googleapis.com/database/available_for_failover

이 상태는 기본 인스턴스의 Get 요청에 대한 응답 중 failoverReplica.available 필드에도 포함됩니다.

Stackdriver를 사용하여 HA 구성 측정항목을 볼 수 있습니다. Stackdriver가 제공하는 Cloud SQL 측정항목의 전체 목록은 Cloud SQL 측정항목 목록을 참조하세요. GCP에서 Stackdriver를 사용하는 방법에 대한 자세한 내용은 Stackdriver 문서를 참조하세요.

복제 지연

개요

기본 인스턴스에 대한 쓰기 작업이 발생할 때마다 일부 동기 복제를 통해 장애 조치 복제본도 동일하게 업데이트되어야 합니다. 변경사항이 손실되지 않도록 하면서 기본 인스턴스의 성능에 미치는 영향을 최소화하기 위해 장애 조치 복제본은 업데이트 이벤트를 로깅한 다음 업데이트를 순서대로 실행합니다. 업데이트 이벤트가 전달되는 속도가 장애 조치 복제본의 업데이트 가능 속도보다 더 빠르면 장애 조치 복제본의 상태가 기본 인스턴스보다 뒤처질 수 있습니다. 기본 인스턴스에서 업데이트가 실행된 이후부터 로그를 통해 장애 조치 복제본에 해당 업데이트가 반영될 때까지의 소요 시간을 복제 지연이라고 합니다.

복제 지연으로 인해 장애 조치 시간이 늘어날 수 있지만 기본 인스턴스가 처리하는 모든 트랜잭션이 장애 조치 복제본의 로그에도 기록되기 때문에 복제 지연으로 인해 데이터가 손실되지는 않습니다.

복제 지연 해결

기본 인스턴스에 대한 쓰기 작업이 급증하여 복제 지연이 발생하는 경우 장애 조치 복제본은 대개 부하가 다시 줄어든 후에 기본 인스턴스를 반영할 수 있습니다. 복제 지연 시간이 길지만 일정 수준으로 유지되는 경우에는 장애 조치 복제본을 삭제한 후 다시 만들면 됩니다. 그러나 쓰기 부하가 지속되며 복제 지연 시간이 계속해서 증가하는 상황이라면 조치를 취해야 합니다. 복제 지연 시간이 너무 길어지면 인스턴스에 SLA가 적용되지 않을 수도 있습니다. 자세히 알아보기

복제본은 대기 중인 쓰기 작업을 순차적으로 수신하므로 단일 스레드 인스턴스와 같이 작동합니다. 때로는 장애 조치 복제본의 RAM 또는 디스크를 늘려 I/O 처리량을 높이는 것으로도 도움이 될 수 있지만, 장애 조치 복제본이 기본 인스턴스보다 계속해서 뒤처지는 경우에는 쓰기 작업을 여러 기본 인스턴스에서 공유하도록 데이터베이스를 샤딩해야 합니다.

측정항목

복제 지연 상태는 다음과 같이 장애 조치 복제본 측정항목으로 제공됩니다.

cloudsql.googleapis.com/database/mysql/replication/seconds_behind_master

이 측정항목의 값은 복제본이 기본 인스턴스보다 뒤처진 시간(초 단위)을 나타냅니다.

이 측정항목에 Stackdriver 알림을 설정하는 방법에 대한 자세한 내용은 복제 지연 알림 만들기를 참조하세요.

백업 및 복원

HA 인스턴스를 구성하더라도 백업은 여전히 필요하며 백업 생성 방식도 이전과 동일하지만 인스턴스 복원 방식은 달라집니다. 백업에서 기본 인스턴스를 복원하거나 기본 인스턴스에서 point-in-time recovery를 수행하려면 먼저 장애 조치 복제본과 읽기 복제본을 모두 삭제해야 합니다. 복원이 완료된 후 장애 조치 복제본과 읽기 복제본을 다시 만들어야 합니다.

애플리케이션 및 인스턴스

비 HA 인스턴스와 HA 인스턴스의 작동 방식에는 차이가 없으므로 애플리케이션을 특정 방식으로 구성할 필요는 없습니다. 장애 조치가 발생하면 해당 인스턴스에 대한 기존 연결이 닫힙니다. 하지만 애플리케이션은 동일한 연결 문자열 또는 IP 주소를 사용하여 다시 연결할 수 있으므로 장애 조치 후 애플리케이션을 업데이트할 필요가 없습니다. 장애 조치 중에 얼마 동안은 애플리케이션이 데이터베이스에 연결할 수 없게 됩니다.

장애 조치 시 애플리케이션에 미치는 영향을 정확히 확인하려면 장애 조치를 수동으로 시작해야 합니다.

다음 단계

이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...

MySQL용 Cloud SQL