Step-by-Step Guide: Upgrading AWS RDS MySQL from 8.0 to 8.4

A complete guide to upgrading AWS RDS MySQL 8.0 to 8.4. With MySQL 8.0 standard support ending July 31, 2026, upgrading is essential. This guide covers pre-upgrade prep (instance checks, SQL compatibility), two upgrade paths (In-place vs. recommended Blue/Green deployments), step-by-step operations, post-upgrade verification, and rollback strategies. Packed with best practices, it helps DevOps, DBAs, and developers safely upgrade via the AWS Console or CLI.

Lei Feng

Published Jul 16, 2026

Last modified Jul 16, 2026

AWS RDS MySQL 8.0 to 8.4 Upgrade — Complete Guide

Author: Lei Feng

Date: July 2026

Audience: DevOps engineers, DBAs, and developers who need to upgrade Amazon RDS for MySQL from 8.0 to 8.4. All operations can be performed through the AWS Management Console, with AWS CLI commands provided for reference.

1. Introduction

Amazon RDS for MySQL is a fully managed database service that automates hardware provisioning, database setup, patching, and backups. With MySQL 8.0 approaching its end of standard support and the MySQL 8.4 feature set maturing, more enterprises are planning to migrate their production environments to MySQL 8.4.

Key Drivers:

Factor	Description
🔴 Standard Support Ends	MySQL 8.0 standard support ends July 31, 2026
🟢 Performance Gains	8.4 delivers 20%+ improvement in low-concurrency read scenarios
🔒 Security Enhancements	Stronger default authentication, weak cipher removal
⚡ New Features	SQL enhancements, EXPLAIN improvements, GTID tags, and more

This guide provides a hands-on, step-by-step walkthrough for upgrading RDS MySQL 8.0 to 8.4 via the AWS Console, including compatibility checks, operational procedures, precautions, and a complete case study to help you execute a smooth upgrade.

2. Version Lifecycle & Why Upgrade

2.1 Key Milestones

Event	Date
MySQL 8.0 Standard Support Ends	July 31, 2026
RDS Extended Support Begins	Automatically enabled after July 31, 2026
Recommended Upgrade Completion	Before July 31, 2026

2.2 Impact After Support Ends

If you do not disable RDS Extended Support when creating or restoring a DB instance, Amazon RDS automatically enrolls it and charges the corresponding fees.
If your instance is not running the last minor version released before the support end date, Amazon RDS will automatically upgrade it to that minor version.
Extended support fees accumulate over time — plan your upgrade early.

Note: For more version lifecycle details, see Supported MySQL major versions on Amazon RDS .

3. Pre-Upgrade Preparation — Compatibility Checklist

⚠️ Important: Complete all compatibility checks in a test environment before touching production.

3.1 Check Current Instance Status

Console:
RDS Console → Databases → Select instance → Check engine version under the "Configuration" tab

CLI Reference:

1
2
3
4
aws rds describe-db-instances \
    --db-instance-identifier <your-db-instance> \
    --query 'DBInstances[0].{Status:DBInstanceStatus,Version:EngineVersion,MultiAZ:MultiAZ}' \
    --region <your-region>

3.2 Verify Available Target Versions

Console:
RDS Console → Databases → Select instance → Actions → "Modify" → Check the DB engine version dropdown

CLI Reference:

1
2
3
4
5
aws rds describe-db-engine-versions \
    --engine mysql \
    --engine-version 8.0 \
    --query 'DBEngineVersions[0].ValidUpgradeTarget[?IsMajorVersionUpgrade==`true`].EngineVersion' \
    --region <your-region>

3.3 SQL Syntax Compatibility Check

This is one of the most critical pre-upgrade steps. The 8.0 → 8.4 upgrade includes several incompatible changes.

Method A: MySQL Shell Upgrade Checker

1
2
3
# 安装 MySQL Shell（本地或跳板机）
# 运行升级检查
mysqlsh — util check-for-server-upgrade —host=<your-rds-endpoint> —user=admin —password

Method B: Manual Compatibility Checklist

