Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DBClusterParameterGroup not found: default.aurora5.6 #2512

Closed
mhuebner opened this issue May 9, 2019 · 10 comments · Fixed by #8686
Closed

DBClusterParameterGroup not found: default.aurora5.6 #2512

mhuebner opened this issue May 9, 2019 · 10 comments · Fixed by #8686
Assignees
Labels
@aws-cdk/aws-rds Related to Amazon Relational Database bug This issue is a bug. in-progress This issue is being actively worked on. p2

Comments

@mhuebner
Copy link

mhuebner commented May 9, 2019

Describe the bug
My DatabaseCluster ist configured with engine: rds.DatabaseClusterEngine.AuroraMysql and no custom ClusterParameterGroup is configured.

The following Exception is thrown:

DBClusterParameterGroup not found: default.aurora5.6 (Service: AmazonRDS; Status Code: 404; Error Code: DBClusterParameterGroupNotFound;

To Reproduce

        new rds.DatabaseCluster(this, 'prodRdsCuster', {
            clusterIdentifier: 'rds-prod',
            engine: rds.DatabaseClusterEngine.AuroraMysql,
            instances: 1,
            port: 3306,
            defaultDatabaseName: 'app',
            masterUser: {
                username: 'admin'
            },
            instanceProps: {
                instanceType: new ec2.InstanceTypePair(ec2.InstanceClass.Burstable2, ec2.InstanceSize.Medium),
                securityGroup: rdsSecurityGroup,
                vpc: props.vpc,
                vpcSubnets: {
                    subnetType: ec2.SubnetType.Isolated,
                }
            },
            backup: {
                preferredWindow: '02:00-03:00',
                retentionDays: 21
            },
            preferredMaintenanceWindow: 'Sun:03:00-Sun:04:00'
        });

cdk deploy

Expected behavior
Successful deployment

Version:

  • OS: MacOS Moave
  • Programming Language: TypeScript
  • CDK Version: 0.31.0

Workaround
Create a ClusterParameterGroup with explicit family setting:

const rdsClusterPrameterGroup = new ClusterParameterGroup(this, 'rdsClusterPrameterGroup', {
            description: 'MySQL 5.7',
            family: 'aurora-mysql5.7'
}

and use it in your cluster with

parameterGroup: rdsClusterPrameterGroup

@mhuebner mhuebner added the bug This issue is a bug. label May 9, 2019
@jogold
Copy link
Contributor

jogold commented May 9, 2019

Also already experienced this.

I think this is a bug in RDS. The problem is that the default.xxx parameter groups (created by AWS) are created only after creating a instance/cluster in the console or using the API directly. So if you never created a instance/cluster this way in a region and you try to deploy with CloudFormation it will not find the default.xxx parameter group.

@joehillen
Copy link
Contributor

joehillen commented May 30, 2019

@jogold Incorrect. I just launched a cluster with a default parameter group

    this.db = new DatabaseCluster(this, "Database", {
      engine: rds.DatabaseClusterEngine.AuroraPostgresql,
      engineVersion: "10.7",
      masterUser: {
        username: "admin",
      },
      defaultDatabaseName: "main",
      instanceProps: {
        instanceType: new ec2.InstanceType("r5.large"),
        vpcSubnets: {
          subnetType: ec2.SubnetType.Private,
        },
        vpc,
      },
      storageEncrypted: true,
      parameterGroup: {
        parameterGroupName: "default.aurora-postgresql10",
      } as any,
    });

Note: The engineVersion props comes from my PR #2698

@hoang-innomize
Copy link

hoang-innomize commented Aug 27, 2019

@joehillen So how can we create a new parameter group and override some parameters rather using the default one? See below sample code

const parameterGroup = new ParameterGroup(this, 'ParameterGroup', {
      family: 'aurora-mysql5.7',
      parameters: {
        max_connections: '100'
      }
    });

@SomayaB SomayaB added the @aws-cdk/aws-rds Related to Amazon Relational Database label Sep 6, 2019
@SomayaB SomayaB added needs-triage This issue or PR still needs to be triaged. needs-reproduction This issue needs reproduction. labels Sep 6, 2019
@NGL321 NGL321 removed the needs-triage This issue or PR still needs to be triaged. label Oct 5, 2019
@skinny85 skinny85 added the p2 label Oct 31, 2019
@pwrmiller
Copy link

If you need to do this in Python, to use the default parameter group for Aurora MySQL 5.7, use this:

pg = rds.ClusterParameterGroup.from_parameter_group_name(self, 'ParameterGroup', "default.aurora-mysql5.7")

@skinny85 skinny85 assigned nija-at and unassigned skinny85 Mar 19, 2020
@machielg
Copy link

machielg commented Jun 3, 2020

The bug is still present

@skinny85
Copy link
Contributor

skinny85 commented Jun 3, 2020

The bug is still present

Yep. I can tell you I'm working on it right now. Stay tuned.

@skinny85 skinny85 added in-progress This issue is being actively worked on. and removed needs-reproduction This issue needs reproduction. labels Jun 3, 2020
skinny85 added a commit to skinny85/aws-cdk that referenced this issue Jun 6, 2020
Change the types of the engine from DatabaseClusterEngine and its subclass,
DatabaseInstanceEngine, to 2 separate interfaces,
IClusterEngine and IInstanceEngine.
Add properties to each of them,
including engineVersion,
and thus stop taking engineVersion separately as a property for instances,
clusters and OptionGroups.
Allow changing the version of an existing engine to an arbitrary string.
Add a bind()-like protocol to both IClusterEngine and IInstanceEngine,
which allows expressing validation and default values logic directly in the engines,
instead of hard-coding them in cluster and instance.
Because of those changes, creating a default cluster with Aurora MySQL or Postgres engines now works out of the box,
instead of failing at deploy time.
We also correctly set the port for Postgres clusters to 5432,
instead of setting it to 3306 (which is the MySQL port).

Fixes aws#2213
Fixes aws#2512
Fixes aws#4150
Fixes aws#5126
Fixes aws#6532
Fixes aws#7072

BREAKING CHANGE: the class DatabaseClusterEngine has been replaced with the interface IClusterEngine in the type of DatabaseClusterProps.engine
* **rds**: the class DatabaseInstanceEngine has been replaced with the interface IInstanceEngine in the type of DatabaseInstanceSourceProps.engine
* **rds**: DatabaseClusterProps.engineVersion has been removed, in favor of the withVersion() method on IClusterEngine
* **rds**: DatabaseInstanceNewProps.instanceClass has been renamed to instanceType
* **rds**: DatabaseInstanceSourceProps.engineVersion has been removed, in favor of the withVersion() method on IInstanceEngine
* **rds**: the engine property can no longer be passed when creating a DatabaseInstanceReadReplica
* **rds**: the property majorEngineVersion can no longer be passed when creating an OptionGroup (instead, the version is taken directly from the passed engine)
skinny85 added a commit to skinny85/aws-cdk that referenced this issue Jun 22, 2020
Change the types of the engine from DatabaseClusterEngine and its subclass,
DatabaseInstanceEngine, to 2 separate interfaces,
IClusterEngine and IInstanceEngine.
Add properties to each of them,
including engineVersion,
and thus stop taking engineVersion separately as a property for instances,
clusters and OptionGroups.
Allow changing the version of an existing engine to an arbitrary string.
Add a bind()-like protocol to both IClusterEngine and IInstanceEngine,
which allows expressing validation and default values logic directly in the engines,
instead of hard-coding them in cluster and instance.
Because of those changes, creating a default cluster with Aurora MySQL or Postgres engines now works out of the box,
instead of failing at deploy time.
We also correctly set the port for Postgres clusters to 5432,
instead of leaving it as the default 3306 (which is the MySQL port).

Fixes aws#2213
Fixes aws#2512
Fixes aws#4150
Fixes aws#5126
Fixes aws#7072

BREAKING CHANGE: the class DatabaseClusterEngine has been replaced with the interface IClusterEngine in the type of DatabaseClusterProps.engine
* **rds**: the class DatabaseInstanceEngine has been replaced with the interface IInstanceEngine in the type of DatabaseInstanceSourceProps.engine
* **rds**: DatabaseClusterProps.engineVersion has been removed; instead, create an IClusterEngine with a specific version using the static factory methods in DatabaseClusterEngine
* **rds**: DatabaseInstanceSourceProps.engineVersion has been removed; instead, create an IInstanceEngine with a specific version using the static factory methods in DatabaseInstanceEngine
* **rds**: the property majorEngineVersion can no longer be passed when creating an OptionGroup; instead, create an IInstanceEngine with a specific version using the static factory methods in DatabaseInstanceEngine
skinny85 added a commit to skinny85/aws-cdk that referenced this issue Jun 22, 2020
Change the types of the engine from DatabaseClusterEngine and its subclass,
DatabaseInstanceEngine, to 2 separate interfaces,
IClusterEngine and IInstanceEngine.
Add properties to each of them,
including engineVersion,
and thus stop taking engineVersion separately as a property for instances,
clusters and OptionGroups.
Allow changing the version of an existing engine to an arbitrary string.
Add a bind()-like protocol to both IClusterEngine and IInstanceEngine,
which allows expressing validation and default values logic directly in the engines,
instead of hard-coding them in cluster and instance.
Because of those changes, creating a default cluster with Aurora MySQL or Postgres engines now works out of the box,
instead of failing at deploy time.
We also correctly set the port for Postgres clusters to 5432,
instead of leaving it as the default 3306 (which is the MySQL port).

Fixes aws#2213
Fixes aws#2512
Fixes aws#4150
Fixes aws#5126
Fixes aws#7072

BREAKING CHANGE: the class DatabaseClusterEngine has been replaced with the interface IClusterEngine in the type of DatabaseClusterProps.engine
* **rds**: the class DatabaseInstanceEngine has been replaced with the interface IInstanceEngine in the type of DatabaseInstanceSourceProps.engine
* **rds**: DatabaseClusterProps.engineVersion has been removed; instead, create an IClusterEngine with a specific version using the static factory methods in DatabaseClusterEngine
* **rds**: DatabaseInstanceSourceProps.engineVersion has been removed; instead, create an IInstanceEngine with a specific version using the static factory methods in DatabaseInstanceEngine
* **rds**: the property majorEngineVersion can no longer be passed when creating an OptionGroup; instead, create an IInstanceEngine with a specific version using the static factory methods in DatabaseInstanceEngine
skinny85 added a commit to skinny85/aws-cdk that referenced this issue Jun 24, 2020
Change the types of the engine from DatabaseClusterEngine and its subclass,
DatabaseInstanceEngine, to 2 separate interfaces,
IClusterEngine and IInstanceEngine.
Add properties to each of them,
including engineVersion,
and thus stop taking engineVersion separately as a property for instances,
clusters and OptionGroups.
Allow changing the version of an existing engine to an arbitrary string.
Add a bind()-like protocol to both IClusterEngine and IInstanceEngine,
which allows expressing validation and default values logic directly in the engines,
instead of hard-coding them in cluster and instance.
Because of those changes, creating a default cluster with Aurora MySQL or Postgres engines now works out of the box,
instead of failing at deploy time.
We also correctly set the port for Postgres clusters to 5432,
instead of leaving it as the default 3306 (which is the MySQL port).

Fixes aws#2213
Fixes aws#2512
Fixes aws#4150
Fixes aws#5126
Fixes aws#7072

BREAKING CHANGE: the class DatabaseClusterEngine has been replaced with the interface IClusterEngine in the type of DatabaseClusterProps.engine
* **rds**: the class DatabaseInstanceEngine has been replaced with the interface IInstanceEngine in the type of DatabaseInstanceSourceProps.engine
* **rds**: DatabaseClusterProps.engineVersion has been removed; instead, create an IClusterEngine with a specific version using the static factory methods in DatabaseClusterEngine
* **rds**: DatabaseInstanceSourceProps.engineVersion has been removed; instead, create an IInstanceEngine with a specific version using the static factory methods in DatabaseInstanceEngine
* **rds**: the property majorEngineVersion can no longer be passed when creating an OptionGroup; instead, create an IInstanceEngine with a specific version using the static factory methods in DatabaseInstanceEngine
skinny85 added a commit to skinny85/aws-cdk that referenced this issue Jun 26, 2020
Change the types of the engine from DatabaseClusterEngine and its subclass,
DatabaseInstanceEngine, to 2 separate interfaces,
IClusterEngine and IInstanceEngine.
Add properties to each of them,
including engineVersion,
and thus stop taking engineVersion separately as a property for instances,
clusters and OptionGroups.
Allow changing the version of an existing engine to an arbitrary string.
Add a bind()-like protocol to both IClusterEngine and IInstanceEngine,
which allows expressing validation and default values logic directly in the engines,
instead of hard-coding them in cluster and instance.
Because of those changes, creating a default cluster with Aurora MySQL or Postgres engines now works out of the box,
instead of failing at deploy time.
We also correctly set the port for Postgres clusters to 5432,
instead of leaving it as the default 3306 (which is the MySQL port).

Fixes aws#2213
Fixes aws#2512
Fixes aws#4150
Fixes aws#5126
Fixes aws#7072

BREAKING CHANGE: the class DatabaseClusterEngine has been replaced with the interface IClusterEngine in the type of DatabaseClusterProps.engine
* **rds**: the class DatabaseInstanceEngine has been replaced with the interface IInstanceEngine in the type of DatabaseInstanceSourceProps.engine
* **rds**: DatabaseClusterProps.engineVersion has been removed; instead, create an IClusterEngine with a specific version using the static factory methods in DatabaseClusterEngine
* **rds**: DatabaseInstanceSourceProps.engineVersion has been removed; instead, create an IInstanceEngine with a specific version using the static factory methods in DatabaseInstanceEngine
* **rds**: the property majorEngineVersion can no longer be passed when creating an OptionGroup; instead, create an IInstanceEngine with a specific version using the static factory methods in DatabaseInstanceEngine
skinny85 added a commit to skinny85/aws-cdk that referenced this issue Jul 7, 2020
Change the types of the engine from DatabaseClusterEngine and its subclass,
DatabaseInstanceEngine, to 2 separate interfaces,
IClusterEngine and IInstanceEngine.
Add properties to each of them,
including engineVersion,
and thus stop taking engineVersion separately as a property for instances,
clusters and OptionGroups.
Allow changing the version of an existing engine to an arbitrary string.
Add a bind()-like protocol to both IClusterEngine and IInstanceEngine,
which allows expressing validation and default values logic directly in the engines,
instead of hard-coding them in cluster and instance.
Because of those changes, creating a default cluster with Aurora MySQL or Postgres engines now works out of the box,
instead of failing at deploy time.
We also correctly set the port for Postgres clusters to 5432,
instead of leaving it as the default 3306 (which is the MySQL port).

Fixes aws#2213
Fixes aws#2512
Fixes aws#4150
Fixes aws#5126
Fixes aws#7072

BREAKING CHANGE: the class DatabaseClusterEngine has been replaced with the interface IClusterEngine in the type of DatabaseClusterProps.engine
* **rds**: the class DatabaseInstanceEngine has been replaced with the interface IInstanceEngine in the type of DatabaseInstanceSourceProps.engine
* **rds**: DatabaseClusterProps.engineVersion has been removed; instead, create an IClusterEngine with a specific version using the static factory methods in DatabaseClusterEngine
* **rds**: DatabaseInstanceSourceProps.engineVersion has been removed; instead, create an IInstanceEngine with a specific version using the static factory methods in DatabaseInstanceEngine
* **rds**: the property majorEngineVersion can no longer be passed when creating an OptionGroup; instead, create an IInstanceEngine with a specific version using the static factory methods in DatabaseInstanceEngine
skinny85 added a commit to skinny85/aws-cdk that referenced this issue Jul 9, 2020
Change the types of the engine from DatabaseClusterEngine and its subclass,
DatabaseInstanceEngine, to 2 separate interfaces,
IClusterEngine and IInstanceEngine.
Add properties to each of them,
including engineVersion,
and thus stop taking engineVersion separately as a property for instances,
clusters and OptionGroups.
Allow changing the version of an existing engine to an arbitrary string.
Add a bind()-like protocol to both IClusterEngine and IInstanceEngine,
which allows expressing validation and default values logic directly in the engines,
instead of hard-coding them in cluster and instance.
Because of those changes, creating a default cluster with Aurora MySQL or Postgres engines now works out of the box,
instead of failing at deploy time.
We also correctly set the port for Postgres clusters to 5432,
instead of leaving it as the default 3306 (which is the MySQL port).

Fixes aws#2213
Fixes aws#2512
Fixes aws#4150
Fixes aws#5126
Fixes aws#7072

BREAKING CHANGE: the class DatabaseClusterEngine has been replaced with the interface IClusterEngine in the type of DatabaseClusterProps.engine
* **rds**: the class DatabaseInstanceEngine has been replaced with the interface IInstanceEngine in the type of DatabaseInstanceSourceProps.engine
* **rds**: DatabaseClusterProps.engineVersion has been removed; instead, create an IClusterEngine with a specific version using the static factory methods in DatabaseClusterEngine
* **rds**: DatabaseInstanceSourceProps.engineVersion has been removed; instead, create an IInstanceEngine with a specific version using the static factory methods in DatabaseInstanceEngine
* **rds**: the property majorEngineVersion can no longer be passed when creating an OptionGroup; instead, create an IInstanceEngine with a specific version using the static factory methods in DatabaseInstanceEngine
@mergify mergify bot closed this as completed in #8686 Jul 9, 2020
mergify bot pushed a commit that referenced this issue Jul 9, 2020
Change the types of the engine from `DatabaseClusterEngine` and its subclass, `DatabaseInstanceEngine`, to 2 separate interfaces, `IClusterEngine` and `IInstanceEngine`. Add properties to each of them, including engineVersion, and thus stop taking `engineVersion` separately as a property for instances, clusters and `OptionGroup`s. Allow creating engines with the version given as an arbitrary string.

Add a `bind()`-like protocol to both `IClusterEngine` and `IInstanceEngine`, which allows expressing validation and default values logic directly in the engines, instead of hard-coding them in cluster and instance.

Because of those changes, creating a default cluster with Aurora MySQL or Postgres engines now works out of the box, instead of failing at deploy time. We also correctly set the port for Postgres clusters to 5432, instead of leaving it as the default 3306 (which is the MySQL port).

Fixes #2213
Fixes #2512
Fixes #4150
Fixes #5126
Fixes #7072

BREAKING CHANGE: the class `DatabaseClusterEngine` has been replaced with the interface `IClusterEngine` in the type of `DatabaseClusterProps.engine`
* **rds**: the class `DatabaseInstanceEngine` has been replaced with the interface `IInstanceEngine` in the type of `DatabaseInstanceSourceProps.engine`
* **rds**: `DatabaseClusterProps.engineVersion` has been removed; instead, create an `IClusterEngine` with a specific version using the static factory methods in `DatabaseClusterEngine`
* **rds**: `DatabaseInstanceSourceProps.engineVersion` has been removed; instead, create an `IInstanceEngine` with a specific version using the static factory methods in `DatabaseInstanceEngine`
* **rds**: the property `majorEngineVersion` can no longer be passed when creating an `OptionGroup`; instead, create an `IInstanceEngine` with a specific version using the static factory methods in `DatabaseInstanceEngine`

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
@saviour123
Copy link

The bug is still present in 2022. I just wanted to created a new resource via cloudformation in ap and this is the same error i got.

@itjuan
Copy link

itjuan commented Mar 23, 2023

The bug is still present in 2022. I just wanted to created a new resource via cloudformation in ap and this is the same error i got.

In case you still have the issue. This is caused by parameter group versions been deprecated. You can still use the default parameter groups, you just need to find the available versions with aws rds describe-db-engine-versions --query "DBEngineVersions[].DBParameterGroupFamily"

Source: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-rds-dbclusterparametergroup.html#cfn-rds-dbclusterparametergroup-family

@sushilatlabs
Copy link

I created test database using AWS console UI first, it created default default.aurora-postgresql14 parameter group.
After this my CDK command started working with:
parameterGroup: ParameterGroup.fromParameterGroupName( this, "ParameterGroup", "default.aurora-postgresql13" )

@tyler-rpi
Copy link

tyler-rpi commented Aug 22, 2024

I faced this. I think the answer is somewhat concealed in the description of the parameters prop:

You can only specify parameterGroup or parameters but not both. You need to use a versioned engine to auto-generate a DBClusterParameterGroup.

Using a versioned engine, rather than DatabaseClusterEngine.AURORA_MYSQL, solved the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
@aws-cdk/aws-rds Related to Amazon Relational Database bug This issue is a bug. in-progress This issue is being actively worked on. p2
Projects
None yet