Thời gian chết để tăng lưu trữ AWS RDS?

Tôi đang tìm cách tăng dung lượng lưu trữ của hai phiên bản RDS (chỉ không gian lưu trữ được phân bổ, không phải loại thể hiện hoặc các tham số khác). Tài liệu tại https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIOPS.StorageTypes.html#USER_PIOPS.ModifyingEx hiện gợi ý:

Bạn có thể thay đổi từ lưu trữ tiêu chuẩn sang lưu trữ IOPS được cấp phép hoặc từ IOPS được cấp phép sang lưu trữ tiêu chuẩn, cũng như tăng dung lượng lưu trữ, với ít hoặc không có thời gian chết.

Tôi chắc chắn sẽ lên lịch một cửa sổ bảo trì trước khi thực hiện thay đổi. Nhưng tài liệu có vẻ hơi mơ hồ trong lĩnh vực này. Đối với một người có thể đã làm điều này trước đây, "ít hoặc không có thời gian chết" là gì? Tôi có thể mong đợi 5 giây hay giống như 5 phút hơn?

Cập nhật tháng 7 năm 2019:

Tôi đã cập nhật liên kết đến tài liệu AWS chính xác và cập nhật (đã bị hỏng). Các tài liệu mới hơn có một lời giới thiệu cũng giúp trả lời câu hỏi ban đầu:

Trong hầu hết các trường hợp, lưu trữ mở rộng không yêu cầu ngừng hoạt động và không làm giảm hiệu suất của máy chủ. Sau khi bạn sửa đổi kích thước lưu trữ cho một phiên bản DB, trạng thái của phiên bản DB là Tối ưu hóa lưu trữ. Phiên bản DB hoàn toàn hoạt động sau khi sửa đổi lưu trữ. Tuy nhiên, bạn không thể thực hiện các sửa đổi lưu trữ tiếp theo trong sáu giờ hoặc trong khi trạng thái đối tượng DB là tối ưu hóa lưu trữ, tùy theo thời gian nào dài hơn.

Tuy nhiên, trường hợp đặc biệt là nếu bạn có phiên bản SQL Server DB và không sửa đổi cấu hình lưu trữ kể từ tháng 11 năm 2017. Trong trường hợp này, bạn có thể gặp sự cố ngừng hoạt động trong vài phút khi bạn sửa đổi phiên bản DB của mình để tăng phân bổ lưu trữ. Sau khi ngừng hoạt động, phiên bản DB trực tuyến nhưng ở trạng thái Tối ưu hóa lưu trữ. Hiệu suất có thể bị suy giảm trong quá trình tối ưu hóa lưu trữ.

Đầu tiên, lưu ý rằng bạn có thể đang xem xét thao tác không chính xác - bạn mô tả rằng bạn muốn thay đổi kích thước lưu trữ , nhưng đã trích dẫn tài liệu mô tả loại lưu trữ . Đây là một sự phân biệt quan trọng: RDS khuyên rằng bạn sẽ không gặp phải sự cố ngừng hoạt động để thay đổi kích thước lưu trữ, nhưng bạn sẽ gặp sự cố ngừng hoạt động để thay đổi loại lưu trữ.

Mong đợi hiệu suất xuống cấp để thay đổi kích thước lưu trữ, thời lượng và tác động của nó sẽ phụ thuộc vào một số yếu tố:

• Loại đối tượng RDS của bạn
• Cấu hình
  • Điều này sẽ xảy ra trong quá trình bảo trì?
  • Những thay đổi này sẽ xảy ra đầu tiên trên nô lệ Multi-AZ của bạn, và sau đó chuyển đổi dự phòng?
• Kích thước cơ sở dữ liệu hiện tại
• Kích thước cơ sở dữ liệu ứng viên
• Khả năng AWS để xử lý yêu cầu này vào thời gian bạn yêu cầu trong ngày, tại khu vực sẵn có được yêu cầu của bạn, trong khu vực bạn yêu cầu
• Loại động cơ (đối với người dùng Amazon Aurora , việc bổ sung lưu trữ được quản lý bởi RDS khi cần theo mức tăng 10 GB, vì vậy cuộc thảo luận này là tranh luận)

Với suy nghĩ này, bạn sẽ được phục vụ tốt hơn bằng cách tự kiểm tra điều này, trong môi trường của bạn và về các điều khoản của bạn. Hãy thử trải nghiệm với những điều sau đây:

• Khôi phục một cá thể RDS mới từ một ảnh chụp nhanh của cá thể hiện tại của bạn và thực hiện thao tác này trên bản sao mới.
• Với bản sao này:
  • Tăng kích thước vào các thời điểm khác nhau trong ngày, khi bạn mong đợi một tải khác nhau trên AWS.
  • Tăng kích thước khác nhau.
  • Hãy thử nó với đa AZ. Xem nếu thời gian chết thực sự của bạn thay đổi so với việc không kích hoạt đa AZ.
  • Hãy thử nó trong một cửa sổ bảo trì và so sánh nó với việc áp dụng thay đổi ngay lập tức.

Điều này sẽ tốn kém hơn một chút (không cần phải ... bạn có thể làm hầu hết thời gian đó trong 1-3 giờ), nhưng bạn sẽ nhận được câu trả lời rõ ràng hơn nhiều so với việc bán hàng cho những trải nghiệm của chúng tôi trong vô số RDS khác nhau môi trường.

Nếu bạn vẫn đang tìm kiếm câu trả lời "sân bóng", tôi khuyên bạn nên lập kế hoạch cho sự suy giảm hiệu suất ít nhất trong phạm vi phút, chứ không phải vài giây - một lần nữa phụ thuộc rất nhiều vào môi trường và cấu hình của bạn.

Để tham khảo, gần đây nhất tôi đã áp dụng thao tác chính xác này để thêm 10GB vào thể hiện loại db.m1.small 40GB vào chiều thứ bảy (tính theo EST). Ví dụ vẫn ở trạng thái "sửa đổi" trong khoảng 17 phút. Lưu ý rằng trạng thái sửa đổi không mô tả thời gian chết thực sự, mà là thời lượng mà hoạt động đang được áp dụng . Bạn sẽ không thể áp dụng các thay đổi bổ sung cho thể hiện thực tế (mặc dù bạn vẫn có thể truy cập vào chính DB) và đây cũng là khoảng thời gian mà bạn có thể mong đợi bất kỳ sự suy giảm hiệu suất nào xảy ra.

Nếu bạn chỉ có kế hoạch thay đổi kích thước lưu trữ thì việc ngừng hoạt động là bất ngờ, nhưng lưu ý rằng điều đó có thể xảy ra nếu thay đổi này được thực hiện cùng với các hoạt động khác như thay đổi định danh / lớp hoặc loại lưu trữ.

Vì bạn chỉ tăng kích thước lưu trữ và không thay đổi loại thể hiện hoặc bất cứ điều gì khác nên không có bất kỳ thời gian chết nào, nhưng có thể có "hiệu suất bị suy giảm" trong khi hoạt động được thực hiện.

Tài liệu tham khảo mà bạn trích dẫn không rõ ràng vì nó thảo luận về việc thay đổi loại lưu trữ cùng lúc với việc thảo luận về việc thay đổi kích thước lưu trữ. Thay vào đó, nếu bạn nhìn vào 'Bộ nhớ được phân bổ' trong bảng ở đây:

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

bạn sẽ thấy rằng nó chỉ nói "Hiệu suất có thể bị suy giảm" và không có gì về việc ngừng hoạt động (điều này nói rằng xảy ra trong một số trường hợp khi chuyển loại lưu trữ).

Để tham khảo, khi thay đổi cơ sở dữ liệu MySQL db.m3.medium 15GB thành 20GB trong eu-west-1 trong ngày làm việc, khả năng kết nối với cơ sở dữ liệu của ứng dụng của tôi không bị gián đoạn. Tuy nhiên, cả IOPS đọc / ghi đều tăng lên từ 400-700 / giây chỉ dưới 20 phút, do đó, các tham chiếu đến hiệu suất bị suy giảm mà tôi cho là. Điều này đã được báo cáo cho cả trường hợp cơ sở dữ liệu AZ đơn và đa AZ. (Trường hợp được báo cáo là 'sửa đổi' lâu hơn một chút so với điều này - khoảng 25 phút.)

Đương nhiên, bạn có thể dùng thử trên một cá thể db giống hệt với db sản xuất của bạn trước khi thực hiện nó trên cá thể db sản xuất của bạn để bạn có thể thấy nó hoạt động như thế nào trong tình huống của bạn trước khi thực hiện nó.