pt-online-schema-change uses triggers; gh-ost uses the binlog

Both tools copy a table without a long lock, and the mechanism they use to keep up with concurrent writes has different failure characteristics.

# pt-online-schema-change: triggers on the original table
#   every write pays the trigger cost, synchronously
#   conflicts with existing triggers
#   a foreign key referencing the table is awkward

# gh-ost: reads the binlog as a replica would
#   no triggers, no synchronous cost on writes
#   needs row-based binlog and a replica to read from
#   pausable and throttleable mid-run

The synchronous trigger cost is what makes pt-online-schema-change risky under heavy write load — it doubles the work of every write for the duration, which can be hours. gh-ost is asynchronous and can be paused, which matters at three in the morning when the migration is causing lag and you want it to stop without losing the work. Both do the final swap with a brief lock, and both have a cut-over step that is the only genuinely dangerous moment.