Compute Engine에서 MySQL 구성

Compute Engine은 MySQL 데이터베이스에서 데이터를 읽고 쓰기 위한 다양한 인스턴스 유형과 스토리지 옵션을 제공합니다. 데이터베이스 워크로드에 최적의 성능과 비용을 제공하려면 최신 세대의 서비스형 인프라 (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 계열에서 사용할 수 있는 유일한 내구성 있는 블록 스토리지입니다. Google은 하이퍼디스크 균형이 대부분의 MySQL 워크로드에 가장 적합하다고 생각합니다. 하이퍼디스크에 관한 자세한 내용은 하이퍼디스크 문서를 참고하세요.

Google Cloud Hyperdisk

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

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

실적 수준 선택

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

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

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

정상 작동 외에도 데이터베이스 유지보수 이벤트로 인해 디스크 성능이 급격히 저하될 수 있습니다. 이 문제가 발생하는 빈도는 데이터베이스의 쓰기 워크로드에 따라 확장되는 경향이 있으므로 재시행 로그를 사용하는 비정상 종료 후 복구나 마지막 백업 이후의 모든 데이터베이스 변경사항을 읽어서 자체를 복사하는 백업 시스템과 같은 상황에서 더 자주 발생합니다.

디스크 크기 조절

디스크 성능 제한 크기를 조절하는 일반적인 전략에는 세 가지가 있습니다.

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

디스크 성능 향상

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

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

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

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

추가 Hyperdisk 기능 활용

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

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

로컬 SSD

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

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

추가 Compute Engine 기능

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

Cloud Monitoring

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

표시되는 성능 측정항목을 맞춤설정하려면 Cloud Monitoring을 사용하여 쿼리를 빌드하세요. 인프라 서비스에 대해 확인하려는 특정 성능 측정항목을 선택할 수 있습니다. MySQL 관련 측정항목의 경우 Compute Engine에서 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로 설정합니다. 이 값은 최적이지만 이러한 버전에서만 사용할 수 있습니다. 8.0.14 이전 버전의 MySQL에서는 innodb_flush_method 값을 O_DIRECT로 설정합니다.

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

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

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

손상된 쓰기를 방지하는 MySQL의 이중 쓰기 버퍼는 MySQL 쓰기 트랜잭션에 최대 25% 의 성능 오버헤드를 발생시켜 트랜잭션 지연 시간에 영향을 줄 수 있습니다. Google Cloud 하이퍼디스크는 찢어진 쓰기 보호 기능도 제공하므로 MySQL을 사용하여 하이퍼디스크에서 실행되는 ext4 파일 시스템에 직접 쓰는 경우 이중 쓰기 버퍼를 안전하게 사용 중지할 수 있습니다.

그러나 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의 쓰기가 하이퍼디스크에 전송되기 전에 파일 시스템에 의해 별도의 IOs로 분할되지 않습니다. 제한을 높이지 않거나 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) 및 백업 솔루션 구성

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

HA 솔루션은 일반적으로 거의 0에 가까운 RTO 및 RPO를 타겟팅하지만 인프라 장애에 대해서만 보호합니다. 백업 솔루션은 더 긴 RTO 및 RPO 기간을 타겟팅하지만 다음과 같은 더 많은 장애 시나리오에 대한 적용 범위를 제공합니다.

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

고가용성 (HA) 구성

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

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

  • 비동기 모드. 비동기 모드에서는 기본이 로컬에서 커밋되는 즉시 쓰기 트랜잭션을 확인합니다. 따라서 기본에 중단이 발생하면 RPO가 0에 가깝지만 실제로는 0이 아니므로 장애 조치 중에 최근에 작성된 소량의 데이터가 손실될 수 있습니다.
  • 준동기 모드. 반동기 모드에서는 구성 가능한 수의 복제본이 트랜잭션 수신을 확인할 때까지 기본 노드가 트랜잭션 확인을 기다립니다. 이렇게 하면 RPO가 사실상 0이므로 계획되지 않은 장애 조치 중에 데이터 손실이 발생할 가능성이 크게 줄어듭니다.

두 모드 모두 RTO는 상태 점검이 다음을 수행하는 속도에 따라 결정됩니다.

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

두 복제 모드 모두 복제할 장애 조치 인스턴스가 있어야 합니다. 다음 위치 중 한 곳에서 해당 인스턴스를 찾을 수 있습니다.

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

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

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

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

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

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

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

  • 논리적 데이터 덤프를 생성하는 바이너리 로깅을 기반으로 하는 증분 백업 여기에는 다음이 포함됩니다.
  • MySQL Enterprise 백업과 같은 백업 프로세스를 자동으로 관리하는 도구

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

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

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

스토리지 수준 백업의 경우 Hyperdisk 제품을 사용하여 MySQL 데이터베이스의 스냅샷을 찍거나, 클론하거나, 특정 시점의 뷰를 캡처하는 것이 좋습니다. 이 접근 방식의 RPO는 데이터베이스의 스냅샷을 찍는 빈도에 따라 달라지고 RTO는 사용하는 구체적인 솔루션에 따라 달라집니다.

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

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

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 명령어를 실행하여 디스크에 진행 중인 모든 쓰기를 플러시하고 파일 시스템 수준에서 새 수신 쓰기를 일시중지합니다.

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

다음 단계