Compute Engine에서 MySQL 구성

Compute Engine은 MySQL 데이터베이스에서 데이터를 읽고 쓰는 데 사용할 수 있는 다양한 인스턴스 유형과 스토리지 옵션을 제공합니다. 최적의 데이터베이스 워크로드 성능과 비용을 달성하려면 최신 세대 Infrastructure as a Service(IaaS) 제품에서 실행하는 것이 좋습니다.

다음 구성 권장사항은 MySQL 워크로드가 온라인 트랜잭션 처리(OLTP) 또는 일반적인 웹 애플리케이션을 지원하는 데이터베이스와 같은 읽기 중심 시스템에서 자주 사용된다는 점을 고려합니다. 또한 MySQL 8.0 이상 버전 사용, InnoDB 스토리지 엔진 사용과 같은 일반적인 구성 선택사항도 고려합니다. 성능에 민감한 워크로드의 경우 구성을 적절히 조정해야 할 수 있습니다. 이 가이드를 배포의 시작점으로 사용한 다음 실제 워크로드로 테스트하여 구성이 요구사항을 충족하는지 확인하는 것이 좋습니다.

가상 머신(VM) 선택

MySQL 워크로드의 경우 대부분의 실제 MySQL 구성에 적합한 형태가 포함된 최신 세대의 C 및 N 머신 계열을 사용하는 것이 좋습니다. 이러한 머신 시리즈에 대한 소개는 다음 Google Cloud 블로그 게시물을 참고하세요. 이러한 머신 계열은 Titanium을 사용하며 최신 세대의 Intel, AMD, Axion 프로세서를 기반으로 합니다.

성능에 집중

비즈니스에 중요한 MySQL 데이터베이스와 같이 성능에 민감한 워크로드의 경우 리전에서 지원되는 경우에 한해 최신 C4 및 C4A 인스턴스를 사용하는 것이 좋습니다. 이러한 인스턴스에 액세스할 수 없는 경우 유사한 성능 중심 기능을 제공하는 C3 및 C3D 인스턴스에 액세스합니다.

이러한 인스턴스는 컴퓨팅 성능의 제약을 받는 작업에 가장 낮고 일관된 지연 시간을 제공하며 성능 중심 워크로드에 유용한 다음과 같은 기능을 포함합니다.

  • 사전 알림을 통한 호스트 유지보수 이벤트 제어
  • 성능 일관성을 높이기 위한 싱글 코어 터보 부스팅 제어
  • 높은 네트워크 대역폭을 위한 Tier_1 네트워킹

C4A, C3 또는 C3D 인스턴스를 사용하는 경우 로컬 솔리드 스테이트 드라이브(로컬 SSD)를 사용하여 특정 성능 요구사항을 충족할 수도 있습니다.

비용에 맞게 최적화

트래픽 수준이 낮음에서 중간 수준인 MySQL 데이터베이스 또는 테스트 또는 개발 환경에서 사용되는 데이터베이스와 같이 비용 최적화가 최우선인 워크로드의 경우 최신 N4 인스턴스를 사용하는 것이 좋습니다. 이러한 인스턴스는 Compute Engine의 차세대 동적 리소스 관리를 사용하여 C4, C4A, C3, C3D에서 제공하는 강력한 보장 없이도 안정적인 성능을 유지하면서 총비용을 최적화합니다. 자세한 내용은 차세대 동적 리소스 관리를 참고하세요.

VM 크기 구성

사용하는 VM에 대해 목표로 하는 MySQL 성능 수준에 적합한 VM 크기를 선택하는 것이 중요합니다.

높은 초당 쓰기 트랜잭션(TPS) 성능을 목표로 하는 경우 고려해야 할 주요 요소는 블록 스토리지입니다. 자세한 내용은 이 페이지의 뒷부분에 나오는 블록 스토리지 구성을 참고하세요.

