How a DBA safely migrated a 136 GB MySQL table to a new disk at 2 a.m.

A production server running dozens of voice agents faced a critical disk space crisis at 2 a.m., with its root volume at 94% capacity and only hours before scheduled workloads would push it over the limit. A single MySQL table, call_transcripts, occupied 136 GB — roughly 40% of the root disk — making it the prime candidate for relocation to a nearly empty secondary volume with 294 GB free. The engineer ruled out the common symlink workaround, noting that InnoDB can silently replace symlinked tablespace files during routine operations like OPTIMIZE or TRUNCATE, recreating the disk space problem at the worst possible time. Instead, the safe approach leveraged MySQL 8.0's innodb_directories feature, which allows InnoDB to locate tablespace files by their internal space_id rather than a fixed path, enabling an offline move that persists across restarts and DDL operations. The migration required keeping the target directory permanently in the server config and placing the file inside a schema-named subdirectory to comply with InnoDB's file-per-table rules.