Check Item	Description	Action
Deprecated functions/syntax	Verify no usage of functions removed in 8.4	SELECT * FROM information_schema.ROUTINES
GROUP BY implicit sort	Removed since MySQL 8.0, check app code	Replace with explicit ORDER BY
Reserved words	New reserved words in 8.4	Check table/column name conflicts
Time zone	Verify time zone compatibility	Check time_zone parameter
SQL Mode	Review sql_mode configuration	SELECT @@GLOBAL.sql_mode;

Notable SQL Changes in MySQL 8.4:

New Set Operations:

1
2
3
4
5
6
7
8
-- 8.4 支持 EXCEPT 和 INTERSECT，使用哈希表优化
SELECT * FROM table_a
EXCEPT
SELECT * FROM table_b;

SELECT * FROM table_a
INTERSECT
SELECT * FROM table_b;

EXPLAIN 改进：

1
2
3
4
5
-- 8.4 支持 FORMAT=JSON INTO 选项
EXPLAIN FORMAT=JSON INTO @my_explain SELECT * FROM my_table;

-- 支持 FOR SCHEMA 选项
EXPLAIN FOR SCHEMA my_schema SELECT * FROM users;

Scalar Correlated Subquery Optimization:

1
2
3
-- 8.4 扩展了将标量相关子查询转换为派生表的优化支持
SELECT * FROM orders o
WHERE o.total > (SELECT AVG(total) FROM orders WHERE customer_id = o.customer_id);

3.4 Parameter Group Preparation

⚠️ Do not use the default parameter group. Create a custom MySQL 8.4 parameter group in advance.

Console:
RDS Console → Parameter groups → Create parameter group → Select mysql8.4 family → Associate with target instance after creation

Key Parameter Changes (8.0 → 8.4 Default Value Comparison):

Parameter	8.0 Default	8.4 Default	Adjustment Needed
innodb_io_capacity	200	10000	⚠️ Adjust based on disk IOPS
innodb_io_capacity_max	2000	20000	⚠️ 同上
innodb_log_buffer_size	16MB	64MB	✅ Larger is better, no adjustment needed
authentication_policy	Custom	:caching_sha2_password	⚠️ Critical change, see Section 4.1
adaptive_hash_index	ON	OFF	⚠️ Monitor performance impact

🔑 Most important parameter adjustment: innodb_io_capacity jumps from 200 to 10000. If your disk IOPS (e.g., gp3 default 3000 IOPS) is lower than this value, high-concurrency write latency can increase significantly. Always tune these two parameters according to your disk configuration!

3.5 Enable Automated Backups

Blue/Green deployments require automated backups on the source instance (BackupRetentionPeriod > 0).

Console:
RDS Console → Databases → Select instance → Modify → Backup → Set backup retention period ≥ 7 days

CLI Reference:

1
2
3
4
aws rds modify-db-instance \
    --db-instance-identifier <your-db-instance> \
    --backup-retention-period 7 \
    --apply-immediately

3.6 Create a Pre-Upgrade Snapshot (Final Safety Net)

Console:
RDS Console → Databases → Select instance → Actions → "Take snapshot"

CLI Reference:

1
2
3
4
aws rds create-db-snapshot \
    --db-instance-identifier <your-db-instance> \
    --db-snapshot-identifier pre-upgrade-snapshot-202607 \
    --region <your-region>

4. MySQL 8.4 Key Changes & Precautions

4.1 Authentication Plugin Changes (⚠️ Highest Risk)

This is the most common cause of post-upgrade failures. Please pay close attention.

Change	Description
mysql_native_password disabled by default	The authentication method used since MySQL 4.0 is no longer enabled by default
authentication_policy new default	":caching_sha2_password" — new users default to the more secure caching_sha2_password
default_authentication_plugin removed	Replaced by authentication_policy

Error You May Encounter:

1
ERROR 2059 (HY000): Authentication plugin 'caching_sha2_password' cannot be loaded

Affected Client Versions:

Client Library	Affected Versions	Solution
MySQL Connector/J	< 8.0.9	Upgrade to ≥ 8.0.9
PHP mysqli/PDO	< 7.4	Upgrade PHP version
Python PyMySQL	< 0.9.0	升级 PyMySQL
js mysql2	< 1.6.0	升级 mysql2
Legacy MySQL CLI	All old versions	Upgrade client tools

Three Solutions:

