MySQL Online Schema Change Plan Prompt

You are a senior MySQL/MariaDB DBA who runs online schema changes on large tables without downtime. You know gh-ost (binlog-based, triggerless) and pt-online-schema-change (trigger-based), their ghost/shadow-table-plus-cut-over model, foreign-key handling, throttling on replica lag, and the failure modes of each.

I will provide:
- The desired change: [PASTE ALTER TABLE STATEMENT]
- `SHOW CREATE TABLE` for the target (size, indexes, foreign keys, triggers): [PASTE SCHEMA]
- Approximate row count / table size on disk and current write rate: [PASTE]
- Topology: replicas, whether the app tolerates a brief metadata-lock cut-over, and any existing triggers/FKs: [DESCRIBE]

Produce a migration plan:

1. **Pick the tool.** Recommend gh-ost or pt-online-schema-change for this table and justify it — gh-ost if you want triggerless binlog-based copy and pausable migrations; pt-osc if gh-ost can't run here. Call out foreign keys and existing triggers explicitly, since they constrain both tools.
2. **Assess the change's safety.** Is it instant/in-place (some ALTERs are metadata-only) or a full table rebuild? Does it risk data loss (narrowing a column, NOT NULL on existing nulls, charset change)?
3. **Define throttling.** Set max replica lag and load thresholds so the copy backs off automatically and never starves the primary or blows out replication lag.
4. **Write the exact command** (gh-ost or pt-osc) with flags: dry-run first, throttle controls, chunk size, and cut-over behaviour. Include the --execute step separately so the dry-run is reviewed first.
5. **Plan the cut-over and rollback.** Describe the brief lock at swap time, how to abort mid-migration, and how to keep/drop the old table for a safe rollback window.

Output: (a) Tool choice with rationale, (b) Safety assessment of the ALTER, (c) Dry-run command, (d) Execute command with throttling, (e) Cut-over and rollback plan, (f) Risks.

Guardrails: always run a dry-run / --no-swap first and review it; back up the table before executing; throttle on replica lag so replicas never fall dangerously behind; foreign keys and triggers can make these tools unsafe — verify before running; keep the old table until you have confirmed success; never execute a real cut-over on prod without review.