Loading...
MySQL 9.5 Reference Manual 9.5의 9.1 Backup and Recovery Types의 한국어 번역본입니다.
아래의 경우에 피드백에서 신고해주신다면 반영하겠습니다.
감사합니다 :)
이 절에서는 서로 다른 유형의 백업의 특성을 설명합니다.
Physical backup는 데이터베이스 내용을 저장하는 디렉터리와 파일의 로(raw) 복사본으로 구성됩니다. 이 유형의 백업은 문제가 발생했을 때 빠르게 복구해야 하는 크고 중요한 데이터베이스에 적합합니다.
Logical backup는 논리적 데이터베이스 구조( CREATE DATABASE, CREATE TABLE statement)와 내용( INSERT statement 또는 구분된 텍스트 파일)으로 표현되는 정보를 저장합니다. 이 유형의 백업은 데이터 값이나 테이블 구조를 수정하거나, 다른 머신 아키텍처에서 데이터를 재생성하려는 소량의 데이터에 적합합니다.
Physical backup method에는 다음과 같은 특성이 있습니다:
Backup은 데이터베이스 디렉터리와 파일의 정확한 복사본으로 구성됩니다. 일반적으로 이것은 MySQL 데이터 디렉터리 전체 또는 일부의 복사본입니다.
Physical backup method는 변환 없이 파일 복사만 수행하므로 logical backup보다 더 빠릅니다.
Output은 logical backup보다 더 compact합니다.
Backup 속도와 compact함은 바쁜 중요 데이터베이스에 중요하므로, MySQL Enterprise Backup product는 physical backup을 수행합니다. MySQL Enterprise Backup product에 대한 개요는 Section 32.1, “MySQL Enterprise Backup Overview”를 참조하십시오.
Backup 및 restore의 granularity는 전체 데이터 디렉터리 수준에서 개별 파일 수준까지 범위가 있습니다. 이는 스토리지 엔진에 따라 테이블 수준 granularity를 제공할 수도 있고 제공하지 않을 수도 있습니다. 예를 들어, InnoDB 테이블은 각각 별도의 파일에 있을 수도 있고, 다른 InnoDB 테이블과 파일 저장소를 공유할 수도 있습니다; 각각의 MyISAM 테이블은 하나의 파일 집합과 1:1로 대응됩니다.
데이터베이스 외에도 로그나 설정 파일과 같은 관련 파일을 backup에 포함할 수 있습니다.
MEMORY 테이블의 데이터는 내용이 디스크에 저장되지 않기 때문에 이 방식으로 backup하기가 까다롭습니다. (MySQL Enterprise Backup product에는 backup 중 MEMORY 테이블에서 데이터를 가져올 수 있는 기능이 있습니다.)
Backup은 하드웨어 특성이 동일하거나 유사한 다른 머신으로만 이식할 수 있습니다.
Backup은 MySQL 서버가 실행 중이 아닐 때 수행할 수 있습니다. 서버가 실행 중인 경우, backup 중에 서버가 데이터베이스 내용을 변경하지 못하도록 적절한 잠금을 수행해야 합니다. MySQL Enterprise Backup은 이러한 잠금이 필요한 테이블에 대해 이를 자동으로 수행합니다.
Physical backup tool에는 InnoDB 또는 기타 테이블용 MySQL Enterprise Backup의 mysqlbackup, 그리고 MyISAM 테이블용 파일 시스템 수준 명령(cp, scp, tar, rsync 등)이 포함됩니다.
Restore의 경우:
MySQL Enterprise Backup은 자신이 backup한 InnoDB 및 기타 테이블을 restore합니다.
ndb_restore는 NDB 테이블을 restore합니다.
파일 시스템 수준에서 복사한 파일은 파일 시스템 명령을 사용해 원래 위치로 다시 복사할 수 있습니다.
Logical backup method에는 다음과 같은 특성이 있습니다:
Backup은 MySQL 서버를 쿼리하여 데이터베이스 구조와 콘텐츠 정보를 얻는 방식으로 수행됩니다.
서버가 데이터베이스 정보를 액세스하고 이를 논리적 포맷으로 변환해야 하므로 backup은 physical method보다 느립니다. Output이 클라이언트 측에 기록되는 경우, 서버는 이를 backup 프로그램으로 전송해야 합니다.
특히 텍스트 포맷으로 저장하는 경우 output은 physical backup보다 더 큽니다.
Backup 및 restore의 granularity는 서버 수준(모든 데이터베이스), 데이터베이스 수준(특정 데이터베이스의 모든 테이블), 또는 테이블 수준에서 가능합니다. 이는 스토리지 엔진과 무관하게 적용됩니다.
Backup에는 로그나 설정 파일 또는 데이터베이스의 일부가 아닌 기타 데이터베이스 관련 파일은 포함되지 않습니다.
Logical 포맷으로 저장된 backup은 머신에 독립적이며 이식성이 매우 좋습니다.
Logical backup은 MySQL 서버가 실행 중인 상태에서 수행됩니다. 서버는 오프라인으로 전환되지 않습니다.
Logical backup tool에는 mysqldump program과 SELECT ... INTO OUTFILE statement가 있습니다. 이는 MEMORY를 포함한 모든 스토리지 엔진에서 동작합니다.
Logical backup을 restore하려면, SQL 포맷 덤프 파일을 mysql 클라이언트를 사용해 처리할 수 있습니다. 구분된 텍스트 파일을 로드하려면 LOAD DATA statement나 mysqlimport client를 사용하십시오.
Online backup은 MySQL 서버가 실행 중일 때 수행되어, 서버로부터 데이터베이스 정보를 얻을 수 있게 합니다. Offline backup은 서버가 중지된 상태에서 수행됩니다. 이러한 구분은 “hot” backup과 “cold” backup으로도 설명할 수 있습니다. “warm” backup은 서버가 계속 실행되지만, 외부에서 데이터베이스 파일에 접근하는 동안 데이터 수정에 대해서는 잠긴 상태를 말합니다.
Online backup method에는 다음과 같은 특성이 있습니다:
Backup이 다른 클라이언트에 덜 침습적입니다. 다른 클라이언트는 backup 중에도 MySQL 서버에 연결할 수 있으며, 수행해야 할 작업에 따라 데이터에 액세스할 수 있을 수도 있습니다.
Backup의 무결성이 손상되지 않도록 데이터 수정이 일어나지 못하게 적절한 잠금을 적용해야 합니다. MySQL Enterprise Backup product는 이러한 잠금을 자동으로 수행합니다.
Offline backup method에는 다음과 같은 특성이 있습니다:
서버가 backup 동안 사용할 수 없기 때문에 클라이언트에 불리하게 작용할 수 있습니다. 이러한 이유로 이러한 backup은 종종 가용성을 해치지 않고 오프라인으로 전환할 수 있는 replica에서 수행됩니다.
클라이언트 액티비티로 인한 간섭 가능성이 없으므로 backup 절차가 더 단순합니다.
Online과 offline 사이의 유사한 구분은 recovery 작업에도 적용되며, 유사한 특성이 적용됩니다. 다만 online recovery는 online backup보다 클라이언트에 영향을 미칠 가능성이 더 큽니다. Recovery에는 더 강한 잠금이 필요하기 때문입니다. Backup 동안에는 클라이언트가 backup이 진행되는 동안 데이터를 읽을 수 있을 수도 있습니다. Recovery는 데이터를 단순히 읽는 것이 아니라 수정하므로, restore 중에는 클라이언트가 데이터에 액세스하지 못하도록 해야 합니다.
Local backup은 MySQL 서버가 실행 중인 동일한 호스트에서 수행되는 반면, remote backup은 다른 호스트에서 수행됩니다. 일부 유형의 backup에서는, output이 서버의 local에 기록되더라도 backup을 remote 호스트에서 시작할 수 있습니다.
mysqldump는 local 또는 remote 서버에 연결할 수 있습니다. SQL output (CREATE 및 INSERT statement)의 경우, local 또는 remote dump를 수행해 클라이언트 측에서 output을 생성할 수 있습니다. 구분된 텍스트 output( --tab 옵션 사용)의 경우, 데이터 파일은 서버 호스트에 생성됩니다.
SELECT ... INTO OUTFILE는 local 또는 remote 클라이언트 호스트에서 시작할 수 있지만, output 파일은 서버 호스트에 생성됩니다.
Physical backup method는 일반적으로 MySQL 서버 호스트에서 local로 시작되어 서버를 오프라인으로 전환할 수 있도록 합니다. 단, 복사된 파일의 대상 위치는 remote일 수도 있습니다.
일부 파일 시스템 구현은 “snapshot”을 생성할 수 있게 해줍니다. 이는 전체 파일 시스템의 physical 복사를 요구하지 않고, 특정 시점의 파일 시스템에 대한 logical 복사를 제공합니다. (예를 들어 구현에서 copy-on-write 기술을 사용해 snapshot 시점 이후에 수정된 파일 시스템의 부분만 복사하도록 할 수 있습니다.) MySQL 자체는 파일 시스템 snapshot을 수행할 수 있는 기능을 제공하지 않습니다. 이는 Veritas, LVM, ZFS 같은 서드파티 솔루션을 통해 사용할 수 있습니다.
Full backup은 특정 시점에 MySQL 서버가 관리하는 모든 데이터를 포함합니다. Incremental backup은 특정 기간(한 시점에서 다른 시점까지) 동안 데이터에 대해 수행된 변경으로 구성됩니다. MySQL에는 이 절 앞부분에서 설명한 것과 같이 full backup을 수행하는 여러 방식이 있습니다. Incremental backup은 서버의 binary log를 활성화함으로써 가능해지며, 서버는 이를 이용해 데이터 변경을 기록합니다.
Full recovery는 full backup으로부터 모든 데이터를 restore합니다. 이는 backup이 수행되었을 때의 서버 인스턴스 상태를 복원합니다. 해당 상태가 충분히 최신 상태가 아니라면, full recovery 이후에 full backup 이후에 수행된 incremental backup을 추가로 recovery하여 서버를 보다 최신 상태로 만들 수 있습니다.
Incremental recovery는 특정 기간 동안 수행된 변경을 recovery하는 것입니다. 이는 point-in-time recovery라고도 하며, 서버의 상태를 특정 시점까지 최신 상태로 만드는 것을 의미합니다. Point-in-time recovery는 binary log를 기반으로 하며, 일반적으로 서버를 backup 시점 상태로 복원하는 backup 파일로부터의 full recovery 이후에 수행됩니다. 그런 다음 binary log 파일에 기록된 데이터 변경을 incremental recovery로 적용하여 데이터 수정 작업을 다시 수행하고, 서버를 원하는 시점까지 끌어올립니다.
Table이 손상되면 데이터 무결성이 손상될 수 있습니다. InnoDB 테이블의 경우, 이는 일반적인 문제가 아닙니다. MyISAM 테이블을 검사하고 문제가 발견되면 이를 repair하는 program에 대해서는, Section 9.6, “MyISAM Table Maintenance and Crash Recovery”를 참조하십시오.
Backup scheduling은 backup 절차를 자동화하는 데 유용합니다. Backup output을 압축하면 공간 요구 사항을 줄일 수 있고, output을 암호화하면 backup된 데이터에 대한 무단 액세스에 대해 더 나은 보안을 제공합니다. MySQL 자체는 이러한 기능을 제공하지 않습니다. MySQL Enterprise Backup product는 InnoDB backup을 압축할 수 있으며, backup output의 압축이나 암호화는 파일 시스템 유틸리티를 사용해 달성할 수 있습니다. 다른 서드파티 솔루션도 사용 가능할 수 있습니다.
9 Backup and Recovery
9.2 Database Backup Methods