높은 초당 읽기 쿼리수(QPS) 성능을 목표로 하는 경우 MySQL의 RAM 기반 버퍼 풀을 사용하여 자주 액세스하는 데이터를 캐시하고 디스크 액세스를 줄이는 것이 좋습니다. 이러한 이점을 극대화하려면 다음 단계를 따르세요.

  • 작업 세트, 즉 데이터베이스에서 한 번에 처리하는 총 데이터 양이 버퍼 풀에 맞도록 VM 크기를 선택합니다.
  • VM에서 RAM을 최대한 많이 사용하도록 버퍼 풀의 크기를 조정합니다.

이와 같이 VM 크기를 조정할 때 비용을 최소화하려면 사용하지 않는 vCPU에 대한 비용을 지불하지 않도록 RAM과 가상 CPU(vCPU)의 비율이 높은 VM을 사용하는 것이 좋습니다.

대부분의 MySQL 워크로드에 적합하게 균형을 맞추려면 워크로드의 작업 세트를 확인한 후 RAM에서 해당 작업 세트에 맞는 가장 작은 highmem 인스턴스 형태를 선택하세요. highmem 인스턴스 형태에는 vCPU당 약 8GB의 RAM이 있습니다. 이는 대규모 작업 세트를 캐시할 수 있는 충분한 메모리를 제공하는 동시에 높은 쿼리 부하를 처리할 수 있는 충분한 CPU를 유지합니다.

작업 세트가 크지만 쿼리 비율이 낮은 워크로드의 경우 N4 인스턴스를 사용하여 확장 메모리가 있는 커스텀 머신 유형을 사용하여 RAM 대 vCPU 비율을 늘려 총비용을 추가로 최적화할 수 있습니다.

VM의 네트워크 대역폭 구성

대부분의 MySQL 사용 사례에서는 인스턴스의 기본 네트워크 대역폭 한도를 유지할 수 있습니다. 이 방법이 요구사항에 적합하다면 Tier_1 네트워킹으로 업그레이드하지 않아도 됩니다.

블록 스토리지 구성

Google Cloud Hyperdisk는 최신 Compute Engine VM 계열에서 사용할 수 있는 내구성이 뛰어난 유일한 블록 스토리지 세대입니다. Hyperdisk Balanced는 대부분의 MySQL 워크로드에 가장 적합합니다. Hyperdisk에 대한 자세한 내용은 Hyperdisk 문서를 참고하세요.

Google Cloud Hyperdisk

Hyperdisk Balanced는 다음과 같은 기능을 제공합니다.

  • 비용이 저렴한 솔리드 스테이트 드라이브(SSD) 지연 시간
  • 고성능이 필요한 애플리케이션을 위한 고성능 구성
  • 99.999% 이상의 내구성으로 업계 전반의 하드웨어 장애 및 드러나지 않은 데이터 손상 위험으로부터 보호
  • Google 관리 또는 고객 관리 암호화 키를 사용하여 모든 Hyperdisk 저장 데이터 암호화

성능 수준 선택

Hyperdisk Balanced를 사용하면 디스크의 스토리지 크기와 독립적으로 성능 수준을 선택할 수 있으므로 워크로드에 필요한 입력/출력(I/O) 리소스에 대해서만 비용을 지불하면서 데이터베이스의 성능을 최적화할 수 있습니다. MySQL 데이터베이스의 버퍼 풀이 작업 세트보다 크면 안정적인 상태의 작업 중에 디스크를 건드리지 않고 버퍼 풀에서 거의 모든 읽기 쿼리를 처리할 수 있습니다.

Hyperdisk 볼륨의 성능 수준을 선택하려면 특히 다음 사항에 중점을 두고 MySQL 쓰기 워크로드를 고려하세요.

  • InnoDB 재실행 로그 액세스
  • InnoDB 데이터 파일 및 색인의 후속 업데이트