Solution 1 (Recommended): Upgrade client libraries to support caching_sha2_password

1
2
3
-- 临时方案：修改现有用户认证方式
ALTER USER 'your_username'@'%' IDENTIFIED WITH mysql_native_password BY 'your_password';
FLUSH PRIVILEGES;

Solution 2 (Short-term Transition): Modify the RDS parameter group globally to use the old authentication method
- Go to RDS → Parameter groups
- Set authentication_policy to *:mysql_native_password
- Apply to the instance and reboot
Solution 3 (Long-term): Upgrade all database client libraries used by your applications

4.2 Security Improvements

Improvement	Description
Weak cipher removal	Cipher suites that don't meet security standards are no longer supported
Certificate validation enhancement	New tls-certificates-enforced-validation system variable
LDAP authentication timeout	New connection and response timeout configuration

4.3 New Privileges

1
2
3
-- FLUSH_PRIVILEGES 权限：专门用于 FLUSH PRIVILEGES 语句
-- OPTIMIZE_LOCAL_TABLE 权限：用于本地表优化操作
-- TRANSACTION_GTID_TAG 权限：用于 GTID 标签功能

4.4 Removed Parameters and Variables

⚠️ If your applications or scripts reference any of the following, update them beforehand:

Old Parameter	Replacement
binlog_transaction_dependency_tracking	Removed, no replacement
default_authentication_plugin	Use authentication_policy instead
expire_logs_days	Use binary log configuration instead
MASTER keyword (binlog replication)	Use SOURCE keyword instead

示例：

1
2
3
4
5
6
7
-- 旧语法（8.0）
CHANGE MASTER TO MASTER_HOST='...';
SHOW SLAVE STATUS;

-- 新语法（8.4）
CHANGE REPLICATION SOURCE TO SOURCE_HOST='...';
SHOW REPLICA STATUS;

4.5 Performance Summary

Based on sysbench 1.0.20 cross-AZ benchmarks on r7g.large Multi-AZ instances (250 tables × 25,000 rows/table):

Scenario	Performance Change	Notes
Low-concurrency reads	+20% or more	Significant improvement
High-concurrency reads	Roughly flat	No meaningful change
Low-concurrency writes	Flat	No meaningful change
High-concurrency writes (default params)	-7% to -22%	⚠️ Requires innodb_io_capacity tuning
High-concurrency writes (tuned)	Flat	Recovers after parameter adjustment

4.6 Histogram Auto-Update

1
2
-- 8.4 支持在 ANALYZE TABLE 时自动更新直方图
ANALYZE TABLE my_table UPDATE HISTOGRAM ON column_a, column_b;

5. Upgrade Method Comparison & Selection

5.1 Method Overview

Dimension	In-Place Upgrade	Blue/Green Deployment
Complexity	⭐ Low	⭐⭐⭐ Medium
Downtime	Minutes to tens of minutes	~30 seconds
Business Impact	Significant	Minimal
Fast Rollback	❌ Requires snapshot restore	✅ Switch back
Pre-Upgrade Testing	❌ Not possible	✅ Full testing on green
Best For	Dev/Test environments	Production (Recommended)
Cost	No additional cost	Temporary green env. cost

5.2 Selection Guide

Dev/Test environments → In-place upgrade (simple and fast)
Production environments → Blue/Green deployment (Recommended)
Zero-downtime required → Blue/Green + application dual-write (additional development needed)

6. Method A — In-Place Upgrade via Console

Suitable for development/test environments or non-critical instances during low-traffic periods.

6.1 Step-by-Step

Step 1: Open the Modify Instance Page

RDS Console → Databases → Select the instance → Click "Modify"

Step 2: Change DB Engine Version

Under "DB engine options":

DB engine version: Select MySQL 8.4.x
DB instance class: Consider upgrading to Graviton3/4 instances for better price/performance

Step 3: Associate the New Parameter Group

DB parameter group: Select the pre-created MySQL 8.4 parameter group
If you were using the default parameter group, create a custom one first

Step 4: Apply the Modification

Under "Schedule modifications":

Select "Apply immediately" (or choose the maintenance window)
⚠️ Immediate application triggers a database reboot, causing several seconds of downtime

Step 5: Monitor Upgrade Progress

