Description
Describe the issue
The props instances
and instanceProps
for rds.DatabaseCluster
are deprecated in favour of writer
and readers
.
What is the behaviour of these when the Aurora cluster fails over? If I create a reader, can it become promoted to a writer, or will it always be a reader?
Relevant Aurora docs: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.AuroraHighAvailability.html#Concepts.AuroraHighAvailability.Instances
When a problem affects the primary instance, one of these reader instances takes over as the primary instance. This mechanism is known as failover.
Further, assuming they do all just become instances in the cluster, any of which might get promoted to be the writer, what happens on future CDK deployments? I can imagine a situation where I think I'm changing something about the readers, but am actually changing something about all-but-one of the readers and the writer, because:
- the instance CDK thinks of as the writer is now a reader
- the instance that is actually the writer is one of the instances the CDK thinks of as readers
I don't see any discussion around this in #25437, the PR that introduced this.
I might just be missing something, but the structure of this seems at odds with how an Aurora cluster actually behaves.
Links
CDK docs:
- https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_rds.DatabaseCluster.html#writer
- https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_rds.DatabaseCluster.html#readers
- https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_rds-readme.html
Aurora failover docs: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.AuroraHighAvailability.html#Concepts.AuroraHighAvailability.Instances