안정적인 상태의 작업 외에도 데이터베이스 유지보수 이벤트로 인해 디스크 성능이 급격히 상승할 수 있습니다. 이러한 상황이 발생하는 빈도는 데이터베이스의 쓰기 워크로드에 따라 높아지는 경향이 있으므로 재실행 로그를 사용한 비정상 종료 후 복구 또는 마지막 백업 이후 모든 데이터베이스 변경사항을 읽어 자체적으로 복사하는 백업 시스템과 같은 상황에서 발생할 가능성이 더 높습니다.

디스크 크기 조정

디스크 성능 한도를 조정하는 데 사용되는 세 가지 일반적인 전략이 있습니다.

  1. 기본 구성을 사용합니다. 각 디스크에는 초당 최소 3,000개의 입력/출력(IOPS)과 140MiBps의 처리량이 제공됩니다. 이는 기본 MySQL 워크로드 및 운영체제(OS) 부팅 볼륨에 충분합니다. 사용 사례가 이보다 커지면 워크로드를 중지하지 않고도 필요에 따라 프로비저닝된 I/O 성능을 수정할 수 있습니다.
  2. 기존 사용량을 측정합니다. 데이터베이스가 이미 다른 환경에서 실행 중인 경우 1분 이하의 세부사항으로 디스크 IOPS와 처리량을 기록합니다. 샘플 세트에 부하 변동과 일반 유지보수 이벤트가 포함되도록 1~2주간의 데이터를 확보한 후 해당 데이터 세트에서 높은 백분위수 값을 선택하고 자연적 증가 또는 예상치 못한 사용량을 고려하여 작은 버퍼를 추가합니다.
  3. 필요한 사항을 추정한 후 나중에 수정합니다. 기존 데이터 소스가 없는 경우 먼저 성능 요구사항을 추정하고 배포 후에 추가로 조정해야 할 수 있습니다. 워크로드에 성능 병목 현상이 발생하지 않도록 처음에는 예상 필요량보다 높은 값을 프로비저닝한 다음, 프로비저닝된 성능을 워크로드에 맞게 줄이는 것이 좋습니다.

디스크 성능 향상

각 Hyperdisk Balanced 디스크의 성능을 최대 160,000IOPS 및 2,400MBps 처리량까지 늘릴 수 있습니다. VM 크기는 Hyperdisk의 최대 성능 한도를 결정하는 데 도움이 되므로 Hyperdisk 성능을 매우 높이려면 VM의 코어 수를 늘려야 할 수 있습니다. 가장 까다로운 워크로드에 단일 Hyperdisk Balanced 디스크에서 제공할 수 있는 것보다 높은 디스크 성능이 필요한 경우 다음 방법 중 하나를 사용하여 여러 Hyperdisk Balanced 디스크를 스트라이핑할 수 있습니다.

  • Hyperdisk Extreme으로 업그레이드
  • mdadm과 같은 다른 소프트웨어 복수 배열 독립 디스크(RAID) 메커니즘 사용

MySQL 데이터베이스를 확장할 때 다운타임 없이 디스크의 용량과 성능을 동적으로 늘릴 수 있습니다. 이렇게 하면 RAM에 맞지 않고 디스크로 유출되는 대규모의 복잡한 조인을 실행하는 온라인 분석 처리(OLAP) 스타일 워크로드의 성능이 향상됩니다. 드물지만 매우 낮은 스토리지 지연 시간이 필요하고 데이터 손실을 허용할 수 있는 MySQL 워크로드는 로컬 SSD에 전체 데이터 세트를 저장할 수 있습니다. 다음과 같은 하이브리드 솔루션을 사용하여 읽기 지연 시간을 단축하고 내구성 감소를 제한할 수도 있습니다.

  • Hyperdisk와 로컬 SSD 간에 데이터 세트를 미러링합니다.
  • 볼륨 관리자를 사용하여 기본 Hyperdisk에 저장된 데이터의 캐시로 로컬 SSD를 구성합니다.

추가 Hyperdisk 기능 활용

