글 작성 당일에 있었던 따끈따끈한 이슈였다.
기존의 맥북이 맛이 가서 새로운 노트북에 프로젝트 환경을 구성하는 중이었는데(이 글 주제에 국한하면 Local DB) DB migration을 하는 도중 사건이 발생했다.
문제
로컬 환경의 DB에 TypeORM의 migration을 실행 시켰는데 에러가 발생했다.
그래서 아무렇지 않게 생성 된 테이블을 전부 다 밀고 다시 migration을 실행시키려 했다.
근데 개발 환경에서 사용되고 있는 DB의 테이블을 전부 밀어버렸다.
어?
그나마 상용 환경 서버에서 사용되는 DB도 아니었고, 개발단계여서 다행이었다..
일단 급하게 Slack으로 팀원들에게 해당 사항을 알리고 급하게 복구 작업에 착수했다.
RDS Snapshots
AWS RDS에서 이용할 수 있는 기능중에 Snapshot 이라는 기능이 있다.
아래는 AWS Database Blog 글의 번역본이다.
Amazon RDS 스냅샷은 스토리지 볼륨 수준에서 생성되며, Oracle용 RMAN 또는 MySQL 인스턴스용 mysqldump와 같은 기본 엔진 백업 도구와는 독립적입니다.
Amazon RDS 볼륨의 스냅샷은 증분 방식으로 이루어지며, 스냅샷이 실행될 때 백업할 블록은 자동화를 통해 결정됩니다.
각 스냅샷에는 데이터를 새 볼륨으로 복원하는 데 필요한 모든 정보가 포함되어 있습니다.
Amazon RDS 스냅샷은 사용자가 지정한 보존 기간을 위해 안전하고 암호화된 AWS 관리형 Amazon S3(Amazon Simple Storage Service) 버킷에 저장됩니다.
스냅샷별 API 호출을 사용하여 복사 및 복원 작업을 위해 스냅샷에 액세스할 수 있습니다.
원할 때마다 데이터베이스 스냅샷에서 새 인스턴스를 만들 수 있습니다.
데이터베이스 스냅샷은 전체 백업으로 작동하지만 증분 스토리지 사용량에 대해서만 요금이 청구됩니다.
간단하게 특정 시점의 DB instance의 상태를 그대로 저장해 놓은 이미지라고 보면 된다.
또한 해당 이미지를 기반으로 DB instance를 만들어낼 수 있으니 백업, 복원 등의 역할을 할 수 있는 것이다.
그 외에 수동, 자동 생성 방식 Snapshot의 차이나 다중 AZ 이런 더 자세한 내용은 지금 나에겐 필요 없으니 기록하지 않도록 하겠다.
아무튼 나는 매일 1개씩 자동 생성되는 Snapshot이 있었다.
휴..
그럼 이제부터 이제부터 어떻게 복구 했는지 본격적으로 알아보자.
문제 해결
Snapshot 복원
먼저 AWS Console에서 RDS에 들어온다. 그리고 왼쪽의 툴바에서 스냅샷으로 들어간다.
이제 복원하고 싶은 시점의 Snapshot을 클릭해서 작업을 클릭하고, 스냅샷 복원을 클릭하면 된다.
그리고 RDS 생성할 때 처럼 생성할 DB instance의 설정들을 만져주면 해당 스냅샷을 기반으로 한 새로운 DB instance가 생성된다.
mysqldump
이제 스냅샷 복원을 통해 복원된 DB를 dump 할 것이다.
mysqldump -u 유저명 -p DB명 -h RDS엔드포인트 > 덤프파일명.sql
이렇게 하면 해당 DB의 모든 테이블부터 Row까지 dump 할 수가 있다.
파일 내부를 보면 테이블 CREATE 부터 INSERT 문까지 전부 작성되어 있다.
그리고
mysql -u 유저명 -p DB명 -h RDS엔드포인트 < 덤프파일명.sql
로 dump file을 DB에 import 하면 그대로 복사가 된다고 한다!!
이렇게 끝났으면 참 좋았을텐데..
추가적인 작업이 필요했다.
RDS
ERROR 1227 (42000) at line 18: Access denied; you need (at least one of) the SUPER, SYSTEM_VARIABLES_ADMIN or SESSION_VARIABLES_ADMIN privilege(s) for this operation
거의 무조건 해당 에러가 뜰 것이다.
참조 링크를 보거나 나와 함께 따라해보자.
-
dump file을 import 하려는 DB instance가 포함되어 있는 파라미터 그룹에서
log_bin_trust_function_creators파라미터 값을 1(true)로 바꿔준다. -
dump file을 vi/vim 으로 열어서 바로 초입부에 나오는
SET @MYSQLDUMP_TEMP_LOG_BIN = @@SESSION.SQL_LOG_BIN;
SET @@SESSION.SQL_LOG_BIN= 0;
SET @@GLOBAL.GTID_PURGED=/*!80000 '+'*/ '';해당 코드들의 앞에 --를 붙여서 주석처리를 해준다.
그리고 파일의 맨 끝라인쪽에 있는
SET @@SESSION.SQL_LOG_BIN = @MYSQLDUMP_TEMP_LOG_BIN;
해당 라인도 --를 붙여서 주석처리를 해주자.
나의 경우엔 해당 처리까지 다 했을 때 에러없이 dump file을 import 할 수 있었다.
마무리
다행히 table과 row까지 모두 정상적으로 복구할 수 있었고, 경각심을 가지게 되는 계기이자 값진 경험을 할 수 있는 계기도 됐던 것 같다.
