  If you’re migrating a large MySQL database and you’re not 
  using mydumper/myloader, you’re doing it the hard way.

If you aren't using xtrabackup you are doing it wrong. I recently migrated a database with 2TB of data from 5.7 to 8.4 with about 15 seconds of down time. It wouldn't have been possible without xtrabackup. Mysqldumper requires a global write block, I wouldn't call blocking writes for hours a "zero downtime migration".

▲ embedding-shape 5 hours ago | parent [-]

Correct me if I'm wrong, but done with a proxy in-between that can "pause" requests, you could have done the move with 0 seconds and no rejected requests, and I don't think mydumper/myloader/xtrabackup matters for that. The "migration" would be spinning up a new database, making it catch up, then switching over. If you can pause/hang in-flight requests while switching, not a single one needs to fail :)

▲

jpablo 4 hours ago | parent [-]

The "making it catch up" is the tricky part. You need an initial backup for that. xtrabackup can take that backup "hot" without blocking read/writes. mysqldumper will block writes for whatever time that initial backup takes, for 2TB of data that's going to be hours.

Once you have that initial back up you can set your replica and make it catch up , then you switch. I choose to take the few seconds of downtime doing the switch because for my use case that was acceptable.

▲

embedding-shape 3 hours ago | parent [-]

Isn't that just a flag? "--lock-tables=false", alternatively --single-transaction for InnoDB.

	▲	jpablo 2 hours ago \| parent [-]
		If you want a consistent backup that you can use to setup a replica you need to block writes while the backup is taken, take the backup while the database is shutdown OR use xtrabackup.