또한 Hyperdisk는 온프레미스 고가용성 및 재해 복구 워크플로를 보강하거나 간소화할 수 있는 다음과 같은 기능을 제공합니다.

Compute Engine용 MySQL로 이러한 기능을 구성하는 방법에 대한 자세한 내용은 이 페이지의 뒷부분에 나오는 고가용성 섹션을 참고하세요.

로컬 SSD

일부 Compute Engine 머신 계열에서는 Hyperdisk 대신 로컬 SSD를 사용할 수 있습니다. 이는 내구성이 있는 스토리지는 아니지만 MySQL 워크로드에서 임시 테이블스페이스를 저장하는 데 자주 사용합니다.

로컬 SSD를 사용하여 MySQL 데이터베이스를 확장하는 방법에 대한 자세한 내용은 이 페이지의 뒷부분에 나오는 동적 디스크 크기 조절을 참고하세요.

추가 Compute Engine 기능

다음 Compute Engine 기능을 사용하여 MySQL 배포를 최적화할 수 있습니다.

Cloud Monitoring

VM의 성능과 인프라 서비스 사용량을 모니터링하려면Google Cloud 콘솔을 사용하세요. VM 인스턴스 페이지의 모니터링 가능성 탭에서 CPU 및 메모리 사용률, 네트워킹 대역폭, 인스턴스의 프로비저닝된 성능과 같은 성능 관련 측정항목을 모니터링할 수 있습니다. 마찬가지로 디스크 페이지의 모니터링 가능성 탭에서 디스크 볼륨의 처리량과 IOPS를 모니터링할 수 있습니다.

표시되는 성능 측정항목을 맞춤설정하려면 Cloud Monitoring을 사용하여 쿼리를 작성하세요. 인프라 서비스에 대해 표시할 특정 성능 측정항목을 선택할 수 있습니다. Compute Engine은 MySQL 관련 측정항목에 대해 MySQL 워크로드 플러그인을 제공합니다.

운영체제 구성에 대한 권장사항

  • 적절한 파일 시스템을 사용합니다. Google은 Linux의 ext4 및 XFS 파일 시스템에 맞게 최적화하는 데 중점을 두지만 대부분의 파일 시스템은 MySQL과 함께 사용하기에 적합합니다.
  • 기본 운영체제 구성에서 Transparent Huge Pages(THP)를 사용 중지합니다. THP를 사용 중지하는 단계는 THP 문서를 참고하세요.
  • Linux를 사용하는 경우 파일 시스템 마운트 구성에 relatime 및 lazytime 플래그를 사용합니다. 이렇게 하면 파일을 읽거나 수정하거나 파일의 메타데이터가 변경될 때 파일의 atime, mtime, ctime 값을 업데이트하는 데 따른 성능 오버헤드가 줄어듭니다.

MySQL 구성에 대한 권장사항

