AWS RDS 스토리지를 늘리기위한 다운 타임?

두 개의 RDS 인스턴스 (인스턴스 유형 또는 기타 매개 변수가 아닌 할당 된 스토리지 공간)의 스토리지를 늘리려 고합니다. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIOPS.StorageTypes.html#USER_PIOPS.ModifyingExisting 의 설명서 는 다음을 제안합니다.

다운 타임이 거의없이 표준 스토리지에서 프로비저닝 된 IOPS 스토리지로 또는 프로비저닝 된 IOPS에서 표준 스토리지로 변경하고 스토리지를 늘릴 수 있습니다.

변경을 수행하기 전에 유지 관리 기간을 확실히 예약합니다. 그러나이 영역에서는 문서가 약간 모호한 것 같습니다. 이전에이 작업을 수행 한 적이있는 사람에게는 "다운 타임이 거의 없거나 전혀없는"것이 무엇입니까? 5 초를 기대할 수 있습니까 아니면 5 분과 더 비슷합니까?

2019 년 7 월 업데이트 :

올 바르고 업데이트 된 AWS 설명서 (손상됨)에 대한 링크를 업데이트했습니다. 최신 문서에는 원래 질문에 대한 답변을 제공하는 흐림 기능이 있습니다.

대부분의 경우 스토리지 확장에는 중단이 필요하지 않으며 서버 성능이 저하되지 않습니다. DB 인스턴스의 스토리지 크기를 수정 한 후 DB 인스턴스의 상태는 스토리지 최적화입니다. 스토리지 수정 후 DB 인스턴스가 완전히 작동합니다. 그러나 6 시간 동안 또는 DB 인스턴스 상태가 스토리지 최적화 중 더 긴 스토리지 스토리지를 더 이상 수정할 수 없습니다.

그러나 특별한 경우는 SQL Server DB 인스턴스가 있고 2017 년 11 월 이후 스토리지 구성을 수정하지 않은 경우입니다.이 경우 DB 인스턴스를 수정하여 할당량을 늘리면 몇 분의 짧은 정전이 발생할 수 있습니다 저장. 중단 후 DB 인스턴스는 온라인 상태이지만 스토리지 최적화 상태입니다. 스토리지 최적화 중에 성능이 저하 될 수 있습니다.

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

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

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

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

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

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

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

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

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

스토리지 크기 만 늘리고 인스턴스 유형 등을 변경하지 않기 때문에 가동 중지 시간은 없어야하지만 작업 수행 중에 '성능 저하'가 발생할 수 있습니다.

인용 한 참조는 스토리지 크기 변경과 동시에 스토리지 유형 변경에 대해 논의하기 때문에 모호합니다. 대신 아래 표에서 '할당 된 스토리지'를 확인하십시오.

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.Modifying.html

"성능이 저하 될 수 있습니다"라는 메시지 만 표시되고 중단 (스토리지 유형을 전환 할 때 발생하는 경우)에 대해서는 아무 것도 표시되지 않습니다.

참고로 작업 일 동안 15GB db.m3.medium MySQL 데이터베이스를 eu-west-1에서 20GB로 변경하면 내 앱의 데이터베이스 연결이 중단되지 않았습니다. 그러나 읽기 / 쓰기 IOPS는 모두 20 분 미만 동안 400-700 / s로 증가했기 때문에 성능 저하에 대한 참조가 생각됩니다. 단일 AZ 및 다중 AZ 데이터베이스 인스턴스 모두에 대해보고되었습니다. (인스턴스가 이보다 조금 더 길어 약 25 분 동안 '수정 중'으로보고되었습니다.)

당연히 프로덕션 DB 인스턴스에서 수행하기 전에 프로덕션 DB와 동일한 DB 인스턴스에서 시도해 볼 수 있으므로 실제로 수행하기 전에 상황에서 어떻게 작동하는지 안전하게 확인할 수 있습니다.