mysqldump vs mysqlpump vs MyDumper: Current Guide

The current MySQL logical-backup choice is between mysqldump, MySQL Shell dump and load utilities, and the community MyDumper/myloader pair. mysqlpump is legacy-only: Oracle deprecated it in MySQL 8.0.34 and removed it, together with lz4_decompress and zlib_decompress, in MySQL 8.4. Do not design a new backup workflow around it.

Choose from recovery requirements, not database size

No database-size threshold selects the right tool. Begin with the maximum tolerable data loss, recovery-time objective, required restore granularity, engine mix, version or platform migration needs, available I/O, and the load a dump may place on the source. A small database with a strict recovery objective can need a different design from a much larger archival database.

mysqldump: the portable baseline

mysqldump produces SQL that can be reviewed and loaded with the mysql client. For an InnoDB-only schema, --single-transaction starts a repeatable-read transaction so application writes do not require table locks. --quick retrieves rows a row at a time instead of buffering an entire large table in client memory.

mysqldump \
  --single-transaction \
  --quick \
  --routines \
  --events \
  --triggers \
  --databases appdb \
  > /secure/backups/appdb.sql

Keep credentials out of process arguments and shell history by using an approved option file, login path, or secret-injection mechanism with restrictive permissions. The example is a starting shape, not a complete backup policy: decide whether users, grants, GTID state, binary-log coordinates, tablespaces, and other server objects belong in the recovery set for the exact MySQL version and destination.

Restore the file first into an empty, access-controlled validation instance:

mysql --database=restore_validation < /secure/backups/appdb.sql

Do not aim a test restore at production or an instance containing data you need. A successful client exit is only the beginning of validation; check expected schemas, objects, row-level invariants, application reads, and the ability to apply retained binary logs when point-in-time recovery is required.

MySQL Shell: the current Oracle parallel path

MySQL Shell provides instance, schema, and table dump utilities plus util.loadDump(). The utilities write multiple files and can split table data into chunks. Each dump thread opens its own connection; the documented default is four, and additional threads increase source connections, CPU, I/O, and destination load. Select concurrency from a representative test rather than a copied thread count.

// MySQL Shell JavaScript mode; 8 is an illustrative tested value.
util.dumpInstance("/secure/backups/instance-2026-08-01", {
  threads: 8,
  consistent: true
})

// Connect to an isolated target first.
util.loadDump("/secure/backups/instance-2026-08-01", {
  threads: 8,
  dryRun: true
})

Use a new output location and confirm space, permissions, encryption, and transport controls. With consistent: true, the utilities coordinate consistent snapshots across dump threads using locks and transactions as documented; the required privileges and fallback behavior matter. A dry run reports planned work and compatibility problems but does not prove that data restores correctly. Follow it with a real load into an isolated target and a timed verification.

MySQL Shell is not simply a faster spelling of mysqldump. It has its own dump format, compatibility options, progress files, load controls, and version requirements. Pin and record the Shell version used to create and load each archive.

MyDumper and myloader: qualify the exact release

MyDumper is a community project that pairs the parallel mydumper export tool with myloader for parallel loading. Its directory-based files can make table selection, chunking, transfer, and parallel restore practical. This also adds a packaging and support dependency that the team must own.

Do not copy command flags from an old article into production. Read the documentation for the exact MyDumper release, test its consistency mode with your mix of transactional and nontransactional tables, and verify behavior during concurrent DDL. Choose thread and chunk settings from measured source latency, replica lag, CPU, I/O, free space, file count, and restore performance. Store the tool version and configuration with the backup manifest.

MyDumper's potential advantage is parallel work on both sides of recovery, not a guaranteed speed multiplier. Table distribution, row width, compression, indexes, storage, network, and destination write capacity determine the result. Benchmark the full dump-transfer-load-validation path on production-shaped data.

mysqlpump: migrate legacy jobs and archives

MySQL 8.0.34 emits a deprecation warning for mysqlpump and directs users to mysqldump or MySQL Shell utilities. MySQL 8.4 removes mysqlpump and its LZ4 and zlib decompression helper programs. The correct production action is to replace the dependency before an 8.4 upgrade, not to copy an obsolete binary onto the upgraded database host.

1. Inventory: find scheduled jobs, container images, packages, runbooks, monitoring, output naming, filters, user/grant handling, and archives that depend on mysqlpump or its compression formats.
2. Classify: record the producing MySQL client version, checksum, compression format, encryption method, source version, and intended recovery scope for every retained archive.
3. Recover safely: when an old compressed archive needs conversion, use an isolated, access-controlled compatibility environment with an approved matching MySQL 8.0 client package. Verify checksums, decompress or restore there, and never install deprecated utilities on a production 8.4 host.
4. Convert: validate the recovered database, then create a new archive with a supported current tool and document its restore procedure.
5. Replace automation: implement and canary either mysqldump, MySQL Shell, or a qualified MyDumper release. Update alerts so a warning, partial directory, missing manifest, or failed verification cannot be reported as success.
6. Prove recovery: complete a timed restore and point-in-time exercise before removing the legacy job or compatibility environment.

This process preserves useful filtering, account-export, progress, compression, and parallelism requirements from the old job without preserving the removed executable. Keep the legacy environment only for the minimum approved retention period and restrict its access.

Logical and physical backups solve different problems

Logical tools reconstruct schema and rows through SQL or a logical load protocol. That helps with selective restore and many migrations, but recovery must parse and rebuild data and indexes. Physical backups copy engine files and logs and can better fit some full-instance recovery objectives, but their version, platform, and engine compatibility is narrower.

Do not infer that either format is complete on its own. A production strategy may combine logical exports, a supported physical or managed-service backup, and retained binary logs. Map each artifact to a recovery scenario, ownership, retention, encryption key, off-site copy, and tested restore sequence.

Validate the backup contract

1. Record tool and server versions, options, timestamps, source identity, GTID or binary-log position when required, file list, sizes, and cryptographic checksums.
2. Confirm the dump includes the required tables, views, routines, events, triggers, users, grants, and configuration-dependent objects.
3. Load into an isolated target with the intended destination version and character set.
4. Run schema diffs, data invariants, foreign-key and application smoke checks; row counts alone can miss corruption or inconsistency.
5. Exercise point-in-time recovery if it is part of the objective, and measure the entire recovery through application readiness.
6. Test failure cases such as interrupted transfer, full disk, expired credentials, missing encryption keys, and a dump created during DDL.

A backup is operationally useful only when the team can restore the required state within its measured objective. Keep evidence from recurring drills and revisit the choice when versions, data shape, workload, or recovery requirements change.

Official primary sources

• MySQL 8.0.34 release notes: mysqlpump deprecation
• MySQL 8.4.0 release notes: mysqlpump removal
• MySQL 8.4 mysqldump reference
• MySQL Shell dump utilities
• MySQL Shell dump loading utility
• Official MyDumper project

Working with JusDB on MySQL recovery

JusDB helps teams replace legacy backup jobs, choose logical and physical recovery layers, and prove the result through isolated restore and point-in-time exercises.

Explore JusDB MySQL services →  |  Talk to a database engineer