Move the database in pieces, not in one night

SQLDumpSplitter » Use cases » Migration and consolidation

Download SQLDumpSplitter Free Trial »     Buy SQLDumpSplitter Now »

The situation

A database has to move - to a new server, to a cloud platform, or into a consolidated instance that will replace three older ones. The plan is a dump and restore, and the dump is enormous. That leaves one long, all-or-nothing import: if it fails at 80%, you start again, and the maintenance window is rarely long enough to find that out twice.

Consolidating several databases is the same problem multiplied: each dump has to land in the same target, and a failure in any one of them stalls the whole cut-over.

What you do

  1. Split each dump by table, so the migration becomes a series of table-sized steps rather than one job.
  2. Migrate in dependency order - reference tables first, then the big transactional ones - and verify each table as it lands.
  3. For the largest tables, split by row count as well and load them in chunks, so a failure costs one chunk instead of the whole table.
  4. Keep the split files: if something has to be re-run, the pieces are already there and the order is already decided.

Splitting a large SQL dump by row count for a staged migration

Because each file is split along SQL statement boundaries, every part is valid SQL that runs on its own - which is exactly what makes the migration restartable. The original dump is never modified, and the encoding is preserved.

Where the split stops

Be clear about what this does and does not cover:

Related

Splitting: by table, by row count, by file size. Copying directly between live databases: DBCopier. Exporting a live database to a dump in the first place: DBToFile.