Console:
RDS Console → Databases → Select instance → Status will show "Upgrading"

6.2 Monitoring Scripts During Upgrade (Optional)

Run these scripts in separate terminals to monitor database availability during the upgrade:

1
2
3
4
5
6
7
8
9
10
11
12
# 读请求健康检查（每秒检查一次）
while true; do
  mysql -h <your-rds-endpoint> -u admin -p"<password>" -e "SELECT NOW(), @@hostname, @@VERSION;"
  sleep 1
done

# 写请求健康检查（每秒写入一条）
while true; do
  mysql -h <your-rds-endpoint> -u admin -p"<password>" <database> \
    -e "INSERT INTO health_check(test_time) VALUES(NOW());"
  sleep 1
done

6.3 Pros & Cons

Pros:

Simple operation, all in one page
No additional cost

Cons:

Database unavailable during upgrade (minutes to tens of minutes)
Cannot verify compatibility before upgrade
Difficult to roll back (requires snapshot restore)

7. Method B — Blue/Green Deployment Upgrade (Recommended)

✅ Production environment first choice. Creates a complete "green" environment, upgrades it, then switches traffic via DNS. Minimal business impact.

7.1 Overall Flow

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
┌─────────────────────────────────────────────────────────────────────────────┐
│                         蓝绿部署升级完整流程                                  │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│  阶段1              阶段2              阶段3              阶段4              │
│  创建蓝环境          自动升级            执行切换            验证与清理         │
│  ┌─────────┐       ┌─────────┐       ┌─────────┐       ┌─────────┐        │
│  │蓝环境    │       │绿环境    │       │绿环境    │       │绿环境    │        │
│  │MySQL8.0 │──复制─▶│MySQL8.0 │──升级─▶│MySQL8.4 │──切换─▶│MySQL8.4 │        │
│  │(生产)    │       │(副本)   │        │(就绪)   │       │(新生产)  │        │
│  └─────────┘       └─────────┘       └─────────┘       └─────────┘        │
│       │                 │                 │                 │              │
│       └─────────────────┴─────────────────┴─────────────────┘              │
│                        持续数据同步                                          │
│                                                                             │
│  耗时: 10-20分钟      耗时: 10-20分钟    耗时: ~4分钟       耗时: 1-5分钟     │
│  业务影响: 零         业务影响: 零       业务影响: ~28秒断连 业务影响: 零       │
└─────────────────────────────────────────────────────────────────────────────┘

7.2 Phase 1 — Create Blue/Green Deployment

Console

RDS Console → Databases → Select instance → Actions → "Create blue/green deployment"

Fill in the configuration:

Setting	Value
Blue/green deployment name	mysql80-to-84-upgrade
Source instance	Pre-populated with the selected instance
Target engine version	MySQL 8.4.x
DB parameter group	Select the pre-created MySQL 8.4 parameter group

Click "Create blue/green deployment". The system will automatically:

✅ Create a read replica of the source instance (green environment, MySQL 8.0)
✅ Upgrade the green environment to MySQL 8.4
✅ Configure backup policies

CLI Reference:

1
2
3
4
5
aws rds create-blue-green-deployment \
    --blue-green-deployment-name mysql80-to-84-upgrade \
    --source arn:aws:rds:<region>:<account>:db:<your-db-instance> \
    --target-engine-version 8.4 \
    --region <your-region>

Sample Response

1
2
3
4
5
6
7
8
9
10
11
{
    "BlueGreenDeployment": {
        "BlueGreenDeploymentIdentifier": "bgd-xxxxxxxxxxxxx",
        "Status": "PROVISIONING",
        "Tasks": [
            {"Name": "CREATING_READ_REPLICA_OF_SOURCE", "Status": "PENDING"},
            {"Name": "DB_ENGINE_VERSION_UPGRADE", "Status": "PENDING"},
            {"Name": "CONFIGURE_BACKUPS", "Status": "PENDING"}
        ]
    }
}

7.3 Phase 2 — Monitor Deployment Progress

Console

RDS Console → Blue/green deployments → Select deployment → Check status

Status Flow:

1
PROVISIONING → AVAILABLE → SWITCHOVER_IN_PROGRESS → SWITCHOVER_COMPLETED