MySQL에는 다음 구성 설정을 사용하는 것이 좋습니다.

  • 최신 버전의 MySQL을 사용합니다. Google은 MySQL 8.0 이상 버전에 맞게 최적화하는 데 중점을 두고 있습니다.

  • 버퍼 풀 크기를 늘립니다. MySQL은 버퍼 풀을 사용하여 RAM에 데이터를 캐시하여 읽기 성능을 개선하고 디스크 액세스를 줄입니다. 기본적으로 MySQL의 버퍼 풀 크기는 128MiB로, 대부분의 실제 사용 사례에서 사용하기에는 너무 작습니다. 애플리케이션이 데이터베이스에서 액세스하는 작업 세트의 크기보다 크게 innodb_buffer_pool_size의 크기를 늘리는 것이 좋습니다. 이는 일반적으로 다음 단계로 구성됩니다.

    1. 실행 중인 MySQL 인스턴스 복사본에서 작업 세트의 크기를 측정하거나 추정합니다.
    2. 작업 세트에 적합한 충분한 RAM을 제공하는 가상 머신(VM) 크기와 형태를 선택합니다.
    3. 사용 가능한 RAM의 대부분을 차지하도록 VM의 버퍼 풀 크기를 구성합니다.

  • 이중 쓰기 버퍼를 사용 설정합니다. MySQL에는 잘린 쓰기를 방지하는 데 도움이 되는 이중 쓰기 버퍼가 있습니다. 잘린 쓰기란 쓰기 중간에 하드웨어 또는 전원 장애가 발생하면 디스크의 여러 블록에 적용되는 쓰기가 부분적으로만 커밋될 수 있는 장애 모드를 말합니다. 이 보호 기능을 활용하려면 innodb_doublewrite를 사용 설정하세요.

  • innodb_flush_log_at_trx_commit 값을 1로 설정합니다. 이렇게 하면 커밋된 쓰기 트랜잭션이 디스크에서 지속됩니다.

  • 성능 오버헤드를 줄이려면 innodb_flush_method 값을 지정하세요. MySQL 8.0.14 이상 버전의 경우 innodb_flush_method 값을 이러한 버전에서만 존재하는 최적의 값인 O_DIRECT_NO_FSYNC로 설정합니다. MySQL 8.0.14 이전 버전에서는 innodb_flush_method 값을 O_DIRECT로 설정합니다.

  • 고가용성 복제 시나리오에서는 기본 데이터베이스 인스턴스의 sync_binlog 값을 1로 설정합니다. MySQL은 바이너리 로그를 사용하여 기본 데이터베이스에서 보조 데이터베이스로 변경사항을 전달하므로 트랜잭션 커밋 시간에 데이터베이스 간에 가능한 가장 낮은 복제 지연 시간과 목표 복구 시간(RPO)으로 바이너리 로그가 커밋됩니다.

  • C 시리즈 머신 계열에서 MySQL을 사용하는 경우 innodb_numa_interleave를 사용 설정합니다. 이렇게 하면 MySQL의 버퍼 풀이 비균일 메모리 액세스(NUMA) 정책을 활용할 수 있습니다.

이중 쓰기 버퍼를 사용 중지해야 하는 경우

잘린 쓰기를 방지하는 MySQL의 이중 쓰기 버퍼는 MySQL 쓰기 트랜잭션의 성능 오버헤드가 최대 25%이므로 트랜잭션 지연 시간에 영향을 줄 수 있습니다. Google Cloud Hyperdisk는 잘린 쓰기 방지 기능도 제공하므로 MySQL을 사용하여 Hyperdisk에서 실행되는 ext4 파일 시스템에 직접 쓰는 경우 doublewrite 버퍼를 안전하게 사용 중지할 수 있습니다.

하지만 Hyperdisk의 잘린 쓰기 보호가 효과적으로 작용하도록 하려면 파일 시스템을 구성하고 데이터베이스와 디스크 사이에 기타 중간 소프트웨어 레이어를 구성하여 디스크 레이어 위에 잘린 쓰기가 발생하지 않도록 해야 합니다. 다음 목록은 Hyperdisk 레이어 위에 잘린 쓰기를 도입할 수 있는 구성의 예를 보여줍니다.

  • Google Kubernetes Engine 또는 자체 호스팅 Kubernetes와 같은 컨테이너 내에서 MySQL 인스턴스 실행
  • 대부분의 Linux 커널 구성에서 충분히 큰 블록 크기를 지원하지 않는 XFS 파일 시스템에 MySQL 파일 저장
  • 디스크 스트라이핑을 유발하는 복수 배열 독립 디스크(RAID) 구성(예: Linux용 mdadm, Windows용 Storage Spaces 및 Storage Spaces Direct)에 MySQL 파일 저장
  • Linux용 Logical Volume Manager(LVM) 또는 Windows용 Storage Spaces 및 Storage Spaces Direct와 같은 볼륨 관리자 위에 MySQL 파일 저장

  • 로컬 솔리드 스테이트 드라이브(SSD)가 캐시로 구성된 Hyperdisk에 MySQL 파일 저장(예: Linux용 lvmcache, dm-cache 또는 bcache 사용, Windows용 Storage Spaces 사용)

  • 중첩된 가상화를 사용하여 VM 내에서 MySQL 인스턴스 실행

