7.3.1 백업 정책 수립

유용하게 백업은 정기적으로 예약해야합니다. 전체 백업 (특정 시점의 데이터 스냅 샷)은 MySQL에서 몇 가지 도구를 사용하여 실행할 수 있습니다. 예를 들어, MySQL Enterprise Backup 은 InnoDB 데이터 파일을 백업 할 때 오버 헤드를 최소화하고 중단을 방지 최적화를 수반 인스턴스 전체의 물리적 백업 을 실행할 수 있습니다. mysqldump는 온라인 논리 백업 을 제공합니다. 이 설명에서는 mysqldump를 사용합니다.

부하가 적은 일요일 오후 1시에 다음의 명령을 사용하여 모든 데이터베이스의 모든 InnoDB 테이블의 전체 백업을 만들려고합니다.

 shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql

mysqldump에 의해 생성 된 결과 .sql 파일에는 나중에 덤프 된 테이블을 다시 읽어 사용할 수있는 SQL INSERT 문 세트가 포함되어 있습니다.

이 백업 작업은 덤프의 처음에서 모든 테이블에 대한 글로벌 읽기 잠금을 획득합니다 ( FLUSH TABLES WITH READ LOCK 을 사용하여). 이 락이 취득되면 즉시 바이너리 로그의 좌표를 읽어 잠금이 해제됩니다. FLUSH 문이 실행 된 때 긴 업데이트 명령문이 실행중인 경우 백업 작업은 그 문이 끝날 때까지 정지 될 수 있습니다. 그 후 덤프는 락 프리입니다 테이블의 읽기 및 쓰기를 방해하지 않습니다.

먼저 백업 할 테이블은 InnoDB 테이블이라고했기 때문에, --single-transaction 은 일관성 독해를 사용하고 mysqldump에 의해 표시되는 데이터가 변경되지 않도록합니다. (다른 클라이언트에 의한 InnoDB 테이블의 변경은 mysqldump 프로세스가 표시되지 않습니다.) 백업 작업에 비 트랜잭션 테이블이 포함 된 경우 일관성 백업 중에 그들이 변경되지 않아야합니다. 예를 들어, mysql 데이터베이스의 MyISAM 테이블의 경우 백업하는 동안 MySQL 계정에 관리 변경 사항이 있어서는 안됩니다.

전체 백업이 필요하지만, 그들을 만들기 위해 항상 형편이 좋은 것은 없습니다. 그들은 큰 백업 파일을 생성하고 생성에 시간이 걸립니다. 그들은 연속적인 각 전체 백업에 마지막 전체 백업 이후 변경되지 않은 부분에서도 모든 데이터가 포함된다는 점에서 최적이 없습니다. 초기 전체 백업을 만든 다음 증분 백업을 생성하는 것이 효율적입니다. 증분 백업은 작고, 생성 시간이 줄어 듭니다. 이 트레이드 오프는 복구시 전체 백업을 다시로드하는 것만으로는 데이터를 복원 할 수없는 것입니다. 증분 백업을 처리하여 증분 변경도 복구해야합니다.

증분 백업을 만들려면 증분 변경 내용을 저장해야합니다. MySQL에서는 이러한 변화는 바이너리 로그에 표시되기 때문에 MySQL 서버를 항상 --log-bin 옵션으로 시작하여 로그를 사용하십시오. 바이너리 로깅이 활성화되어 있으면 서버는 데이터를 업데이트하는 동안 각 데이터의 변경을 파일에 기록합니다. --log-bin 옵션으로 시작하고 며칠 동안 실행했던 MySQL 서버의 데이터 디렉토리를 살펴보면 이러한 MySQL 바이너리 로그 파일을 찾을 수 있습니다.

 -rw-rw ---- 1 guilhem guilhem 1277324 Nov 10 23:59 gbichot2-bin.000001
 -rw-rw ---- 1 guilhem guilhem 4 Nov 10 23:59 gbichot2-bin.000002
 -rw-rw ---- 1 guilhem guilhem 79 Nov 11 11:06 gbichot2-bin.000003
 -rw-rw ---- 1 guilhem guilhem 508 Nov 11 11:08 gbichot2-bin.000004
 -rw-rw ---- 1 guilhem guilhem 220047446 Nov 12 16:47 gbichot2-bin.000005
 -rw-rw ---- 1 guilhem guilhem 998412 Nov 14 10:08 gbichot2-bin.000006
 -rw-rw ---- 1 guilhem guilhem 361 Nov 14 10:07 gbichot2-bin.index