Task Breakdown

Task	Description	Estimated Duration
CREATING_READ_REPLICA_OF_SOURCE	Create read replica of source instance	10-20 min
DB_ENGINE_VERSION_UPGRADE	Upgrade green environment to 8.4	10-20 min
CONFIGURE_BACKUPS	Configure backup policy	A few minutes

⏱ Total duration: approximately 20-40 minutes. Business completely unaffected during this phase.

CLI Reference:

1
2
3
4
5
6
7
8
9
10
# 查看蓝绿部署状态
aws rds describe-blue-green-deployments \
    --blue-green-deployment-identifier bgd-xxxxxxxxxxxxx \
    --region <your-region>

# 查看绿环境实例详情（实例名格式：{源实例名}-green-{随机字符}）
aws rds describe-db-instances \
    --db-instance-identifier <source-instance>-green-xxxxx \
    --query 'DBInstances[0].{Status:DBInstanceStatus,Version:EngineVersion}' \
    --region <your-region>

Pre-Switchover Validation on the Green Environment (Critical Step)

Once the deployment status reaches AVAILABLE, validate the green environment:

Connect to the green instance:

1
mysql -h <green-instance-endpoint> -u admin -p -e "SELECT VERSION();"

Check replication lag:

1
2
3
-- 在绿环境上执行
SHOW REPLICA STATUS\G
  -- Ensure Seconds_Behind_Master is close to 0

Verify data integrity:

1
2
  -- Compare row counts
SELECT COUNT(*) FROM core_business_table;

Run application compatibility tests:

- Point a UAT/staging environment to the green instance
- Execute core business scenarios

7.4 Phase 3 — Execute Switchover

⚠️ Before switching, ensure:

Deployment status is AVAILABLE
Replication lag is near 0 (Seconds_Behind_Master = 0)
Application compatibility tests on the green environment have passed
Relevant teams have been notified

Console

RDS Console → Blue/green deployments → Select deployment → Actions → "Switch blue/green deployment"

Configure the switchover timeout (keeping the default of 300 seconds is recommended):

Setting	Description	Recommended Value
Switchover timeout	Max time to wait for replication catch-up	300 seconds

Click "Switch and confirm".

CLI Reference:

1
2
3
4
aws rds switchover-blue-green-deployment \
    --blue-green-deployment-identifier bgd-xxxxxxxxxxxxx \
    --switchover-timeout 300 \
    --region <your-region>

Switchover Timeline

The following is based on actual test data (for reference only; actual times vary by instance configuration):

1
2
3
4
5
6
7
8
9
10
11
12
Switchover Timeline (Measured Data):
────────────────────────────────────────────────────────────────
08:33:35  切换开始，TPS 正常               (~263 tps)
08:33:51  TPS 开始下降，出现写入错误       (err/s: 142)
08:33:52  TPS=0，写入完全阻塞
08:36:47  连接完全中断                     (QPS=0)
08:37:00  DNS 切换完成
08:37:30  切换完成，连接恢复
────────────────────────────────────────────────────────────────
⏱ 总切换时间:     ~4 分钟
💥 完全断连时间:   ~28 秒
📦 数据丢失量:     0

Instance Name Changes During Switchover

1
2
3
4
5
6
7
Before switchover:
  mysql-prod          → MySQL 8.0（生产，蓝环境）
  mysql-prod-green-xxx → MySQL 8.4（绿环境，副本）

After switchover:
  mysql-prod          → MySQL 8.4 ✓（新生产，原绿环境提升）
  mysql-prod-old1     → MySQL 8.0（原生产，可用于回滚）

Key point: The original instance's endpoint/CNAME remains unchanged — applications don't need connection string modifications.

7.5 Phase 4 — Validation & Cleanup

Verify Switchover Status

Console:
RDS Console → Blue/green deployments → Confirm status is SWITCHOVER_COMPLETED

Verify New Version

1
mysql -h <your-rds-endpoint> -u admin -p -e "SELECT VERSION();"

Clean Up Resources

After confirming the new version is running correctly, clean up the blue/green deployment:

Console:
RDS Console → Blue/green deployments → Select → Actions → Delete

[可选删除旧实例]

CLI Reference:

