Prerequisite

  • 인스턴스 타입 변경 시 다운 타임이 발생하는 것은 불가피합니다.
    따라서 유지보수 시간을 두고 해당 시간대에 시스템 점검을 겸하는 것이 좋습니다.
  • DB 인스턴스 타입 변경에 따른 다운타임에서 가장 큰 차이를 보이는 부분은 Multi-AZ구성 여부입니다.
    Single-AZ 구성일 경우 약 10 ~ 20분 가량의 다운타임이 발생합니다.


Process

※실제 운영중인 DB의 경우 만일의 사태를 대비하여 Snapshot 생성 후 작업 진행을 권장 드립니다.


Instance A : 쓰기 (Writer)

Instance B : 읽기 (Reader)


위와 같이 쓰기/읽기 용 인스턴스를 하나씩 운영 중인 경우, 인스턴스 타입 변경 시 아래와 같이 진행합니다.


1) Instance B (Reader) 의 타입을 변경합니다. 

＊운영중인 환경에서 Reader Endpoint를 사용 중인 서비스에서 Restart에 따른 다운타임이 발생합니다.


2) Fail-over 기능 실행하여 Reader/Writer Instance의 역할을 교체합니다.

* 이 경우 3~5분 가량 서비스 다운타임이 발생합니다.


3) Reader로 변경 된 Instance A의 타입을 변경합니다.

* 운영중인 환경에서 Reader Endpoint를 사용 중인 서비스에서 Restart에 따른 다운타임이 발생합니다.


4) (관리 포인트에 따른 선택 사항) Reader로 전환된 기존 Writer Instance (Instance A) Fail-back

* 기존 Reader 역할의 이스턴스를 Writer로 승격하여 그대로 사용하는 것이 무방하다면 해당 단계는 Skip하셔도 됩니다.

Reader로 전환된 기존 Writer 역할의 인스턴스를 Fail-back 할 경우 다운타임이 발생합니다.



Instance A : 쓰기 (Writer)

Instance B : 읽기 (Reader)
Instance C : 읽기 (Reader)


위와 같이 여러개의 Reader Instance를 사용할 수 있다면, 타입 변경 시 Reader Endpoint에 대한 서비스중단 없이 타입 변경 작업을 진행하실 수 있습니다.


Reference