7.2 데이터베이스 백업 방법

이 섹션에서는 백업을 만들 경우의 일반적인 방법을 요약 한 것입니다.

MySQL Enterprise Backup 의한 핫 백업 만들기

MySQL Enterprise Edition 고객은 MySQL Enterprise Backup 제품을 사용하여 인스턴스 전체 또는 선택한 데이터베이스 테이블 또는 둘의 물리적 백업을 실행할 수 있습니다. 이 제품은 증분 및 압축 백업 기능이 포함되어 있습니다. 물리적 데이터베이스 파일의 백업은 복원이 mysqldump 명령 등의 논리 기법보다 훨씬 빨라집니다. InnoDB 테이블은 핫 백업 메커니즘을 사용하여 복사됩니다. (이상적으로는 InnoDB 테이블에서 데이터의 대부분을 나타내고있다한다.) 다른 스토리지 엔진의 테이블은 웜 백업 메커니즘을 사용하여 복사됩니다. MySQL Enterprise Backup 제품의 개요는 섹션 25.2 "MySQL Enterprise Backup" 을 참조하십시오.

mysqldump 또는 mysqlhotcopy에 의한 백업 만들기

mysqldump 프로그램과 mysqlhotcopy 스크립트로 백업을 만들 수 있습니다. mysqldump는 모든 종류의 테이블을 백업 할 수 있기 때문에보다 일반적인입니다. mysqlhotcopy는 일부 스토리지 엔진에서만 작동합니다. ( 섹션 7.4 "백업에 mysqldump 사용" 및 섹션 4.6.10 "mysqlhotcopy - 데이터베이스 백업 프로그램" 을 참조하십시오.)

InnoDB 테이블의 경우, mysqldump에 --single-transaction 옵션을 사용하여 테이블을 잠그지 온라인 백업을 수행 할 수 있습니다. 섹션 7.3.1 "백업 정책 설정" 을 참조하십시오.

테이블 파일을 복사하여 백업 만들기

자신의 파일을 사용하여 각 테이블을 나타내는 스토리지 엔진의 경우, 테이블은 그 파일을 복사하여 백업 할 수 있습니다. 예를 들어, MyISAM 테이블은 파일로 저장되므로 파일 ( *.frm , * *.MYD , 및 *.MYI 파일)을 복사하여 쉽게 백업을 할 수 있습니다. 일관된 백업을 취득하려면 서버를 중지하거나 관련 테이블을 잠그고 플러시합니다.

 FLUSH TABLES tbl_list WITH READ LOCK;

읽기 잠금 만 필요합니다. 이는 데이터베이스 디렉토리의 파일을 복사하는 동안 다른 클라이언트가 계속 테이블을 쿼리 할 수​​ 있습니다. 백업을 시작하기 전에 모든 액티브 인덱스 페이지를 디스크에 기록하도록하기 위해 플래시가 필요합니다. 섹션 13.3.5 "LOCK TABLES 및 UNLOCK TABLES 구문" 및 섹션 13.7.6.3 "FLUSH 구문" 을 참조하십시오.

서버가 아무것도 업데이트하지 않는 한, 모든 테이블 파일을 복사해서 바이너리 백업을 쉽게 만들 수 있습니다. mysqlhotcopy 스크립트는이 방법을 사용합니다. (단, 테이블 파일 복사 방법은 데이터베이스에 InnoDB 테이블이 포함되어있는 경우 작동하지 않습니다. InnoDB 는 반드시 데이터베이스 디렉토리에 테이블 내용을 저장하지 않기 때문에 mysqlhotcopy은 InnoDB 테이블에서 작동하지 않습니다. 또한 서버 이 활성화 데이터를 업데이트하지 않는 경우, InnoDB 는 변경된 데이터를 아직 메모리에 캐시하고 디스크에 플래시하지 않을 수 있습니다.)

구분 된 텍스트 파일 백업 만들기

테이블의 데이터가 포함 된 텍스트 파일을 작성하려면 SELECT * INTO OUTFILE ' file_name ' FROM tbl_name 를 사용할 수 있습니다. 이 파일은 클라이언트 호스트가 아니라 MySQL 서버 호스트에 생성됩니다. 이 문의 경우, 파일의 덮어 쓰기를 허용하면 보안 위험하므로 출력 파일이 이미 존재하고있어되지 않습니다. 섹션 13.2.9 "SELECT 구문" 을 참조하십시오. 이 방법은 모든 종류의 데이터 파일에 작동하지만 테이블 데이터 만 저장하고 테이블 구조는 저장되지 않습니다.

텍스트 데이터 파일 (백업 된 테이블의 CREATE TABLE 문이 포함 된 파일 이외에)를 만드는 다른 방법은 mysqldump와 --tab 옵션을 사용하는 것입니다. 섹션 7.4.3 "mysqldump에 의한 구분 된 텍스트 형식으로 데이터의 덤프" 를 참조하십시오.

구분 된 텍스트 데이터 파일을 다시로드하려면 LOAD DATA INFILE 또는 mysqlimport를 사용합니다.

바이너리 로깅을 사용해서 증분 백업의 작성

MySQL은 증분 백업을 지원합니다. --log-bin 옵션으로 서버를 시작하고 바이너리 로깅을 활성화해야합니다. 섹션 5.2.4 "바이너리 로그" 를 참조하십시오. 바이너리 로그 파일은 백업을 수행 한 시점의 뒤에 열린 데이터베이스에 변경 복제 할 필요가있는 정보를 제공합니다. 증분 백업 (마지막 전체 백업 또는 증분 백업 이후에 발생한 모든 변경을 포함)을 만들려고 할 때 FLUSH LOGS 를 사용하여 바이너리 로그를 순환합니다. 이것이 완료되면 마지막 전체 또는 증분 백업의 순간부터 마지막​​ 하나 전 범위의 모든 바이너리 로그를 백업 위치에 복사해야합니다. 이러한 바이너리 로그는 증분 백업 복원시 섹션 7.5 "바이너리 로그를 사용한 시점 (증분) 복구" 에 설명 된대로 그들을 적용합니다. 다음으로 전체 백업을하고자한다면, 역시 FLUSH LOGS , mysqldump --flush-logs, 또는 mysqlhotcopy --flushlog를 사용하여 바이너리 로그를 순환합니다. 섹션 4.5.4 "mysqldump - 데이터베이스 백업 프로그램" 및 섹션 4.6.10 "mysqlhotcopy - 데이터베이스 백업 프로그램" 을 참조하십시오.

리플리케이션을 사용하여 백업 만들기

백업을 만드는 동안 마스터 서버에 성능 문제가있는 경우 유용 할 수있는 하나의 전략은 마스터가 아닌 슬레이브에 복제를 설치하고 백업을 수행하는 것입니다. 섹션 17.3.1 "백업을 위해 복제 사용" 을 참조하십시오.

슬레이브 복제 서버를 백업하는 경우 선택한 백업 방법에 관계없이 슬레이브 데이터베이스를 백업 할 때 그 마스터 정보와 릴레이 로그 정보 저장소를 백업하십시오 ( 섹션 17.2.2 "복제 릴레이 및 상태 로그" 를 참조하십시오). 이러한 정보 파일은 슬레이브의 데이터를 복원 한 후 복제를 다시 시작하기 위해 항상 필요합니다. 슬레이브가 LOAD DATA INFILE 명령문을 복제 할 때 슬레이브가이를 위해 사용하는 디렉토리 내에 존재하는 SQL_LOAD-* 파일도 백업하십시오. 노예 중단 된 LOAD DATA INFILE 조작의 복제를 재개하기 위해이 파일을 필요로합니다. 이 디렉토리의 위치는 --slave-load-tmpdir 옵션의 값입니다. 옵션으로 서버를 시작하지 않은 경우, 디렉토리 위치는 tmpdir 시스템 변수의 값입니다.

손상된 테이블 복구

손상된 MyISAM 테이블을 복원해야하는 경우, 먼저 REPAIR TABLE 또는 myisamchk -r을 사용하여 그 복구를 시도합니다. 그것은 모든 경우의 99.9 %에서 작동하는 것입니다. myisamchk가 실패했을 경우 섹션 7.6 "MyISAM 테이블의 보수와 크래쉬 복구" 를 참조하십시오.

파일 시스템 스냅 샷을 사용하여 백업 만들기

Veritas 파일 시스템을 사용하는 경우 다음과 같이 백업을 만들 수 있습니다.

같은 스냅 샷 기능은 LVM이나 ZFS와 같은 다른 파일 시스템에서도 사용할 수 있습니다.