Content tagged with "blue-green-deployment"
Upgraded AWS JDBC Wrapper from 2.6.4 to 3.2.0 and re-tested Blue/Green Switchover on both PostgreSQL and MySQL. MySQL's connection failure turned out to be timing-dependent (0–1 failures). Summarizes 3.x migration guidance.
Tested Blue/Green Switchover on Aurora MySQL and compared with PostgreSQL. IN_PROGRESS phase was only 3s (vs 12s for PG), but the BG plugin may have 0–1 connection errors (timing-dependent). HikariCP's stale writer problem is engine-agnostic. Plain JDBC stayed on old host for 31s after recovery.
Compared downtime during Blue/Green Switchover across Plain JDBC, HikariCP with retry, and AWS JDBC Driver BG plugin. The plugin recorded 0 failures in 400 queries during testing. HikariCP kept connecting to the old writer — a critical pitfall.
Measured real downtime during Aurora PostgreSQL failover vs Blue/Green Switchover. Failover had 12 connection failures in two separate windows, Blue/Green Switchover ~26s with 6 failures. DNS TTL of 60s is the key bottleneck.
Creating a Blue/Green deployment with a major version upgrade on an Aurora PostgreSQL cluster using a custom parameter group fails with InvalidParameterCombination. You must explicitly specify a Green parameter group.
Running create-blue-green-deployment with the default parameter group fails with SourceClusterNotSupportedFault. Set rds.logical_replication = 1 for PostgreSQL or binlog_format = ROW for MySQL, then reboot all instances.
All connections are dropped during Blue/Green Switchover, but HikariCP may reconnect to the old writer via DNS cache. Write queries fail with read-only transaction errors. Same behavior on both PostgreSQL and MySQL.