Skip to content

fix: reuse a shared blue/green cluster parameter group - #178

Open
yanw-bq wants to merge 1 commit into
mainfrom
fix/bg-parameter-group-reuse
Open

yanw-bq wants to merge 1 commit into
mainfrom
fix/bg-parameter-group-reuse

Conversation

@yanw-bq

@yanw-bq yanw-bq commented Oct 28, 2026 •

Copy link
Copy Markdown

Summary

Fix the Blue/Green integration jobs failing with DBParameterGroupQuotaExceeded by reusing one shared cluster parameter group instead of creating one per run.

Description

Each Blue/Green job (Windows, macOS, Linux) created a cluster parameter group named after its run (parameter-<cluster id>) and deleted it at teardown. The delete always failed with InvalidDBParameterGroupState, because RDS keeps the just-deleted clusters attached to the group for several minutes. destroy only logged a warning, so every job leaked one group. Every push to main leaked three, until ap-northeast-3 hit its quota of 50 and every Blue/Green job since Oct 20 failed at the create step.

The group's parameters are the same on every run, so this PR shares one group instead:

  • get_or_create_parameter_group (replaces create_parameter_group / delete_parameter_group in scripts/db_resources.py):
    • Names the group <prefix>-<parameter group family>, e.g. odbc-wrapper-bg-aurora-postgresql18, so a new major version gets its own group automatically.
    • If another run already created the group (DBParameterGroupAlreadyExists), reuses it.
    • Reads the current values and only changes the ones that differ, so clusters already using the group aren't flagged for a reboot. This also repairs a group left half-configured by a run that died.
    • Reads the family from describe_db_engine_versions. This also fixes the MySQL family name, which used to come out as aurora-mysql-<full version> instead of aurora-mysql8.4.
  • destroy no longer deletes the group, and its --parameter-group option is removed. Otherwise one job's teardown could delete the group while another job is attaching it.
  • Workflow: the three Blue/Green create steps pass --parameter-group odbc-wrapper-bg, and the three destroy steps no longer pass the option.

The parameter values are unchanged (rds.logical_replication=1, max_wal_senders=20, rds.allowed_extensions=rds_tools for PostgreSQL; binlog_format=ROW for MySQL).

Testing

  • Ran get_or_create_parameter_group against ap-northeast-3 twice. The first call created odbc-wrapper-bg-aurora-postgresql18 and set its three parameters; the second reused it and made no changes. Confirmed the values with aws rds describe-db-cluster-parameters --source user.
  • Resolved the Aurora MySQL family (read-only): aurora-mysql8.4.
  • The Blue/Green jobs only run on a push to main or a manual dispatch, so they weren't run on this PR. A manual dispatch of the Integration Tests workflow on this branch would run them.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Each blue/green job created a parameter group named after its run and
deleted it at teardown, but the delete always failed: RDS keeps the
just-deleted clusters attached to the group for several minutes, and the
error was swallowed. One group leaked per job until the region hit its
50 parameter group quota, failing every blue/green job since Oct 20.

The parameters are the same every run, so create one group per
parameter group family (odbc-wrapper-bg-aurora-postgresql18), reuse it
across runs, and never delete it. Concurrent creates fall back to reuse,
and parameters are only modified when they differ so clusters already
using the group are not flagged for reboot.

The family is now read from RDS, which also fixes the invalid MySQL
family name (aurora-mysql-<full version> instead of aurora-mysql8.4).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant