RDBMS의 백업 및 복구에 대한 연구 - (2) 백업 및 복구 테스트 준비
1. 테스트 후보군
1. MySQL
2. MariaDB
3. PostgreSQL
4. Cubrid
5. Firebird
2. 각 DB는 어떻게 백업 / 복구를 구현했는가?
각 DB의 백업 및 재해 복구(Disaster recovery)를 살펴보자
1) MySQL
MySQL Enterprise 버전에서는 물리적 백업을 지원한다.
물리적 백업은 논리적 백업보다 속도가 빠르다.
내가 사용하는 MySQL은 community edition 이므로, 논리적 백업인 mysqldump가 이용 가능하다.
mysql dump는 database dump의 일종으로서, DB의 전체 구조를 SQL문으로 바꾸어 백업하는 방법이다.
DB 버전 문제에 영향을 받지 않는 장점이 있다.
db dump 참고
innoDB에서 지원하는 백업 방법만 사용할 수 있음에 유의.
MyISAM에서 사용하는 백업 기능은 사용할 수 없다.
바이너리 로그를 이용한 백업, 슬레이브(DB의 복사본)에 백업 등의 방법이 있다.
InnoDB 자체 복구 기능(자동)
InnoDB Crash Recovery
To recover from a MySQL server crash, the only requirement is to restart the MySQL server. InnoDB automatically checks the logs and performs a roll-forward of the database to the present. InnoDB automatically rolls back uncommitted transactions that were present at the time of the crash.
MySQL 서버에 크래시가 생긴 후 다시 실행할 경우
InnoDB에서는 자동으로 로그를 확인하여 복구를 시작한다.
복구 과정에서 커밋되지 않은 트랜잭션들을 롤백시킨다.
InnoDB로부터 강제로 복구를 하도록 시도할 수도 있다.(force recovery mode)
바이너리 로그로부터 복구하기(수동)
MySQL 에서 권장하는 백업 / 복구 전략 권장 사항을 살펴보면 다음과 같다.
1. MySQL server를 --log-bin 옵션과 함께 실행하여, 바이너리 로그가 서버 혹은 다른 외부 저장소에 저장되도록 한다.
2. 주기적으로 mysqldump를 이용해 전체 백업을 실시한다.
3. 주기적으로 로그를 외부 파일로 플러시 하여 백업한다.
현재 관심이 있는 것은 '갑자기' 테이블이 손상됐을 때 어떻게 대응하느냐 하는 것이다.
mysqldump는 수동으로 백업을 해야 하므로, 위 문제에 대해 대처하기 어렵다.
MySQL DB 손상시, 자동 복구로 커버가 안될 때에는 바이너리 로그를 이용해 복구를 해야겠다.
테스트 후보 : 자동 테스트, 바이너리 로그 테스트, 강제 리커버리 모드 테스트
2) MariaDB
MySQL 개발자가 개발한 것이라, MySQL과 방식이 같다고 보면 된다.
물리적 백업 / 논리적 백업을 나누어 수행한다.
테스트 후보 : 자동 테스트, 바이너리 로그 테스트, 강제 리커버리 모드 테스트
3) PostgreSQL
이하 PG라고 언급
3-1) pg dump를 이용한 저장
pg dump는 pg의 dump 프로그램이다.
테이블의 데이터들을 insert 문으로 전환하여 파일로 저장한다.
3-2) DB 파일 백업
디스크에 물리적으로 저장된 DB 파일 자체를 복사하는 방법이다.
3-3) WAL 로그
PG는 WAL(write ahead logging)을 통해 백업 및 복구가 가능하다.
필요하다면 개발자가 원하는 시점으로 복구하는 것 또한 가능하다.(point-in-time recovery,PITR)
DB 충돌로 문제 발생 -> 최근 지점까지 롤 포워드 후, 커밋되지 않은 트랜잭션들 롤백
롤 포워드 : 앞으로 감기. 최근 지점까지 모두 수행
롤백 : 되감기. 롤 포워드 후, 커밋되지 않은 트랜잭션에 대하여 롤백 수행
주의 : 로그 파일 크기가 커질 수 있음(얼마나 커질까? 테스트?)
수동 : pg dump / 파일로부터 복구하기
자동 : WAL 로그로부터 복구하기
테스트 대상 : WAL 로그
4) Cubrid
이제 마이너한 DB일수록 documentation이 적거나 퀄리티가 떨어지는 게 느껴진다...
'백업 자동화' 생각해보기
4-1) 백업
백업 명령어를 이용하여, db를 파일로 백업.
전체 백업 / 증분 백업 등 백업하는 데이터 량에 따라서 구분함(+압축 백업)
논리적 / 물리적 백업을 구별하지 않음(아마 논리적 백업으로 가는듯, 쿼리문으로 구조 저장하기)
4-2) 복구
다음은 큐브리드에서 제시한 백업 및 복구 예시다.
2008/8/14 04:30분에 운영이 중단된 demodb 를 전체 백업을 수행한다.
2008/8/14 10:00분에 운영 중인 demodb 를 1차 증분 백업 수행한다.
2008/8/14 15:00분에 운영 중인 demodb 를 1차 증분 백업을 수행한다. 2번의 1차 증분 백업 파일을 덮어쓴다.
2008/8/14 15:30분에 시스템 장애가 발생하였고, 관리자는 demodb 의 복구 작업을 준비한다. 장애 발생 이전의 마지막 커밋 시점이 15:25분이므로 이를 복구 시점으로 지정한다.
관리자는 1.에서 생성된 전체 백업 파일 및 3.에서 생성된 1차 증분 백업 파일, 활성 로그 및 보관 로그를 준비하여 마지막 커밋 시점인 15:25 시점까지 demodb 를 복구한다.
전체 백업 / 증분 백업을 수행하고, 나머지는 로그로 처리
테스트 대상 : 전체 백업/증분 백업에 대한 복구, 아카이브 로그에 대한 복구 성능
5) Firebird
5-1) 백업
파이어버드에서는 gbak, nbackup 이라는 백업 유틸리티를 이용하여 백업 수행.
gbak는 1.x 버전 이하, nbackup은 2.x 버전에서부터 도입됨.
두 유틸리티는 장단점이 있으므로 취사선택할 것
gbak :
nbackup : 속도가 빠름, 다른 버전 / 기기에서 호환이 안될 수 있음
5-2) 복구
gbak : gfix 라는 복구 툴을 이용해 복구함, (IBSurgeon 이라는 상업용 툴도 있음)
nbackup은 -R 명령어를 추가해 복구 가능. - 백업 / 복구를 한 유틸리티가 담당하는듯.
DB의 백업 / 복구 성능을 어떻게 테스트할 것인가?
얼마나 빠르게 백업/복구?(속도)
얼마나 안정적인 복구가 가능한가?(오류?
얼마나 효율적인 백업이 가능한가?(백업 파일 및 로그 크기)
편의 지원?(자동 백업, 원격 저장 등)
언제 DB 복구를 해야하는가?
DB가 비정상적으로 종료되면 DB 복구를 해야 한다.
검토는 계속된다 ...