9.3.1 Establishing a Backup Policy

9.3.1 백업 정책 수립하기

유용한 백업이 되려면 정기적으로 스케줄링해야 합니다. 전체 백업 (어느 한 시점의 데이터 스냅샷)은 MySQL에서 여러 도구를 사용하여 수행할 수 있습니다. 예를 들어,
MySQL Enterprise Backup은 전체 인스턴스에 대해
physical backup을 수행할 수 있으며,
InnoDB 데이터 파일을 백업할 때 오버헤드를 최소화하고 중단을 피하기 위한 최적화를 제공합니다;
mysqldump는 온라인
logical backup을 제공합니다.
이 설명에서는 mysqldump를 사용합니다.

다음과 같이, 부하가 낮은 일요일 오후 1시에 모든 데이터베이스의 모든 InnoDB 테이블에 대해 전체 백업을 수행한다고 가정합니다:

1$> mysqldump --all-databases --source-data --single-transaction > 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 옵션을 사용하여 시작해야 합니다.
바이너리 로깅이 활성화되면, 서버는 데이터를 변경할 때마다 해당 변경 내용을 파일에 기록합니다. 며칠 동안 실행 중이었던 MySQL 서버의 데이터 디렉터리를 보면, 다음과 같은 MySQL 바이너리 로그 파일이 있습니다:

1-rw-rw---- 1 guilhem  guilhem   1277324 Nov 10 23:59 gbichot2-bin.000001
2-rw-rw---- 1 guilhem  guilhem         4 Nov 10 23:59 gbichot2-bin.000002
3-rw-rw---- 1 guilhem  guilhem        79 Nov 11 11:06 gbichot2-bin.000003
4-rw-rw---- 1 guilhem  guilhem       508 Nov 11 11:08 gbichot2-bin.000004
5-rw-rw---- 1 guilhem  guilhem 220047446 Nov 12 16:47 gbichot2-bin.000005
6-rw-rw---- 1 guilhem  guilhem    998412 Nov 14 10:08 gbichot2-bin.000006
7-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 바이너리 로그를 플러시하고 덤프 파일에 새로운 현재 바이너리 로그의 이름을 포함하도록 해 보겠습니다:

1$> mysqldump --single-transaction --flush-logs --source-data=2 \
2         --all-databases > backup_sunday_1_PM.sql

이 명령을 실행한 후에는 --flush-logs 옵션 때문에 서버가 로그를 플러시하므로 데이터 디렉터리에 새로운 바이너리 로그 파일 gbichot2-bin.000007이 생성됩니다.
--source-data 옵션은 mysqldump가 바이너리 로그 정보를 출력에 기록하도록 하므로, 생성된 .sql 덤프 파일에는 다음과 같은 줄이 포함됩니다:

1-- Position to start replication or point-in-time recovery from
2-- CHANGE REPLICATION SOURCE TO SOURCE_LOG_FILE='gbichot2-bin.000007',SOURCE_LOG_POS=4;

mysqldump 명령이 전체 백업을 수행하였으므로, 이 줄은 두 가지를 의미합니다:

• 덤프 파일에는 gbichot2-bin.000007 바이너리 로그 파일 또는 그 이후 파일에 기록된 변경 사항이 작성되기 전까지의 모든 변경 내용이 포함되어 있습니다.

• 백업 이후에 로그에 기록된 모든 데이터 변경 사항은 덤프 파일에는 없지만, gbichot2-bin.000007 바이너리 로그 파일 또는 그 이후 파일에는 포함되어 있습니다.

월요일 오후 1시에, 로그를 플러시하여 새로운 바이너리 로그 파일을 시작함으로써 증분 백업을 생성할 수 있습니다. 예를 들어,
mysqladmin flush-logs 명령을 실행하면 gbichot2-bin.000008이 생성됩니다.
일요일 오후 1시의 전체 백업과 월요일 오후 1시 사이의 모든 변경 사항은 gbichot2-bin.000007에 기록됩니다. 이 증분 백업은 중요하므로 안전한 위치에 복사해 두는 것이 좋습니다.
(예를 들어, 테이프 또는 DVD에 백업하거나 다른 머신으로 복사합니다.) 화요일 오후 1시에 또 다른
mysqladmin flush-logs 명령을 실행합니다.
월요일 오후 1시부터 화요일 오후 1시까지의 모든 변경 사항은 gbichot2-bin.000008에 기록되며 (이 역시 안전한 곳에 복사해 두어야 합니다).

MySQL 바이너리 로그는 디스크 공간을 차지합니다. 공간을 확보하려면 정기적으로 로그를 삭제(purge)해야 합니다. 한 가지 방법은 전체 백업을 수행할 때처럼 더 이상 필요하지 않은 바이너리 로그를 삭제하는 것입니다:

1$> mysqldump --single-transaction --flush-logs --source-data=2 \
2         --all-databases --delete-source-logs > backup_sunday_1_PM.sql

참고

mysqldump의
--delete-source-logs를 사용하여 MySQL 바이너리 로그를 삭제하는 것은 서버가 복제 소스 서버인 경우 위험할 수 있습니다. 레플리카가 아직 바이너리 로그의 내용을 완전히 처리하지 못했을 수 있기 때문입니다.
MySQL 바이너리 로그를 삭제하기 전에 무엇을 확인해야 하는지에 대해서는 PURGE BINARY LOGS 구문에 대한 설명에 나와 있습니다.
Section 15.4.1.1, “PURGE BINARY LOGS Statement”를 참조하십시오.