aws-rds: deprecate writer and readers props for DatabaseCluster

[plumdog]

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

[pahud]

Thanks for the callout. When you delete a writer from the console, the reader will immediately promoted as the new writer and if you go to cloudformation to "detect drfit", the stack will be in DRIFTED status because the writer has been deleted.

Unfortunately we didn't address the recommended practice how to update the existing cdk stack in this scenario given the writer is deleted and reader promoted as writer. I will explore this a little bit further and see if I can find anything.

[s0enke]

The naming introduced into CDK with writer and readers is misleading and confusing, since it's only valid at db cluster creation. Which instance is a reader or writer is not a property of the instance assigned by the createDbIstance API, but it depends on the order which db instance is created first: The first db instance created becomes the writer. Other instances created after the first instance become readers. And, in case of a fail-over (initiated by a cloud event, or a manually triggered fail-over by a user), a reader becomes the new writer. CDK cannot and should not reflect this in their APIs, since it's a dynamic property.

[plumdog]

I've updated the title of this issue because I don't think it's possible to resolve this confusion adequately with documentation as the behaviour implied by CDK's writer and readers props is contrary to how Aurora behaves.

[s0enke]

I just noticed that even the initial writer/reader assignment might no be valid. With a fresh cluster (one writer, one reader), Aurora just assigned the supposedly writer role ("assigned" by the CDK) the reader role, and vice versa.

[adrianhincuvisma]

Hello, I have an issue, I'm trying to migrate from instanceProps to writer and readers and CloudFormation wants to delete my old isntances and replace them with new ones, which is not optimal, how did you guys handle this? Don't tell me you created new ones and then removed the old ones

LE: found a solutions here #25900

[jsamuel1]

I'm hitting this issue.
Created a cluster with writer property, and added DBInstances.
After writer is deleted in cluster (outside of CDK), fails to update.

[jsamuel1]

Ideal scenario -- Allow for initial creation of multiple provisioned DBInstances in the cluster, spread across AZ's, but don't fail on upgrades if they are different later.

btw. It would be good if we could specify a naming convention for the dbInstances too - eg. include the AZ letter identifier in the name.

[mjgp2]

This new API is very counterintuitive and I would support rolling it back. The readers and writers concept is orthogonal to how readers and writers are chosen - they are certainly not static assignments.

Further, I have just come to look at specifying the new CA certificates, but it's not available in the instanceProps so I cannot update the CA certs without trying to use a workaround.