Pipe a small database straight into RDS 24 with mysqldump --single-transaction --routines --set-gtid-purged=OFF shop | mysql -h <endpoint> -u admin -p shop. MySQL Shell 524 (Logical Backups) is faster for large ones. Here a mysql:8.4 container on port 3418 stands in for RDS:
mysqlsh root@127.0.0.1:3318 --passwords-from-stdin -- util dump-schemas shop \
--outputUrl=shop-dump --threads=4 <<< secret 2>&1 | grep -E '^(Schemas|Rows)'
mysqlsh root@127.0.0.1:3418 --passwords-from-stdin -- util load-dump shop-dump \
--threads=4 <<< secret 2>&1 | grep -E '^(Target|[0-9]+ (chunks|warn))' | cut -c1-75Schemas dumped: 1 Rows written: 53 Target is MySQL 8.4.11. Dump was produced from MySQL 9.7.2 6 chunks (53 rows, 2.08 KB) for 6 tables in 1 schemas were loaded in 0 sec 0 warnings were reported during the load.
No ignoreVersion option was needed, because 8 and 9 are consecutive major versions; it works only while the schema uses nothing newer than 8.4, such as VECTOR. It runs LOAD DATA LOCAL INFILE, so the target needs local_infile set to 1.
For near-zero downtime, load the dump, make RDS a replica of the old server with CALL mysql.rds_set_external_source_with_auto_position(...) (Replication and GTIDs), wait for zero lag, set the old server read_only, and point PHP at the new endpoint. AWS 24 DMS does the same across engines: a full load, then ongoing changes. Compare CHECKSUM TABLE on both sides first.