MySQL 서버는 다시 시작할 때마다 시퀀스의 다음 번호를 사용하여 새로운 바이너리 로그 파일을 만듭니다. 서버가 실행중인 동안 FLUSH LOGS SQL 명령문을 실행하거나 mysqladmin flush-logs 명령에 의해 수동으로 거기에 현재의 바이너리 로그 파일을 닫고 새 파일을 시작하도록 말할 수 있습니다. mysqldump에는 로그를 플러시하는 옵션도 있습니다. 데이터 디렉토리에있는 .index 파일에는 디렉토리의 모든 MySQL 바이너리 로그의 목록이 포함됩니다.

MySQL 바이너리 로그는 증분 백업 세트를 형성하기 위해 복구에 중요합니다. 전체 백업을 만들 때 로그를 플러시 할 경우 다음 생성되는 바이너리 로그 파일은 백업 이후에 변경된 모든 데이터 변경 사항이 포함됩니다. 여기에 위의 mysqldump 명령을 약간 수정하여 전체 백업의 시점에서 MySQL 바이너리 로그를 플러시하도록 덤프 파일에 새로운 현재 바이너리 로그의 이름이 포함되도록합니다.

 shell> mysqldump --single-transaction --flush-logs --master-data=2 \
         
--all-databases > backup_sunday_1_PM.sql 

이 명령을 실행 한 후 --flush-logs 옵션으로 서버에 로그를 플래시시키기 위해, 데이터 디렉토리는 새로운 바이너리 로그 파일 gbichot2-bin.000007 가 포함됩니다. --master-data 옵션은 mysqldump로 출력 바이너리 로그 정보를 기록하기 위해 결과 .sql 덤프 파일에는 이러한 행이 포함됩니다.

 - Position to start replication or point-in-time recovery from
 - CHANGE MASTER TO MASTER_LOG_FILE = 'gbichot2-bin.000007', MASTER_LOG_POS = 4;

mysqldump 명령으로 전체 백업을하고 있기 때문에 이러한 행은 두 가지를 의미합니다.

월요일 오후 1시 로그를 플러시하고 새로운 바이너리 로그 파일을 시작하여 증분 백업을 만들 수 있습니다. 예를 들어, mysqladmin flush-logs 명령어를 실행하면 gbichot2-bin.000008 가 생성됩니다. 일요일 오후 1시 전체 백업 이후 월요일 오후 1 시까 지 모든 변경 사항은 gbichot2-bin.000007 파일에 있습니다. 이 증분 백업은 중요하기 때문에 그것을 안전한 장소에 복사하는 것이 좋습니다. (예를 들어, 테이프 나 DVD에 백업하거나 다른 컴퓨터에 복사합니다.) 화요일 오후 1시 더욱 mysqladmin flush-logs 명령을 실행합니다. 월요일 오후 1 시부 터 화요일 오후 1 시까 지 모든 변경이 gbichot2-bin.000008 파일에 있습니다 (이것도 어딘가 안전한 장소에 복사해야합니다).

MySQL 바이너리 로그는 디스크 공간을 차지합니다. 공간을 확보하기 위해 때때로 그들을 제거합니다. 이것을 실행하는 하나의 방법은 전체 백업을 만들 때 등 필요 없게 된 바이너리 로그를 삭제하는 것입니다.

 shell> mysqldump --single-transaction --flush-logs --master-data=2 \
         
--all-databases --delete-master-logs > backup_sunday_1_PM.sql