DMS MySQL migration fails with "waitid: no child processes" — recurring across different configs

Google Cloud Database
1

I’m running a Database Migration Service (DMS) continuous migration from
Amazon RDS for MySQL 8.0 to Cloud SQL for MySQL, using Reverse-SSH Tunnel
connectivity (VPC Peering doesn’t work in my topology — confirmed via
packet capture that DMS traffic never reaches my VPC through peering).

Source database has an unusual shape: ~2,577 separate schemas
(multi-tenant SaaS, one schema per tenant), ~15GB total data.

The migration repeatedly fails during full-dump with:

DUMP_STAGE(FAILED): failed to import with MySQL Shell:
dump instance failed: waitid: no child processes

This has recurred twice under different conditions:

  1. First on a 4GB RAM destination instance (also hit a separate
    OOM “signal: killed” error)
  2. Again after scaling to 8 vCPU/32GB RAM AND fixing a GTID config
    issue on the source (gtid_mode staged from OFF_PERMISSIVE to
    fully ON)

Since it recurred on a much larger instance with correct GTID, I don’t
think it’s memory or GTID related. Connectivity is confirmed solid —
“Test job” passes cleanly every time, and I’ve verified the tunnel
manually via direct mysql client connection.

For context: the job ran for roughly 20 hours before failing, and had
successfully synced ~2GB of data across 100+ of the 2,577 schemas with
zero errors up to that point — although quite slow — so it’s not an
immediate/config-level failure, but something that eventually trips
after a long sustained run.

Has anyone seen this specific error, especially with a high schema-count
source database? Is there a practical limit on schema count DMS can
reliably handle in one job?

If anyone has successfully handled a migration with this many schemas, I’d appreciate any advice on whether I’m missing something in my setup or approach.

Thanks

1 Like