먼저, 잘못된 작업을보고있을 수 있습니다. 스토리지 크기 를 변경하고 싶지만 스토리지 유형을 설명하는 문서를 인용했습니다 . RDS는 스토리지 크기 변경으로 인한 중단이 발생하지 않지만 스토리지 유형 변경으로 인한 중단이 발생할 것을 권장합니다.

스토리지 크기 변경에 따른 성능 저하 예상

• RDS 인스턴스 유형
• 구성
  • 유지 관리 중에이 문제가 발생합니까?
  • 이러한 변경 사항이 다중 AZ 슬레이브에서 먼저 발생한 다음 장애 조치됩니까?
• 현재 데이터베이스 크기
• 후보 데이터베이스 크기
• 요청한 시간, 요청 된 가용 영역, 요청 된 리전에서이 요청을 처리 할 수있는 AWS 용량
• 엔진 유형 ( Amazon Aurora 사용자의 경우 스토리지 추가는 10GB 단위로 필요에 따라 RDS에서 관리하므로이 논의는 무의미합니다)

이 점을 염두에두고 직접, 환경 및 용어를 테스트하여 더 나은 서비스를 받으십시오. 다음을 실험 해보십시오.

• 기존 인스턴스의 스냅 샷에서 새 RDS 인스턴스를 복원하고 새 클론에서이 작업을 수행합니다.
• 이 클론으로 :
  • AWS에 다른로드를 기대할 수있는 다른 시간대에 크기를 늘리십시오.
  • 다른 크기로 늘리십시오.
  • 다중 AZ로 사용해보십시오. 다중 AZ를 사용하지 않는 것과 비교하여 실제 가동 중지 시간이 변경되는지 확인하십시오.
  • 유지 관리 기간 동안 사용해보고 변경 사항을 즉시 적용하는 것과 비교하십시오.

이것은 조금 더 비쌀 것입니다 (필요하지는 않지만 … 1-3 시간 안에 그 대부분을 할 수 있습니다), 무수한 다른 RDS에서의 경험을 고려하는 것보다 훨씬 깨끗한 대답을 얻을 것입니다 환경.

여전히 “ballpark”답변을 찾고 있다면 최소한 몇 초가 아닌 몇 분 안에 성능 저하를 계획하는 것이 좋습니다. 이는 다시 환경과 구성에 크게 좌우됩니다.

참고로 가장 최근에는 토요일 오후 (EST)에 40GB db.m1.small 유형 인스턴스에 10GB를 추가하기 위해이 정확한 작업을 적용했습니다. 인스턴스는 약 17 분 동안 “수정 중”상태로 유지되었습니다. 수정 상태는 실제 가동 중지 시간이 아니라 작업이 적용되는 기간을 나타 냅니다. 실제 인스턴스에 추가 변경 사항을 적용 할 수는 없지만 (아직 DB 자체에 액세스 할 수는 있지만) 성능 저하가 발생할 것으로 예상되는 기간이기도합니다.

스토리지 크기 만 변경하려는 경우에는 예상치 못한 중단이 발생하지만이 변경이 인스턴스 식별자 / 클래스 또는 스토리지 유형 변경과 같은 다른 작업 과 함께 수행 되는 경우 발생할 수 있습니다 .

답변