Introduction

In high‑traffic systems, database upgrades cannot be improvised. Dynalyst, a mobile advertising platform with a hybrid infrastructure spanning AWS and Cycloud, faced end‑of‑life for Aurora MySQL v2 (MySQL 5.7 compatible). Not upgrading meant expensive extended‑support costs; upgrading improperly risked operational failure. The objective was clear: migrate to MySQL 8.0 with minimal impact and zero service interruption.

Background

The environment ran under a hybrid architecture:

• Aurora MySQL v2 as the master in AWS
• MySQL 5.7 in Cycloud as a replica
• High‑traffic infrastructure handling hundreds of thousands of requests per second
• Zero tolerance for prolonged downtime

Beyond the end‑of‑support deadline, additional technical risks included:

• Incompatible changes between versions
• Replication issues
• Possible query performance degradation
• Risk of breaking replication filters
• It wasn’t just “bumping the version.” It was redesigning the transition without impacting the business.

Execution

Pre‑upgrade assessment

Before any change, the team reviewed:

• Incompatible Changes
• Deprecation & Removal Notes
• Important Changes in the release notes
• Validation using the MySQL Shell upgrade checker
• This allowed identification of real risks and avoided unnecessary checks.

Method selection: Blue/Green Deployment

AWS offers three upgrade methods:

• Snapshot/Restore
• In‑place upgrade
• Blue/Green Deployment

Blue/Green was chosen because it enables version change with minimal downtime, but in a hybrid setup it alone was insufficient. The switchover changes the endpoint automatically, which affected replication to Cycloud.

Solution:

• Temporarily pause replication
• Perform the switchover
• Reconfigure replication with the new endpoint
• Validate replication lag is within acceptable tolerance

Performance verification before full cutover

A test cluster was built: Aurora v2 → Aurora v3 (MySQL 8.0) → Cycloud MySQL 8.0

Three checkpoints were validated:

• Correct creation of the new cluster
• Functional replication
• End‑to‑end data consistency

Load tests were then executed:

• Identification of critical queries via Datadog DBM
• Parameter normalization

Some queries showed degradation and indexes were optimized before production rollout.

Progressive pseudo‑canary migration

The bid server in Cycloud ran across multiple StatefulSets. Strategy:

• Redirect a single StatefulSet to MySQL 8.0
• Monitor performance
• Gradually scale traffic

This allowed real‑world validation without systemic risk.

Rollback strategy prepared

Blue/Green allows capturing the binlog position at switchover time. Using that:

• Reverse replication was configured from Aurora v3 back to Aurora v2
• The environment was ready for immediate switchback

Fortunately it was not needed, but it was prepared.

Recommendations

• Don’t upgrade just because of a deadline; upgrade with a defined risk strategy.
• Use load tests based on real queries, not idealized scenarios.
• Configure rollback before the switchover, not afterwards.
• If using replication, prefer table‑level filtering.
• In massive environments, estimate real ALTER times before executing them.

Conclusions

Upgrading MySQL in a high‑traffic hybrid environment is not purely a technical task — it is risk management.

The success of the process depends not only on Blue/Green Deployment but on:

• Progressive validation
• Replication control
• Preventive optimization
• Rollback preparedness

When infrastructure supports real‑time business, the upgrade must be invisible to the end user.

Glossary

• Blue/Green Deployment: Strategy that keeps two parallel environments and switches between them to update versions.
• Replica Lag: Delay between primary and replica databases.
• Binlog: Binary log that stores changes for replication.
• utf8mb4: Recommended character encoding in MySQL 8.0.
• StatefulSet: Kubernetes resource for stateful applications.