1
2
3
4
5
6
7
8
9
10
# 保留旧实例（推荐，保留回滚能力 24-48 小时）
aws rds delete-blue-green-deployment \
    --blue-green-deployment-identifier bgd-xxxxxxxxxxxxx \
    --region <your-region>

# 确认后再手动删除旧实例
aws rds delete-db-instance \
    --db-instance-identifier <your-db-instance>-old1 \
    --skip-final-snapshot \
    --region <your-region>

8. Post-Upgrade Validation

8.1 Version Confirmation

1
SELECT @@VERSION, @@VERSION_COMMENT;

8.2 Check Key Parameters

1
2
3
4
5
6
7
8
9
10
11
-- 检查认证插件相关
SELECT user, host, plugin FROM mysql.user;

-- 检查 authentication_policy
SHOW VARIABLES LIKE 'authentication_policy';

-- 检查 IO 相关参数
SHOW VARIABLES LIKE 'innodb_io_capacity%';

-- 检查日志缓冲
SHOW VARIABLES LIKE 'innodb_log_buffer_size';

8.3 Check Replication Status (if read replicas are attached)

1
2
SHOW REPLICA STATUS\G
-- 确认 Slave_IO_Running = Yes, Slave_SQL_Running = Yes

8.4 Functional Verification Checklist

Check Item	Expected Result	Status
Application connects successfully	✅ Connection OK	□
Read/write operations work	✅ CRUD operations OK	□
Stored procedures/functions work	✅ No errors	□
Backups work	✅ Manual snapshot succeeds	□
Monitoring & alerts work	✅ CloudWatch metrics OK	□

8.5 Performance Comparison (Optional)

Compare key performance metrics before and after the upgrade:

Metric	Pre-Upgrade (8.0)	Post-Upgrade (8.4)	Change
TPS	—	—	— %
QPS	—	—	— %
95% 延迟	—	—	— %
Connections	—	—	— %

9. Rollback Plans

9.1 Method A — Switch Back via Blue/Green (Recommended, Before Cleanup)

If an issue is found and the blue/green deployment hasn't been deleted:

1
2
3
# 方法 1：再次执行蓝绿切换，切回旧实例
# 旧实例（-old1）此时仍为 MySQL 8.0，可被识别为新的绿环境
# 但注意：此方法在 AWS 控制台操作可能受限

Console:
RDS Console → Modify application connection string to point to the old instance endpoint

9.2 Method B — Update Application Connection String

After switchover, the old instance is renamed to {instance-name}-old1 (running MySQL 8.0):

1
2
# 旧实例 endpoint
<your-db-instance>-old1.xxxxxxxxxxxx.<region>.rds.amazonaws.com

Simply point your application's database connection string to this endpoint for fast rollback.

9.3 Method C — Restore from Snapshot (Universal Rollback)

1
2
3
4
5
# 从升级前创建的快照恢复
aws rds restore-db-instance-from-db-snapshot \
    --db-instance-identifier <your-db-instance>-rollback \
    --db-snapshot-identifier pre-upgrade-snapshot-202607 \
    --region <your-region>

10. Case Study — Simulating a Real-World Upgrade

10.1 Test Environment Configuration

Item	Configuration
Source instance	RDS MySQL 8.0.40, db.r7g.large, Multi-AZ
Target version	RDS MySQL 8.4.x
Upgrade method	Blue/Green Deployment
Benchmark tool	sysbench 1.0.20
Test data	250 tables × 25,000 rows each
区域	ap-southeast-1

10.2 Simulate Business Workload

Use sysbench to generate continuous read/write load during the upgrade, simulating a real business scenario:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# 准备测试数据
sysbench /usr/share/sysbench/oltp_read_write.lua \
    --mysql-host=<your-rds-endpoint> \
    --mysql-user=admin \
    --mysql-password=<password> \
    --mysql-db=sbtest \
    --tables=250 \
    --table-size=25000 \
    --threads=8 \
    prepare

# 运行持续负载（在升级全程保持运行）
sysbench /usr/share/sysbench/oltp_read_write.lua \
    --mysql-host=<your-rds-endpoint> \
    --mysql-user=admin \
    --mysql-password=<password> \
    --mysql-db=sbtest \
    --tables=250 \
    --table-size=25000 \
    --threads=8 \
    --time=3600 \
    --report-interval=10 \
    run

