(rds): Read Replica cannot join kerberos domain

[milesgranger]

What is the problem?

When creating a rds.DatabaseInstanceReadReplica, while it accepts domain and domain_role parameters, it does not accept an engine parameter.

Then deployment fails with

To use Domain, you must provide an eligible SQL Server, Oracle, or Postgres engines

Reproduction Steps

 vpc: ec2.Vpc

# source_instance: rds.DatabaseInstance

rds.DatabaseInstanceFromSnapshot(self, "Instance",
    snapshot_identifier="my-snapshot",
    engine=rds.DatabaseInstanceEngine.postgres(version=rds.PostgresEngineVersion.VER_12_3),
    vpc=vpc
)
instance = rds.DatabaseInstanceReadReplica(self, "ReadReplica",
    source_database_instance=source_instance,
    instance_type=ec2.InstanceType.of(ec2.InstanceClass.BURSTABLE2, ec2.InstanceSize.LARGE),
    vpc=vpc,
    domain='my-domain',
    domain_role=my_domain_role
)
assert instance.engine is None

What did you expect to happen?

Initially, suspected it would inherit the engine from the referenced database; or at least be able to provide an engine

What actually happened?

Could not join the domain

To use Domain, you must provide an eligible SQL Server, Oracle, or Postgres engines

CDK CLI Version

2.9.0

Framework Version

No response

Node.js Version

14.15.1

OS

Ubuntu 18

Language

Python

Language Version

3.7

Other information

No response

[skinny85]

Thanks for opening the issue @milesgranger!

This is fascinating - I actually though you couldn't supply the engine for a read replica, because it always inherits the engine from the primary.

@jogold what do you think? We have the engine property in IDatabaseInstance,we could fill this automatically in some cases - maybe when domain and/or domainRole were passed...?

[jogold]

Why not always supply it when we can?

[skinny85]

We definitely can, but I'm a little worried about updates to existing replicas - the docs say "Some interruption".

So, maybe do it only if domain was passed...?

[jogold]

We definitely can, but I'm a little worried about updates to existing replicas - the docs say "Some interruption".

I think that this is only when you switch "edition", like from sqlserver-ee to sqlserver-se. Will check this.

[jogold]

@skinny85 so I tested this.

If you specify engine for an existing read replica it gets replaced. So if a resource depends on the "endpoint" of the read replica the value will be updated once the new read replica is ready. For example for a container having the endpoint as an env var in its task definition the container will be replaced once the new read replica is ready => possible (small) downtimes.

What do you suggest?

[skinny85]

Thanks for doing the testing @jogold. I think that means we can't add this for existing replicas - if it causes downtime (I'm actually not sure it would be so small for large databases - perhaps re-creating the replica takes longer with larger datasets?), than I think it's too risky, and we should go with the "only add engine if domain (and/or domainRole?) were passed" plan.

Do you agree?

[jogold]

I'm actually not sure it would be so small for large databases - perhaps re-creating the replica takes longer with larger datasets?

Yes it takes longer but this doesn't impact the downtime. While the new read replica gets created the old one remains accessible and when the new one is ready the old one gets deleted (a CF replace, new resource gets created and when ready the old one gets removed during CF clean up).

A resource/app that GetAtts the read replica's endpoint will receive the new value when the new read replica is ready. At this point you can have a small downtime if this resource/app doesn't correctly handle this case. Let's say you have a load balancer in front of ECS tasks connecting to the read replica: in this case new ECS tasks will be launched by CF (CF replace of task definition because the value of an env var references the endpoint), then the old ones will be removed and finally the old read replica => no downtime.