MySQL 백업 및 복원
예상치 못한 상황이 발생하면 비즈니스에 악영향을 줄 수 있습니다. 하드웨어 오류, 데이터베이스 손상, 사용자 실수, 악의적인 공격으로 인해 데이터가 손실될 수 있습니다. 데이터베이스 백업은 문제가 발생하더라도 비즈니스를 복구하고 계속 운영하는 데 도움이 됩니다. 또한 문제가 없는 경우에는 데이터베이스 백업을 과거의 특정 시점으로 데이터베이스를 복원하는 데 사용할 수 있으므로 규정 준수 및 감사 요구사항을 충족합니다.
MySQL은 데이터베이스 백업을 위한 여러 옵션을 지원하며, 옵션마다 장점이 다릅니다. 니즈에 가장 적합한 방법의 조합을 선택할 수 있습니다.
백업 유형
MySQL 데이터베이스를 백업하는 방법에는 크게 물리적 백업 및 논리적 백업 두 가지가 있습니다. 물리적 백업은 실제 데이터 파일을 복사하고 논리적 백업은 CREATE TABLE 및 INSERT와 같이 데이터를 다시 만들 수 있는 문을 생성합니다.
물리적 백업
물리적 백업에는 디스크에 있는 모든 파일과 디렉터리의 원시 사본이 포함됩니다. 이 유형의 백업은 논리적 백업에 비해 원시 파일을 복사하는 것이 훨씬 빠르기 때문에 대규모 데이터베이스에 적합합니다.
장점:
- 물리적 백업은 많은 메모리나 CPU 주기 실행이 필요하지 않기 때문에 간단하고 효율적입니다.
- 물리적 백업은 원시 파일을 생성하는 데 추가 작업이 필요하지 않으며, 원시 파일과 디렉터리를 백업 위치에 복사하기만 하면 됩니다.
- 물리적 백업은 MySQL에서 데이터베이스 객체를 다시 만들고 데이터를 가져올 필요가 없기 때문에 논리적 백업보다 더 빠릅니다.
단점:
- 물리적 백업에는 InnoDB 테이블스페이스(공유되고 table.ibd 파일당 있으며 일반적으로 분할된 공간)뿐만 아니라 트랜잭션 로그, 실행취소 로그 등이 포함되므로 논리적 백업보다 공간이 훨씬 더 많이 필요합니다.
- 물리적 백업은 플랫폼, 운영체제, MySQL 버전 간에 이동성을 항상 보장하지는 않습니다.
- 물리적 백업은 원시 파일을 복사하므로 원시 파일에 기본적인 손상이 있는 경우 백업 파일에도 복사됩니다.
MySQL 생태계에서 일반적으로 사용되는 물리적 백업 도구
논리적 백업
논리적 백업에는 데이터베이스의 데이터가 MySQL에서 SQL이나 구분된 텍스트로 해석할 수 있는 형식으로 포함됩니다. 데이터베이스 객체를 다시 만들고 데이터를 가져오기 위해 실행할 수 있는 SQL 문의 시퀀스로 데이터베이스를 나타냅니다. 이 백업 유형은 소규모 데이터베이스에 적합합니다. 논리 백업을 복원하는 것이 물리적 백업을 복원하는 것보다 훨씬 시간이 오래 걸릴 수 있기 때문입니다. 이 백업 유형은 클라우드의 관리형 데이터베이스 서비스로 또는 그 반대로 마이그레이션할 때도 유용합니다.
장점:
- 논리적 백업은 매우 유연합니다. 논리적 백업은 서버 수준(모든 데이터베이스), 데이터베이스 수준(특정 데이터베이스의 모든 테이블), 테이블 수준 또는 심지어 행 수준(지정된 WHERE 조건과 일치하는 테이블 행)에서 백업 및 복원 작업에 대한 자세한 세부사항을 제공합니다.
- 논리적 백업은 복원이 쉽습니다. 백업 파일을 mysql 클라이언트로 파이핑하고 LOAD DATA 문 또는 mysqlimport 명령어를 사용하여 텍스트 구분 파일을 로드하기만 하면 됩니다.
- 논리적 백업은 다른 머신에서 원격으로 실행할 수 있으므로 네트워크를 통해 데이터베이스를 백업하고 복원할 수 있습니다. 논리적 백업은 사용자가 가상 머신에 직접 액세스할 수 없는 Google Cloud SQL, Amazon RDS, Microsoft Azure와 같은 클라우드 데이터베이스에 매우 유용합니다.
- 논리적 백업을 사용하면 데이터 손상을 방지할 수 있습니다. 물리적 백업은 손상될 수 있으며, 이는 인증될 때까지 알 수 없습니다. 논리적 백업은 일반적으로 텍스트 파일이므로 텍스트 편집기로 검토하여 손상을 찾아내기가 더 쉽습니다. 논리적 백업은 손상이 거의 발생하지 않습니다.
- 물리적 백업과 달리 논리적 백업은 플랫폼, 운영체제, MySQL 버전 간에 이동성이 높습니다.
- 논리적 백업은 압축성이 뛰어납니다.
단점:
- 논리적 백업은 MySQL 서버에 쿼리하여 스키마와 행을 얻은 다음 논리적 형식으로 변환해야 하므로 생성 속도가 느립니다.
- 논리적 백업은 또한 MySQL에서 테이블을 만들고, 행을 가져오고, 색인을 다시 빌드하기 위해 SQL 문을 실행해야 하기 때문에 복원도 느립니다.
- 물리적 백업에 비해 논리적 백업에는 백업 및 복원 작업에 더 많은 서버 리소스(CPU, RAM, 디스크 I/O)가 필요합니다.
몇 가지 일반적인 논리적 백업 도구
MySQL 셸 유틸리티 — 덤프 | 로드
특정 시점 복구(PITR)
이름에서 알 수 있듯이 PITR(point-in-time recovery)은 인스턴스를 특정 시점으로 복구하는 데 도움이 됩니다. 예를 들어 오류로 데이터가 손실된 경우 오류가 발생하기 전의 시점으로 데이터베이스를 복구할 수 있습니다.
PITR은 바이너리 로그를 사용하는 2단계 프로세스입니다.
- 전체 물리적 또는 논리적 백업을 복원하여 서버를 백업 당시와 동일한 상태로 되돌리기
- 바이너리 로그를 적용하여 백업 시점과 원하는 시점 간의 변경사항을 재생
바이너리 로그에는 테이블 만들기, 행 삽입/업데이트/삭제 등 데이터베이스 인스턴스에 대한 모든 변경사항이 포함됩니다. 예를 들어 일일 백업이 오전 6시에 실행되고 오전 10시 15분까지 언제든지 인스턴스를 복구하려고 한다고 가정해 보겠습니다. 오전 10시 15분에 상태를 복구하려면 먼저 오전 6시의 전체 백업을 복원한 다음 오전 6시에서 오전 10시 15분까지의 바이너리 로그 이벤트를 재생합니다. 이렇게 하면 서버가 원하는 시간에 원하는 상태로 전환됩니다.
복제 및 PITR에는 바이너리 로그가 필요합니다. 기본 데이터만큼 중요합니다. 바이너리 로그가 복구 계획에서 효과적이려면 실시간으로 백업되어야 하며 바이너리 로그는 mysqlbinlog 명령어를 사용하여 다운로드할 수 있습니다.
예를 들면 다음과 같습니다.
|
mysqlbinlog --host=<hostname> --port=<port> --user=<user> --password=<password> --read-from-remote-server --raw --stop-never <binlog_filename> |
<binlog_filename>이 첫 번째로 다운로드되는 파일이 되고, mysqlbinlog가 자동으로 다음 파일로 전환합니다. 이러한 바이너리 로그는 mysqlbinlog 명령어를 실행하는 서버의 현재 디렉터리에 작성됩니다. --result-file 옵션을 사용하면 파일 이름과 위치를 변경할 수 있습니다. --stop-never 옵션을 사용하면 mysqlbinlog binlog를 서버에 연결된 상태로 유지하고 새로 작성되는 변경사항을 다운로드할 수 있습니다.
mysqlbinlog 매뉴얼을 통해 원격 서버에 연결하고 작성된 바이너리 로그를 다운로드하는 방법에 대해 자세히 알아볼 수 있습니다.
MySQL용 Cloud SQL에서 백업 및 복원
Google Cloud의 MySQL용 관리형 데이터베이스 서비스인 Cloud SQL은 데이터 보호를 위한 자동 백업 및 PITR(point-in-time recovery)을 제공합니다. 기본적으로 사용 설정되며 MySQL용 Cloud SQL 인스턴스에서 고가용성(HA)을 사용 설정하는 데 필요합니다.
모든 Cloud SQL 백업은 영구 디스크(PD)에서 가져온 스냅샷이므로 물리적 백업의 한 유형입니다. Cloud SQL은 백업을 자동으로 수행하거나 언제든지 주문형으로 전환할 수 있는 유연성을 제공합니다. 또한 관리형 백업을 방해하지 않고 mysqldump, mydumper, mysqlpump 등의 표준 MySQL 논리적 백업 도구를 사용하여 논리적 백업을 수행할 수 있습니다.
Cloud SQL 백업의 작동 방식을 자세히 살펴보겠습니다.
Cloud SQL 스냅샷 이해하기
Cloud SQL은 스토리지에 Persistent Disk(PD)를 사용하며 모든 Cloud SQL 인스턴스에는 데이터베이스 파일 및 디렉터리를 저장할 수 있는 영구 데이터 디스크가 연결되어 있습니다.
Cloud SQL은 백업에 PD 스냅샷을 사용하며 이러한 스냅샷은 특정 시점의 데이터 디스크 상태를 참조합니다. PD의 첫 번째 스냅샷은 PD의 모든 데이터가 포함된 전체 스냅샷입니다. 후속 스냅샷은 증분 스냅샷이며 이전 스냅샷 이후의 새 데이터 또는 수정된 데이터만 포함합니다. 이러한 스냅샷은 클라우드에서 관리되는 영구 데이터 디스크의 실제 사본으로 간주되며 PITR을 비롯한 모든 Cloud SQL의 백업 및 복원 기능의 기반이 됩니다.
Cloud SQL 백업
Cloud SQL은 자동 및 주문형이라는 두 가지 유형의 관리형 백업을 수행합니다. 두 유형 모두 기본적으로 인스턴스와 가장 가까운 멀티 리전 위치에 저장됩니다. 예를 들어 Cloud SQL 인스턴스가 us-central1에 있으면 백업은 기본적으로 미국 멀티 리전에 저장됩니다. 하지만 australia-southeast1과 같은 기본 위치는 멀티 리전 외부에 있으며 가장 가까운 멀티 리전(아시아)에 배치됩니다. 백업에 커스텀 위치를 선택할 수도 있습니다.
자동 백업
자동 백업은 선택한 4시간 동안 매일 수행됩니다. 백업 기간 동안 백업이 시작되며 백업 기간이 끝난 후에도 완료될 때까지 계속될 수 있습니다. 1개에서 365개까지 보관할 자동 백업 수를 구성할 수 있습니다. 기본 보관 정책은 최근 백업 7개를 보관하는 것입니다.
주문형 백업
또한 언제든지 주문형 백업을 만들 수 있습니다. 백업이 필요하고 백업 기간까지 기다리지 않으려는 경우에 유용합니다. 또한 자동 백업과 달리 주문형 백업은 자동으로 삭제되지 않습니다. 사용자가 직접 삭제하거나 인스턴스가 삭제되기 전까지 유지됩니다.
Cloud SQL 백업 복원
백업이 수행된 동일한 인스턴스나 동일한 프로젝트의 다른 인스턴스로 백업을 복원할 수 있습니다. 대상 복제본은 읽기 복제본이 아니고 백업 복원 시점에 읽기 복제본이 없어야 합니다. 읽기 복제본은 기본 인스턴스의 사본이고 복제본이 기본 인스턴스와 동기화되지 않을 위험이 있습니다. 나중에 언제든지 읽기 복제본을 추가할 수 있습니다.
백업을 복원하면 해당 백업 스냅샷에서 새 PD가 만들어지고 인스턴스에 연결됩니다. 데이터베이스는 새 디스크 사용을 시작하고 스냅샷에서 새로 복원된 정식 MySQL 데이터베이스로 온라인 상태가 되기 전에 표준 MySQL 장애 프로세스를 수행합니다.
동일한 인스턴스로 복원
백업에서 동일한 인스턴스로 복원할 경우 해당 인스턴스의 데이터를 백업을 가져올 때의 상태로 되돌립니다.
다른 인스턴스로 복원
백업에서 다른 인스턴스로 복원할 경우, 대상 인스턴스의 데이터를 백업을 가져왔을 때 소스 인스턴스의 상태로 업데이트합니다.
중요: 백업을 복원하면 이전의 PITR(point-in-time recovery) 로그를 포함하여 대상 인스턴스의 현재 데이터를 모두 덮어씁니다. 덮어쓴 데이터는 복구할 수 없습니다.
Cloud SQL PITR(point-in-time recovery)
Cloud SQL에서 PITR은 인스턴스 클론 작업과 유사하게 소스 인스턴스의 설정을 상속하는 새 인스턴스를 항상 만듭니다. 이 기능을 사용하려면 소스 인스턴스에서 자동 백업과 PITR(바이너리 로그)을 모두 사용 설정해야 합니다. 바이너리 로그의 기본 보관 정책은 7일이며 1일부터 7일 사이로 보관 기간을 구성할 수 있습니다.
원본 인스턴스의 백업에서 새 인스턴스를 만들고 원본 인스턴스 데이터 디스크에 저장된 바이너리 로그를 지정된 지점으로 재생하면 PITR이 구현됩니다.
Cloud SQL에서 PITR을 수행할 때 고객은 인스턴스의 현재 상태를 클론하거나 과거의 타임스탬프로 클론할 수 있습니다.
PITR을 실행하는 UI는 다음과 같습니다.
관련 제품 및 서비스
Google Cloud는 온프레미스 데이터 센터 사용 중지부터 SaaS 애플리케이션 실행, 핵심 비즈니스 시스템 마이그레이션에 이르기까지 비즈니스 니즈에 맞게 설계된 관리형 MySQL 데이터베이스를 제공합니다.