잘린 쓰기가 발생하지 않도록 위의 구성을 설정할 수 있지만, 특정 구성이 안전한지 확인하기가 어렵기 때문에 이러한 구성을 사용할 때는 이중 쓰기 버퍼를 사용 중지하지 않는 것이 좋습니다.

(선택사항) 이중 쓰기 버퍼 사용 중지

이중 쓰기 버퍼를 사용 중지하려면 다음 단계를 완료하세요.

  1. ext4 파일 시스템에서는 bigalloc 기능을 사용 설정하고 파일 시스템의 클러스터 크기를 16KiB 또는 16KiB에 2를 곱하고 거듭제곱한 값보다 큰 값으로 구성해야 합니다. 이렇게 하면 MySQL의 쓰기가 Hyperdisk에 실행되기 전에 파일 시스템에 의해 별도의 IO로 분할되지 않습니다. 한도를 높이지 않거나 16KiB보다 작은 값을 사용하면 잘린 쓰기를 방지할 수 없습니다. 16KiB 클러스터 크기 예시와 같이, 이는 파일 시스템 생성 시 다음과 같이 구성됩니다.

    mkfs.ext4 -O bigalloc -C 16384 /dev/<device-name>

  2. innodb_doublewrite를 사용 중지하고 innodb_flush_method를 O_DIRECT 또는 O_DIRECT_NO_FSYNC로 설정합니다(위에서 설명한 대로 MySQL 버전에 따라 다름).

고가용성(HA) 및 백업 솔루션 구성

고가용성(HA) 및 백업 솔루션을 구성하여 중요한 MySQL 워크로드를 모두 보호하는 것이 좋습니다. HA와 백업 모두에서는 다음 요소가 가장 중요합니다.

HA 솔루션은 일반적으로 RTO와 RPO를 0에 가깝게 만드는 것을 목표로 하지만 인프라 장애만 방지합니다. 백업 솔루션은 더 긴 RTO 및 RPO 기간을 타겟팅하지만 다음과 같은 더 광범위한 장애 시나리오를 지원합니다.

  • 실수로 인한 데이터 삭제
  • 랜섬웨어 공격
  • 자연 재해

고가용성(HA) 구성

HA 기능은 스토리지 및 컴퓨팅 중복성을 사용하여 호스트 장애 또는 중단 시 MySQL 데이터베이스의 다운타임을 줄여 인스턴스 또는 영역을 사용할 수 없는 경우에도 클라이언트 애플리케이션이 데이터에 액세스할 수 있도록 합니다.

MySQL에서는 다음 모드로 복제가 가능합니다.

  • 비동기 모드. 비동기 모드에서는 쓰기 트랜잭션이 로컬에 커밋되는 즉시 기본 인스턴스가 이를 확인하므로 기본 인스턴스에 장애가 발생하면 RPO가 0에 가깝지만 실제로 0은 아니므로 장애 조치 중에 최근에 작성된 데이터가 약간 손실될 수 있습니다.
  • 일부 동기 모드. 일부 동기 모드에서는 구성 가능한 수의 복제본이 트랜잭션 수신을 확인할 때까지 기본 인스턴스가 트랜잭션 확인을 기다립니다. 이 경우 RPO가 사실상 0이므로 계획되지 않은 장애 조치 중에 데이터 손실이 발생하지 않을 가능성이 크게 높아집니다.

두 모드 모두에서 RTO는 다음과 같은 상태 점검 작업이 얼마나 빨리 수행되는지에 따라 결정됩니다.

  1. 실패한 인스턴스를 식별합니다.
  2. 장애 조치를 트리거합니다.
  3. DNS(도메인 이름 시스템) 또는 데이터베이스 서버를 식별하는 다른 방법을 사용하여 장애 조치 인스턴스가 이제 기본 인스턴스임을 클라이언트에 알립니다.

