MySQL 5.7‑to‑8.0 Upgrade Plan, Compatibility Checks, and Blue‑Green Deployment on AWS RDS

The MySQL 5.7 community edition will reach end‑of‑life on February 29, 2024, and AWS requires all MySQL instances to be upgraded before that date. Two game‑related instances are scheduled for forced upgrade on January 16, so an urgent migration plan is needed.

Background and Goal : No internal precedent exists for upgrading from MySQL 5.7 to 8.0, and many business‑impacting factors are unknown. The team decided to start from scratch, co‑creating a solution that fits the actual business situation.

Target Version : Based on MySQL release history, the latest stable version is 8.0.35 (released 2023‑11‑09). The next minor release (8.0.36) is expected around February 2024, so 8.0.35 is chosen as the “next‑to‑latest” target.

Upgrade Draft : A draft plan was produced that includes a zero‑impact, blue‑green deployment strategy, with a fallback path in case the AWS upgrade fails.

Pre‑Upgrade Compatibility Check : The MySQL Shell function util.checkForServerUpgrade() is used to generate a PrePatchCompatibility.log on Amazon RDS. The log categorises issues as ERROR (must be fixed), WARNING (potential functional impact), and NOTICE (handled automatically). Sample log screenshots are provided in the source.

Issue Analysis : Errors must be resolved before upgrade; warnings should be reviewed; notices are safe. The main identified risk is a driver version mismatch for Alibaba Cloud DataWorks, which was tested and found to have no impact.

Business SQL Verification : Using the pt‑upgrade tool, SQL statements are executed on both the source (5.7) and target (8.0) instances. Metrics collected include row count, row data, warnings, query time, query errors, and SQL errors. Two verification methods are described: direct comparison of a general log file and repeated testing with saved results.

Blue‑Green Deployment Test : A green instance (8.0.35) is created from a snapshot of the blue (5.7) instance. The steps include snapshot creation, binlog recovery, user reset, instance start‑stop cycles, and enabling automatic backups. The whole deployment took about 26‑27 minutes, with read/write traffic unaffected.

Switch Over : The actual switch from blue to green took 2‑3 minutes, with database write impact under 30 seconds. Detailed timestamps of each operation (snapshot, instance rename, binlog position recording, etc.) are listed.

Upgrade Execution : The upgrade was scheduled during the low‑traffic window (around 15:00). The process involved creating the green instance, performing the blue‑green switch, and verifying that the new instance runs correctly. Total time for creating the blue‑green environment was about 2 hours (including multi‑AZ and storage upgrades). The switch itself matched the expected 2‑minute duration.

Result Validation : Post‑upgrade checks confirmed that the new instance functions as expected. Minor non‑impacting items were noted for optional adjustment. Overall, the upgrade met the planned timeline and impact goals.