feat(rds): support rolling instance updates to reduce downtime

[spanierm42]

Support defining the instance update behaviour of RDS instances. This allows to switch between bulk (all instances at once) and rolling updates (one instance after another). While bulk updates are faster, they have a higher risk for longer downtimes as all instances might be simultaneously unreachable due to the update. Rolling updates take longer but ensure that all but one instance are not updated and thus downtimes are limited to the (at most two) changes of the primary instance.

We keep the current behaviour, namely a bulk update, as default.

This implementation follows proposal A by @hixi-hyi in issue #10595.

Fixes #10595

[gitpod-io]

[TheRealAmazonKendra]

Thank you for this change. For the most part it looks great, just a couple things before we can approve it. We need to have a README update for this new functionality and we also need an integration test.

Additionally, I'm wondering if there's a use case for allowing the rolling update to be more configurable rather than just one at a time. Thoughts on that?

[spanierm42]

@TheRealAmazonKendra Thanks for the feedback. I indeed forgot to add both a documentation and an integration test.

Concerning more flexible update behaviors: I generally like the idea to add more flexibility. But I think we only have limited options in this case as RDS/Aurora does not support more sophisticated update behaviors as, for instance. E.g., I cannot state that at least "2 instances need to be running" or "at most 3 instances at a time can be updated". Thus, I think the option to choose an enum reflecting the most important options, BULK and ROLLING are a good start and easy to understand.
We might add something like BLUE_GREEN making sure that at most half of the instances are updated at a time thus further reducing the time to update while still making sure not all instances are getting updated. Or KEEP_AT_LEAST_TWO_INSTANCES making sure that at least two instances are always up and running while all others can be updated in a batch.
But as we lack support from CloudFormation for more sophisticated options, I would keep it simple and use enums here.

[TheRealAmazonKendra]

@spanierm42 Sounds good. If you can just add in the tests and documentation I'll be more than happy to approve and merge this.

Pull request has been modified.

[spanierm42]

@TheRealAmazonKendra I added the missing documentation and integration test. Let me know if that fits your needs. Looking forward to hearing from you :)

[TheRealAmazonKendra]

Thank you for this contribution and for your edits on this! I hope you don't mind that I updated the README a bit.

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
• Commit ID: 3d38e60
• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[spanierm42]

@TheRealAmazonKendra Thanks for all your guidance and feedback. I highly appreciate your change in the README.md as I learned from that you prefer concise documentation and technical details (here, the dependencies between the instances, which I wanted to hide as implementation detail in the text).