어떤 복제 모드에서든 복제할 장애 조치 인스턴스가 있어야 합니다. 다음 위치에서 인스턴스를 찾을 수 있습니다.

  • 기본 인스턴스가 있는 영역과 동일한 영역
  • 기본 인스턴스가 있는 리전 내의 다른 영역
  • 기본 인스턴스가 있는 리전과 다른 리전

영역 서비스 중단 중에도 고가용성을 유지하려면 다음 구성을 사용하는 것이 좋습니다.

  • 기본 인스턴스와 장애 조치 인스턴스를 서로 다른 영역에 배치합니다. 동일한 리전 내에 있는지 여부는 중요하지 않습니다.
  • 비동기 복제를 사용합니다. 일부 동기 복제를 사용하는 경우 기본 인스턴스와 장애 조치 인스턴스를 별도의 영역에 배치하면 쓰기 트랜잭션 커밋의 지연 시간이 길어질 수 있기 때문입니다.
  • 복구 지점 목표가 0인 경우 Hyperdisk Balanced High Availability를 사용합니다. 그러면 동일한 리전의 두 영역에 디스크를 동기식으로 복제할 수 있습니다. 자세한 내용은 Hyperdisk High Availability를 사용하여 HA 서비스를 제공하는 방법에 관한 Google 가이드를 참고하세요. Hyperdisk Balanced High Availability를 구성할 때는 스테이트풀(Stateful) 관리형 인스턴스 그룹과 통합하여 인스턴스 상태 문제를 진단하고 복구 작업을 자동화하는 것이 좋습니다.

백업 및 데이터 복원력 계획 구성

백업 및 데이터 복원력 계획은 실수로 인한 데이터 삭제, 랜섬웨어 공격, 자연재해와 같은 장애 발생 시 데이터 손실을 방지하는 데 도움이 됩니다. 규정 준수 및 감사 요구사항을 위한 콜드 스토리지로도 사용할 수 있습니다. MySQL의 경우 많은 백업 방법론 중에서 선택할 수 있으며, 일부는 데이터베이스 수준에서 작용하고 일부는 스토리지 볼륨 수준에서 작용합니다. 방법론을 선택할 때는 주로 RTO 및 RPO 요구사항을 고려해야 합니다.

데이터베이스 수준에서 백업

데이터베이스 수준 백업의 경우 MySQL에서 제공하는 다음 옵션을 사용하는 것이 좋습니다.

  • 바이너리 로깅을 기반으로 하는 증분 백업: 논리적 데이터 덤프를 만듭니다. 예를 들면 다음과 같습니다.
  • MySQL Enterprise Backup과 같이 백업 프로세스를 자동으로 관리하는 도구

MySQL의 데이터베이스 수준 백업 옵션에 대한 자세한 내용은 MySQL 문서의 백업 및 복구를 참고하세요.

이러한 옵션 중 하나를 사용하려면 백업 데이터를 복사할 보조 스토리지 시스템이 있어야 합니다. 다음 도구를 사용하는 것이 좋습니다.

Hyperdisk를 사용하여 스토리지 수준에서 스냅샷 생성 및 클론

스토리지 수준 백업의 경우 MySQL 데이터베이스의 특정 시점 보기 스냅샷 생성, 클론 또는 캡처에 Hyperdisk 제품을 사용하는 것이 좋습니다. 이 접근 방식의 RPO는 데이터베이스 스냅샷을 얼마나 자주 생성하는지에 따라 달라지고, RTO는 사용하는 특정 솔루션에 따라 달라집니다.

