(rds): Aurora Serverless V2 instances are re-created when switching from a common workaround to an official solution

[moltar]

Describe the bug

A feature release via #25437 (Serverless V2 support) breaks a common workaround for V2.

Workaround explained here: #20197 (comment)

Note that it has 21 likes, so likely there are many instances of this workaround in the wild.

However, when switching to the official solution from #25437, the instances change the ID and need to be recreated.

A question I raised in the PR is whether or not it is possible to retain the original IDs somehow. I don't see the need for them to change.

Example: #25437 (comment)

Expected Behavior

The instances not to be re-created.

Current Behavior

ID changes and the instance gets re-created.

Reproduction Steps

#25437 (comment)

Possible Solution

N/A

Additional Information/Context

#25437 (comment)

CDK CLI Version

latest

Framework Version

2

Node.js Version

16

OS

macOS

Language

Typescript

Language Version

TS 5

Other information

No response

[peterwoodworth]

Have you tried setting instanceIdentifier?

[IllarionovDimitri]

instance_identifier worked for me; the switch from a workaround to the official solution indeed re-created the instances but no troubles during that, works fine

[moltar]

Have you tried setting instanceIdentifier?

If I set that prop, I simply get an additional prop, but it does not affect the ID:

      writer: ClusterInstance.serverlessV2('Instance', {
        instanceIdentifier: 'Instance', // ⬅️ Added
        publiclyAccessible: databaseEngine?.public,
        parameterGroup: this.parameterGroup,
      }),

-     "ClusterInstance1448F06E4": Object {
+     "ClusterInstanceAAE2C8BD": Object {
        "DeletionPolicy": "Delete",
        "Properties": Object {
          "DBClusterIdentifier": Object {
            "Ref": "ClusterEB0386A7",
          },
          "DBInstanceClass": "db.serverless",
+         "DBInstanceIdentifier": "Instance",
          "DBParameterGroupName": Object {

[moltar]

instance_identifier worked for me; the switch from a workaround to the official solution indeed re-created the instances but no troubles during that, works fine

re-created the instances

So you were able to re-create the instance, in a B/G deployment-way, without any downtime or data loss?

Which engine did you use?

[IllarionovDimitri]

here how I define the writer and the reader instances

writer_instance = rds.ClusterInstance.serverless_v2(
            f"{config.ID}-writer-instance",
            instance_identifier=f"{config.ID}-writer-instance",
        )

reader_instance = rds.ClusterInstance.serverless_v2(
            f"{config.ID}-reader-instance",
            instance_identifier=f"{config.ID}-reader-instance",
            scale_with_writer=True,
        )

and here I define the cluster, it is an Aurora Postgre Engine, but B/G deployment is not supported by this kind of engine, so I simply deployed the new/official solution on top of the workaround, w/o data loss.

db_cluster = rds.DatabaseCluster(
             ...
            engine=rds.DatabaseClusterEngine.aurora_postgres(
                version=rds.AuroraPostgresEngineVersion.VER_13_9
            ),
            ...
            security_groups=[sg_db_cluster_import],
            serverless_v2_max_capacity=1,
            serverless_v2_min_capacity=0.5,
            readers=[reader_instance],
            storage_type=rds.DBClusterStorageType.AURORA,
            subnet_group=subnet_group,
            ...        
            writer=writer_instance,
        )

[IllarionovDimitri]

after testing on dev stage, have just migrated our prod stage from workaround to official solution. no problems so far

[hastarin]

I just tried following this with the .NET version of the CDK and it wanted to create a new reader/writer and complained that the InstanceId already exists.

I tried to follow the documentation for migrating from instance props but the property it suggests setting of isFromLegacyInstanceProps does not exist for a ServerlessV2 reader/writer.

[dabrowne]

I was able to successfully migrate from the custom resource workaround to the new Serverless V2 constructs without downtime using a combination of isFromLegacyInstanceProps: true and manually setting instanceIdentifier.

There was a bit of a stumbling block using CDK with Typescript, which is that isFromLegacyInstanceProps doesn't exist on the ServerlessV2ClusterInstanceProps type. This seems to be an oversight, as the author has assumed that nobody would be migrating serverless instances in this way as they have previously been unsupported. I found that including the prop anyway did however have the desired effect.

Here's what I ended up doing:

const instanceProps: rds.ServerlessV2ClusterInstanceProps & {
  isFromLegacyInstanceProps: boolean;
} = {
  publiclyAccessible: false,
  // ...
  isFromLegacyInstanceProps: true,
};

const dbCluster = new rds.DatabaseCluster(this, "cluster", {
  vpc,
  vpcSubnets,
  securityGroups,
  // ...
  writer: rds.ClusterInstance.serverlessV2("Instance1", {
    ...instanceProps,
    instanceIdentifier: "<current instance 1 identifier>",
  }),
  readers: [
    rds.ClusterInstance.serverlessV2("Instance2", {
      ...instanceProps,
      instanceIdentifier: "<current instance 2 identifier>",
      scaleWithWriter: true,
    }),
  ],
  serverlessV2MinCapacity: 1,
  serverlessV2MaxCapacity: 12,
  // ...
}

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.