MySQL 8.

My team is currently dealing with the MySQL 8.0 end-of-life panic. AWS started hitting us with those Extended Support fees, so we had to move everything to 8.4 LTS. The problem is our setup is a bit of a mess—we have one giant RDS instance serving about seven different projects. We've got old Laravel apps, some Node.js services, and a few legacy sites all living in different logical databases on one cluster.

The obvious move is using RDS Blue/Green deployments. It's great for zero-downtime, but we hit a massive wall during the validation phase. If you're planning a migration, you need to know that the Green environment is essentially read-only for testing purposes. You can't just point a staging app at the Green instance and run a full suite of integration tests that involve writes, because you don't want to mess with the replication stream or risk something weird happening before the actual switchover.

When we tried to run a few write-heavy migration scripts on the Green instance to see if the 8.4 engine handled our specific data types correctly, we realized we were limited. In a real-world AI workflow or a complex app deployment, you can't just "hope" the read queries work; you need to verify the full write cycle.

To solve this, we stopped trying to force the Green instance to be our testbed and started layering snapshots on top of the process. Here is the practical tutorial on how we actually handled it:

The "Snapshot-Parallel" Testing Workflow

Instead of testing directly on the Green environment, we used the Green instance as a "golden image" for compatibility testing.

1. Spin up the Blue/Green Deployment: Create the Green environment and let it upgrade to MySQL 8.4.
2. Take a Snapshot of Green: Once the Green instance is upgraded and synced, take a manual snapshot of it.
3. Restore to a Temporary Test Instance: Restore that snapshot to a completely separate, isolated RDS instance.
4. Run Destructive Tests: Point each of the seven project teams to their own restored snapshot instance. Since this is a standalone copy, they can run UPDATE, DELETE, and schema migrations without affecting the Blue/Green replication.
5. Verify and Sign-off: Once a project confirms 8.4 compatibility on the snapshot, they get the green light.
6. Execute Switchover: Only after every single project has signed off do we trigger the actual Blue/Green switchover.

This approach removes the "big bang" risk. If the Laravel app breaks on 8.4, it breaks on a temporary snapshot instance, not on the environment we're about to promote to production.

For anyone doing this, keep an eye on your parameter groups. A lot of the 8.4 compatibility issues we found weren't actually SQL syntax errors, but default parameter changes in the new engine version. By using the snapshot method, we could tweak the parameter group on the test instance and document exactly what needed to be changed on the Green instance before the final cutover.

It adds a few extra steps to the deployment, but it's the only way to sleep soundly when you're managing a shared database for multiple teams.