빠른 복구가 중요하고 영역 내에서만 백업 적용이 필요한 경우 Hyperdisk의 인스턴트 스냅샷을 사용하는 것이 좋습니다. 인스턴트 스냅샷은 특정 시점의 데이터를 증분식으로 캡처하며 디스크 클로닝을 통해 새 Hyperdisk 볼륨에 데이터를 빠르게 복원하여 몇 분 단위의 RTO를 제공할 수 있습니다. 디스크의 콘텐츠가 덮어써지거나 삭제되거나 손상된 경우 데이터를 복구할 수 있으며 소스 디스크와 동일한 영역 또는 리전에서 로컬로 사용할 수 있습니다. 자세한 내용은 인스턴스 스냅샷 정보를 참고하세요.

데이터가 원본 디스크보다 높은 중복성으로 저장되어야 하고 단일 재해가 데이터의 모든 복제본이 영향을 주지 않도록 데이터를 별도의 위치에 저장해야 하는 재해 복구 시나리오의 경우 Hyperdisk의 보관처리 및 표준 디스크 스냅샷을 사용하는 것이 좋습니다. 보관처리 및 표준 디스크 스냅샷은 디스크에 특정 시점 데이터의 복사본을 만들어 변경 불가능한 형식을 사용하여 높은 중복성으로 저장합니다. 스냅샷 일정과 같이 디스크의 스냅샷을 여러 개 만들면 Hyperdisk는 증분 변경사항만 저장합니다. 스냅샷 스토리지에서 VM 스토리지로 데이터를 다시 복사하면 복원하는 데 시간이 오래 걸릴 수 있으므로 RTO가 높아도 괜찮다면 보관처리 및 표준 디스크 스냅샷이 적합합니다. 자세한 내용은 보관처리 및 표준 디스크 스냅샷 만들기를 참고하세요.

Hyperdisk의 인스턴트 스냅샷과 보관처리 및 표준 스냅샷은 모두 단일 디스크 내에서 비정상 종료 일관성을 유지합니다. 즉, 스냅샷에서 복원할 때는 MySQL 데이터베이스가 로그와 데이터 파일을 일관된 상태로 되돌리기 위해 일반적인 InnoDB 복구 단계를 실행해야 합니다. 따라서 InnoDB 재실행 로그 구성에 따라 RTO가 길어질 수 있습니다. 다음 패턴은 일관된 데이터베이스 스냅샷을 만드는 작업을 더욱 복잡하게 만들 수 있습니다.

  • MySQL 데이터베이스 파일이 여러 볼륨에 분산되어 있습니다.
  • mdadm 같은 Linux 소프트웨어 RAID 유틸리티를 사용하고 있습니다.
  • MySQL의 구성된 저장소 위치를 서로 다른 디스크의 파일 시스템으로 분리했습니다.

스냅샷 복원 후 복구가 필요하지 않은 스냅샷을 만들려면 다음 단계를 완료하세요.

  1. MySQL 데이터베이스에 대한 쓰기 액세스를 일시적으로 잠급니다.
  2. LOCK INSTANCE FOR BACKUP 및 FLUSH TABLES WITH READ LOCK 명령어를 사용하여 진행 중인 모든 버퍼를 디스크에 플러시합니다.
  3. 스냅샷 작업을 시작합니다.

  4. 다중 디스크 시나리오의 경우 MySQL 수준에서 플러시한 후 서버에서 sync 및 fsfreeze 명령어를 실행하여 진행 중인 모든 쓰기를 디스크에 플러시하고 파일 시스템 수준에서 새로 수신되는 쓰기를 일시중지합니다.

데이터베이스의 초기 스냅샷을 캡처한 후에는 디스크를 계속 잠글 필요가 없습니다. Hyperdisk는 특정 시점의 보기를 빠르게 캡처한 후 후속 스토리지 복사 단계를 비동기식으로 처리할 수 있기 때문입니다. 스냅샷 일관성을 위해 이러한 단계가 필요하고 이러한 쓰기가 기본 데이터베이스에 영향을 주지 않도록 하려면 기본 데이터베이스가 아닌 데이터베이스 복제본에 대해 백업을 실행하면 됩니다.

다음 단계