AWS RDS postgres 데이터베이스의 주요 버전을 원활하게 업그레이드하려면 어떻게해야합니까?

오늘 아침 저는 AWS RDS에서 PostgreSQL 데이터베이스를 업그레이드하는 데 참여했습니다. 버전 9.3.3에서 버전 9.4.4로 이동하려고했습니다. 준비 데이터베이스에서 업그레이드를 "테스트"했지만 준비 데이터베이스는 훨씬 작으며 다중 AZ를 사용하지 않습니다. 이 테스트는 꽤 부적절하다는 것이 밝혀졌습니다.

프로덕션 데이터베이스는 다중 AZ를 사용합니다. 우리는 과거에 마이너 버전 업그레이드를 해왔으며,이 경우 RDS는 먼저 스탠바이를 업그레이드 한 다음 마스터로 승격시킵니다. 따라서 장애 발생시 유일하게 가동 중지 시간은 ~ 60 초입니다.

우리는 메이저 버전 업그레이드에서도 같은 일이 일어날 것이라고 생각했지만, 우리가 얼마나 잘못했는지.

설정에 대한 세부 사항 :

• db.m3.large
• 프로비저닝 된 IOPS (SSD)
• 300GB 스토리지 (139GB 사용)
• RDS OS 업그레이드가 탁월했으며 다운 타임을 최소화하기 위해이 업그레이드를 일괄 처리하려고했습니다.

업그레이드를 수행하는 동안 기록 된 RDS 이벤트는 다음과 같습니다.

데이터베이스 CPU는 약 08:44와 10:27 사이에서 최대가되었습니다. 이 시간의 대부분은 RDS가 업그레이드 전 및 업그레이드 후 스냅 샷을 찍는 것으로 보입니다.

AWS의 워드 프로세서 를 읽고 분명히 있지만 우리의 접근에 명백한 결함은 우리가의 사본을 만들지 않은 있다는 것을, 같은 영향에 대해 경고하지 않는 생산 다중 AZ 설정에서 데이터베이스 및로 업그레이드하려고 시운전

RDS가 ​​수행 한 작업과 소요 시간에 대한 정보가 거의 없기 때문에 일반적으로 매우 실망 스러웠습니다. (다시 말해 시범 운영은 도움이 될 것입니다 ...)

그 외에도, 우리는이 사건으로부터 배우고 자하므로 여기에 우리의 질문이 있습니다 :

• RDS에서 메이저 버전 업그레이드를 수행 할 때 이런 종류의 것이 정상입니까?
• 다운 타임을 최소화하면서 향후 주요 버전 업그레이드를 원한다면 어떻게해야할까요? 복제를 사용하여보다 매끄럽게 만드는 영리한 방법이 있습니까?

이것은 좋은 질문이다
클라우드 환경에서 작업하는 까다로운 때때로이다.

pg_dumpall -f dump.sql명령 을 사용 하면 전체 데이터베이스를 SQL 파일 형식으로 덤프하여 다른 엔드 포인트를 가리키는 처음부터 재구성 할 수 있습니다. psql -h endpoint-host.com.br -f dump.sql짧게 사용 합니다.

그러나 그렇게하려면 디스크에 적당한 공간이있는 일부 EC2 인스턴스가 필요합니다 (데이터베이스 덤프에 맞도록). 또한 yum install postgresql94.x86_64덤프 및 복원 명령을 실행할 수 있도록 설치해야 합니다.

PG Dumpall DOC의 예를 참조하십시오 .

데이터의 무결성을 유지하려면이 유지 관리 기간 동안 데이터베이스에 연결하는 시스템을 종료하는 것이 좋습니다 (일부 경우 필수).

또한 속도를 높여야하는 경우 프로세스에 관련된 CPU 수를 결정할 때 병렬 처리 ( ) 매개 변수 를 활용 하여 pg_dump대신을 사용하는 것이 좋습니다 pg_dumpall( -j njobs예 : -j 88 개의 CPU까지 사용). 기본적으로 pg_dumpall또는 동작은 pg_dump1입니다. pg_dump대신 사용 하는 유일한 장점 pg_dumpall은 보유한 각 데이터베이스에 대해 명령을 실행하고 ROLES (그룹 및 사용자)를 분리하여 덤프해야한다는 것입니다.

PG Dump DOC 및 PG Restore DOC의 예를 참조하십시오 .