소개

RDB를 사용한 신규 안건이 발생해, 배치 운용이 메인이 되어 오는 시스템이었기 때문에,
스몰 스타트에서 운용하기에는 비용이 저렴하고, 스케일하기 쉽다고 하는 것으로
Amazon Aurora(Postgres)를 사용하게 되었다.

자동으로 백업을 해주는 것으로부터, 복원도 안이하게 할 수 있는 분위기가 있었지만
실제 곳은 어떤지 조사했다.

두 가지 유형의 복원 방법

복원 방법은 2종류이며, 어느 복원의 방법도 디폴트로 7일간, 최대 35일분의 데이터를 보존할 수 있다

스냅샷으로 복원
스냅샷 목록에서 선택하여 복원이 가능하며,
백업은 하루에 한 번 자동으로 수행됩니다

특정 시점으로 복원
콘솔 오른쪽 상단의 액션에서 특정 시점으로 복원을 선택하면 실행할 수 있습니다.
이곳은 임의의 시점의 데이터로 복원할 수 있다.

관계 담보

「특정 시점으로의 복원」에서는 DB간 무결성을 담보할 수 없다고 써 있다.
(즉, 복원 전후에 액세스가 있으면 관계가 무너질 수 있습니다)

스냅샷에는 그 취지의 기재가 없었다
(현재 시스템을 움직이지 않는 타이밍에서 정확하게 스냅 샷이 실시되고 있으며,
콜드 백업이 있는지 확인할 수 없습니다.

장애 발생 → 복원을 실행하고 나중에는 방치가 되지 않는다

이것이 중요하지만 현재 실행중인 복원 소스 DB 식별자는 복원 대상으로 선택할 수 없습니다.
(생각해 보면 그렇다고 된 부분이지만,
당초 할 수 있다고 생각했기 때문에이 기사를 쓰고 있습니다)



(Aurora 복원 화면. DB 클러스터 식별자를 동일하게 해도 런타임 오류가 발생함)

즉...

↑ 이런 일을 할 수 없다. 아마도 가동중인 DB를 실수로 데이터를 지우지 않도록 하는 조치라고 생각합니다. 이런 상황은 피해야합니다.

이번에 검토 한 제안

이번에는 안을 2개 내고, 그 안의 안 2를 채용했습니다.

방안 1 : 새롭게 프로덕션 DB 만들기

복원한 DB를 새로운 프로덕션 DB로 하고, 복원원과 정확히 같은 설정으로 완성해, DB 접속처 설정을 새로운 프로덕션 DB로 향한다 익숙해지면 문제 없을 것입니다 만, 장애 발생시 설정 항목을 조사하는 것은 어렵습니다. DB 식별자도 바뀐다 이미 대량의 데이터를 가지고 있는 경우에는 후술하는 순서에 비하면 복원 순서에 걸리는 비용은 적다

방안 2 : 복원용의 DB를 작성해, postgres의 덤프 기능으로부터 복원을 실시한다

복원 된 DB를 복구 용 DB로 설정하고 Postgres 명령으로 DB 백업을 얻고이를 프로덕터로 복원합니다.

손을 넣는 프로덕션 시스템이 DB뿐이므로 실수의 적층이 일어나기 어렵다

절차가 일정화되기 쉬운

Postgres에 의한 DB 흡출을 수행하는 데 시간이 걸린다. 복구 중에 데이터가 부풀어 오른다.

참고 URL:
- htps : // / cs. 아 ws. 아마존. 이 m / 그럼 _ jp / 아마 존 RDS / 아 st / 우세 r 구이로 / 우세 R_를 r 쿵 쾅 버려서 d 바 c ps. HTML
- htps : // / cs. 아 ws. 아마존. 코 m / 그럼 _ jp / 아마 웬 RDS / 아 st / 우세 r 구이 데 / 우세 R_ 피 T. HTML