9.2 Database Backup Methods

9.2 Database Backup Methods

이 섹션에서는 backup을 수행하기 위한 일반적인 방법들을 요약합니다.

Making a Hot Backup with MySQL Enterprise Backup

MySQL Enterprise Edition의 고객은 MySQL Enterprise Backup product를 사용하여 전체 instance 또는 선택한 database, table, 혹은 둘 다에 대해 physical backup을 수행할 수 있습니다.

이 product는 incremental 및 compressed backup 기능을 포함합니다. physical database file을 backup하는 것은 mysqldump command와 같은 논리적 기법보다 restore를 훨씬 빠르게 해 줍니다.

InnoDB table은 hot backup mechanism을 사용하여 복사됩니다. (이상적으로, InnoDB table이 데이터의 상당한 대부분을 차지해야 합니다.) 다른 저장 엔진의 table은 warm backup mechanism을 사용하여 복사됩니다.

MySQL Enterprise Backup product에 대한 개요는 Section 32.1, “MySQL Enterprise Backup Overview”를 참조하십시오.

Making Backups with mysqldump

mysqldump program은 backup을 만들 수 있습니다. 이는 모든 종류의 table을 backup할 수 있습니다. (자세한 내용은 Section 9.4, “Using mysqldump for Backups”를 참조하십시오.)

InnoDB table의 경우, mysqldump에 --single-transaction option을 사용하여 table에 lock을 걸지 않는 온라인 backup을 수행할 수 있습니다. Section 9.3.1, “Establishing a Backup Policy”를 참조하십시오.

Making Backups by Copying Table Files

MyISAM table은 table file (*.MYD, *.MYI file 및 연관된 *.sdi file)을 복사하여 backup할 수 있습니다. 일관된 backup을 얻으려면 server를 중지하거나 관련 table을 lock하고 flush해야 합니다:

1FLUSH TABLES tbl_list WITH READ LOCK;

read lock만 필요합니다. 이렇게 하면 database directory에서 file을 복사하는 동안 다른 client가 계속해서 table을 query할 수 있습니다. flush는 backup을 시작하기 전에 모든 활성 index page가 disk에 기록되었는지를 보장하기 위해 필요합니다. Section 15.3.6, “LOCK TABLES and UNLOCK TABLES Statements” 및 Section 15.7.8.3, “FLUSH Statement”를 참조하십시오.

또한 server가 아무 것도 업데이트하지 않는 한, table file을 복사하는 것만으로 간단히 바이너리 backup을 생성할 수도 있습니다. (그러나 database에 InnoDB table이 포함되어 있는 경우 table file 복사 방법은 동작하지 않는다는 점에 유의하십시오. 또한 server가 데이터를 적극적으로 업데이트하지 않더라도, InnoDB는 여전히 수정된 데이터를 메모리에 cache하고 disk에 flush하지 않았을 수 있습니다.)

이 backup 방법의 예시는 Section 15.2.6, “IMPORT TABLE Statement”의 export 및 import 예제를 참조하십시오.

Making Delimited-Text File Backups

table의 data를 포함하는 텍스트 file을 생성하려면 SELECT * INTO OUTFILE 'file_name' FROM tbl_name를 사용할 수 있습니다. file은 client host가 아니라 MySQL server host에 생성됩니다. 이 statement의 경우, output file이 이미 존재해서는 안 됩니다. file overwrite를 허용하는 것은 보안 위험이 되기 때문입니다. Section 15.2.13, “SELECT Statement”를 참조하십시오. 이 방법은 어떤 종류의 data file에도 동작하지만 table 구조가 아닌 table data만 저장합니다.

backup한 table에 대한 CREATE TABLE statement를 포함하는 file과 함께 텍스트 data file을 생성하는 또 다른 방법은 mysqldump에 --tab option을 사용하는 것입니다. Section 9.4.3, “Dumping Data in Delimited-Text Format with mysqldump”를 참조하십시오.

delimited-text data file을 다시 load하려면 LOAD DATA 또는 mysqlimport를 사용하십시오.

Making Incremental Backups by Enabling the Binary Log

MySQL은 binary log를 사용하여 incremental backup을 지원합니다. binary log file은 backup을 수행한 시점 이후에 database에 가해진 변경을 복제하는 데 필요한 정보를 제공합니다.

따라서 server를 특정 시점으로 복구할 수 있도록 하려면 해당 server에서 binary logging이 활성화되어 있어야 하며, 이는 MySQL 9.5의 기본 설정입니다. Section 7.4.4, “The Binary Log”를 참조하십시오.

마지막 full 또는 incremental backup 이후에 발생한 모든 변경을 포함하는 incremental backup을 만들고자 하는 순간에, FLUSH LOGS를 사용하여 binary log를 rotate해야 합니다. 이 작업을 수행한 후, 마지막 full 또는 incremental backup 시점의 log부터 마지막 log 바로 전까지의 모든 binary log를 backup 위치로 복사해야 합니다.

이들 binary log가 incremental backup이며, restore 시에는 Section 9.5, “Point-in-Time (Incremental) Recovery”에 설명된 대로 이를 적용합니다. 다음에 full backup을 수행할 때도 FLUSH LOGS 또는 mysqldump --flush-logs를 사용하여 binary log를 rotate해야 합니다. Section 6.5.4, “mysqldump — A Database Backup Program”를 참조하십시오.

Making Backups Using Replicas

backup을 수행하는 동안 server에서 성능 문제가 발생한다면, 도움이 될 수 있는 한 가지 전략은 replication을 설정하고 backup을 source가 아닌 replica에서 수행하는 것입니다. Section 19.4.1, “Using Replication for Backups”를 참조하십시오.

replica를 backup하는 경우, 선택한 backup 방법과 관계없이, replica의 database를 backup할 때 connection metadata 저장소와 applier metadata 저장소를 ( Section 19.2.4, “Relay Log and Replication Metadata Repositories” 참조) 함께 backup해야 합니다. 이 정보는 replica의 data를 restore한 후 replication을 다시 시작하는 데 항상 필요합니다.

replica가 LOAD DATA statement를 replicate하고 있다면 replica가 이 목적을 위해 사용하는 directory에 존재하는 모든 SQL_LOAD-* file도 backup해야 합니다. replica는 중단된 LOAD DATA 작업의 replication을 재개하기 위해 이 file이 필요합니다. 이 directory의 위치는 system variable replica_load_tmpdir의 값입니다. server가 이 variable을 설정하지 않고 시작된 경우, directory 위치는 system variable tmpdir의 값입니다.

Recovering Corrupt Tables

손상된 MyISAM table을 restore해야 하는 경우, 먼저 REPAIR TABLE 또는 myisamchk -r를 사용하여 복구를 시도하십시오. 이는 전체 경우의 99.9%에서 동작해야 합니다. myisamchk가 실패하는 경우, Section 9.6, “MyISAM Table Maintenance and Crash Recovery”를 참조하십시오.

Making Backups Using a File System Snapshot

Veritas file system을 사용하는 경우, 다음과 같이 backup을 만들 수 있습니다:

1. client program에서 FLUSH TABLES WITH READ LOCK를 실행합니다.

2. 다른 shell에서 mount vxfs snapshot을 실행합니다.

3. 첫 번째 client에서 UNLOCK TABLES를 실행합니다.

4. snapshot에서 file을 복사합니다.

5. snapshot을 unmount합니다.

LVM이나 ZFS와 같은 다른 file system에서도 유사한 snapshot 기능을 사용할 수 있습니다.