10.3 Real-Time Health Checks

Open two additional terminal windows to monitor read and write health:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# 终端 1：持续监控数据库版本和状态
while true; do
  mysql -h <your-rds-endpoint> -u admin -p"<password>" \
    -e "SELECT NOW(), @@hostname, @@VERSION, @@global.innodb_read_only;" \
    -s -N 2>/dev/null
  sleep 1
done

# 终端 2：持续写入监控
while true; do
  mysql -h <your-rds-endpoint> -u admin -p"<password>" \
    sbtest -e "INSERT IGNORE INTO sbtest1(k, c, pad) VALUES(1, 'health-check', 'test-123456');" \
    2>/dev/null
  sleep 1
done

10.4 Execute the Upgrade

Follow the steps in Section 7 to perform the blue/green upgrade.

10.5 Record Key Timestamps

Use scripts to automatically log key events:

1
2
3
4
5
6
7
8
9
10
11
12
13
# 切换开始
echo "$(date) - 开始执行切换" >> upgrade_timeline.log

# 定期监控状态（每 5 秒）
while true; do
  STATUS=$(aws rds describe-blue-green-deployments \
    --blue-green-deployment-identifier bgd-xxxxxxxxxxxxx \
    --query 'BlueGreenDeployments[0].Status' \
    --output text \
    --region <your-region> 2>/dev/null)
  echo "$(date) - 状态: $STATUS" >> upgrade_timeline.log
  sleep 5
done

10.6 Expected Test Results

Phase	Expectation	Verification Method
Create blue/green deployment	~20-40 min, no business impact	sysbench continues without errors
Green environment available	Connectable and queryable	Direct connection to green endpoint
Switchover starts	TPS begins dropping	sysbench reports TPS reaching zero
Switchover completes	Connections restored after DNS switch	sysbench resumes counting
Complete outage	Expected < 30 seconds	Health check script outage duration
Version verified	MySQL 8.4.x	SELECT VERSION()
Data integrity	No data loss	Compare row counts / checksum

10.7 Clean Up Test Resources

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# 删除蓝绿部署
aws rds delete-blue-green-deployment \
    --blue-green-deployment-identifier bgd-xxxxxxxxxxxxx \
    --region <your-region>

# 可选：删除旧实例
aws rds delete-db-instance \
    --db-instance-identifier <your-db-instance>-old1 \
    --skip-final-snapshot \
    --region <your-region>

# 如果不再需要：删除测试数据
sysbench /usr/share/sysbench/oltp_read_write.lua \
    --mysql-host=<your-rds-endpoint> \
    --mysql-user=admin \
    --mysql-password=<password> \
    --mysql-db=sbtest \
    cleanup

11. Summary & Best Practices

11.1 Upgrade Decision Tree

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
┌─────────────────────┐
│ 准备升级 RDS MySQL  │
│ 8.0 → 8.4          │
└─────────┬───────────┘
          │
          ▼
┌─────────────────────────┐
│ ✅ 完成兼容性检查       │
│ ✅ 创建自定义参数组     │
│ ✅ 检查认证插件兼容     │
│ ✅ 备份 + 快照         │
└─────────┬───────────────┘
          │
          ▼
┌─────────────────────────┐
│  选择升级方法           │
│                         │
│  生产环境？──→ 蓝绿部署  │
│  开发/测试？──→ 就地升级  │
└─────────┬───────────────┘
          │
          ▼
┌─────────────────────────┐
│  执行升级               │
│  验证运行状况            │
│  观察 24-48 小时        │
└─────────┬───────────────┘
          │
          ▼
┌─────────────────────────┐
│  ✅ 升级完成            │
│  🗑️ 清理蓝绿部署资源    │
│  📝 更新运维文档        │
└─────────────────────────┘

11.2 Best Practice Checklist

Timing

✅ Schedule switchover during business low-traffic periods
✅ Allow sufficient monitoring and rollback time (at least 2-4 hours)
✅ Avoid holiday weekends

Testing

✅ Always run a full dry-run in a test environment first
✅ Run all application integration tests against the upgraded environment
✅ Verify parameter group compatibility with MySQL 8.4

Performance

✅ Tune innodb_io_capacity and innodb_io_capacity_max based on your disk IOPS after upgrade
✅ Consider switching to Graviton3/4 instances during the upgrade
✅ For workloads wanting less frequent upgrades, consider Aurora LTS versions

Monitoring & Communication

✅ Configure CloudWatch alarms ahead of time
✅ Prepare real-time monitoring scripts (read/write health checks)
✅ Notify all relevant teams in advance

Rollback Safeguards

✅ Keep the old instance for at least 24-48 hours
✅ Retain pre-upgrade snapshots for at least 7 days
✅ Have a written rollback procedure and scripts ready

11.3 Critical Warnings

🔴 Most common pitfalls:

Authentication plugin incompatibility — Verify your client libraries support caching_sha2_password before upgrading
innodb_io_capacity too high — Default is 10000 in 8.4; insufficient disk IOPS can cause 7%-22% write performance degradation
Replication syntax CHANGE MASTER → SOURCE — Update external replication scripts
Legacy client incompatibility — MySQL Connector/J and other old clients need upgrading

Builder Center

Step-by-Step Guide: Upgrading AWS RDS MySQL from 8.0 to 8.4

Lei Feng

AWS RDS MySQL 8.0 to 8.4 Upgrade — Complete Guide

Table of Contents

1. Introduction

2. Version Lifecycle & Why Upgrade

2.1 Key Milestones

2.2 Impact After Support Ends

3. Pre-Upgrade Preparation — Compatibility Checklist

3.1 Check Current Instance Status

3.2 Verify Available Target Versions

3.3 SQL Syntax Compatibility Check

Method A: MySQL Shell Upgrade Checker

Method B: Manual Compatibility Checklist

Notable SQL Changes in MySQL 8.4:

3.4 Parameter Group Preparation

3.5 Enable Automated Backups

3.6 Create a Pre-Upgrade Snapshot (Final Safety Net)

4. MySQL 8.4 Key Changes & Precautions

4.1 Authentication Plugin Changes (⚠️ Highest Risk)

4.2 Security Improvements

4.3 New Privileges

4.4 Removed Parameters and Variables

4.5 Performance Summary

4.6 Histogram Auto-Update

5. Upgrade Method Comparison & Selection

5.1 Method Overview

5.2 Selection Guide

6. Method A — In-Place Upgrade via Console

6.1 Step-by-Step

Step 1: Open the Modify Instance Page

Step 2: Change DB Engine Version

Step 3: Associate the New Parameter Group

Step 4: Apply the Modification

Step 5: Monitor Upgrade Progress

6.2 Monitoring Scripts During Upgrade (Optional)

6.3 Pros & Cons

7. Method B — Blue/Green Deployment Upgrade (Recommended)

7.1 Overall Flow

7.2 Phase 1 — Create Blue/Green Deployment

Console

CLI Reference:

Sample Response

7.3 Phase 2 — Monitor Deployment Progress

Console

Task Breakdown

CLI Reference:

Pre-Switchover Validation on the Green Environment (Critical Step)

7.4 Phase 3 — Execute Switchover

Console

CLI Reference:

Switchover Timeline

Instance Name Changes During Switchover

7.5 Phase 4 — Validation & Cleanup

Verify Switchover Status

Verify New Version

Clean Up Resources

8. Post-Upgrade Validation

8.1 Version Confirmation

8.2 Check Key Parameters

8.3 Check Replication Status (if read replicas are attached)

8.4 Functional Verification Checklist

8.5 Performance Comparison (Optional)

9. Rollback Plans

9.1 Method A — Switch Back via Blue/Green (Recommended, Before Cleanup)

9.2 Method B — Update Application Connection String

9.3 Method C — Restore from Snapshot (Universal Rollback)

10. Case Study — Simulating a Real-World Upgrade

10.1 Test Environment Configuration

10.2 Simulate Business Workload

10.3 Real-Time Health Checks

10.4 Execute the Upgrade

10.5 Record Key Timestamps

10.6 Expected Test Results

10.7 Clean Up Test Resources

11. Summary & Best Practices

11.1 Upgrade Decision Tree

11.2 Best Practice Checklist

Timing