pt-online-schema-change praktisch einsetzen: Schema-Änderungen ohne Lock

1. Warum natives Online DDL nicht jedes Problem löst

Natives Online DDL mit ALGORITHM=INPLACE arbeitet zuverlässig, solange die Operation innerhalb der konfigurierten Grenzen bleibt. Bei sehr schreibintensiven Tabellen, etwa einer aktiven Warenkorb- oder Sitzungstabelle mit tausenden Änderungen pro Minute, kann der interne Row-Log jedoch an die konfigurierte Obergrenze innodb_online_alter_log_max_size stoßen. Die Folge ist ein vollständiger Rollback nach unter Umständen stundenlanger Laufzeit, ohne dass auch nur eine einzige Änderung übernommen wurde.

Zusätzlich benötigt selbst eine inplace-fähige Operation zu Beginn und am Ende einen kurzen, aber exklusiven Metadata Lock. Bei einer Tabelle mit dauerhaft hoher Parallelität kann bereits dieser kurze Moment zu spürbaren Wartezeiten in der Anwendung führen. Für genau diese Fälle wurde pt-online-schema-change entwickelt: ein Kommandozeilenwerkzeug, das komplett außerhalb des InnoDB-eigenen Online-DDL-Mechanismus arbeitet und dadurch dessen Limitierungen umgeht.

2. Die Grundarchitektur: Shadow Table statt interner Rebuild

pt-online-schema-change legt zunächst eine leere Kopie der Zieltabelle mit der neuen Struktur an, die sogenannte Shadow Table, meist mit einem Präfix wie _tablename_new. Anschließend wendet es die gewünschte ALTER-Anweisung ausschließlich auf diese neue, noch leere Tabelle an, was bei einer leeren Tabelle unabhängig von der Zielgröße der Originaltabelle nahezu sofort abgeschlossen ist. Erst danach beginnt die eigentliche Kopierarbeit.

Um während der Kopierphase keine Änderungen an der Originaltabelle zu verpassen, installiert das Tool drei Trigger auf der Originaltabelle: für INSERT, UPDATE und DELETE. Jede Änderung an der Originaltabelle wird dadurch synchron in Echtzeit auf die Shadow Table gespiegelt, während gleichzeitig im Hintergrund der bestehende Datenbestand in Chunks kopiert wird. So bleiben Original und Shadow Table durchgehend konsistent, ohne dass ein globaler Lock nötig wäre.

# Trockenlauf ohne tatsaechliche Änderung an der Datenbank
pt-online-schema-change --dry-run --alter="ADD INDEX idx_status_created (status, created_at)" D=magento,t=sales_order_grid

# Tatsaechliche Ausführung nach erfolgreichem Dry-Run
pt-online-schema-change --execute --alter="ADD INDEX idx_status_created (status, created_at)" D=magento,t=sales_order_grid

3. Der Trigger-Mechanismus im Detail

Die drei von pt-online-schema-change erzeugten Trigger sind bewusst minimalistisch gehalten. Der INSERT-Trigger fügt jede neue Zeile identisch auch in die Shadow Table ein, der UPDATE-Trigger repliziert Änderungen an bereits kopierten Zeilen, der DELETE-Trigger entfernt gelöschte Zeilen auch aus der Shadow Table. Da diese Trigger synchron innerhalb derselben Transaktion wie die ursprüngliche Schreiboperation ausgeführt werden, bleibt die Konsistenz garantiert, allerdings um den Preis eines zusätzlichen Schreibvorgangs pro Anwendung.

Genau dieser synchrone Overhead ist der zentrale Unterschied zu binlog-basierten Alternativen wie gh-ost. Bei extrem hoher Schreiblast, etwa mehreren tausend Inserts pro Sekunde auf einer Log- oder Sitzungstabelle, kann der zusätzliche Trigger-Aufwand die effektive Schreib-Performance der Anwendung spürbar senken, solange die Migration läuft. Für die meisten Magento-typischen Tabellen mit moderater Schreiblast bleibt der Effekt jedoch kaum messbar.

4. Chunk-Copy und der Nibble-Iterator

Den bestehenden Datenbestand kopiert pt-online-schema-change nicht in einer einzigen langen Transaktion, sondern in kleinen, aufeinanderfolgenden Blöcken, die über den Primärschlüssel abgegrenzt werden. Dieser sogenannte Nibble-Iterator berechnet fortlaufend Wertebereiche des Primärschlüssels und kopiert jeweils nur die Zeilen innerhalb eines Bereichs in einer eigenen, kurzen Transaktion. Das begrenzt sowohl die Dauer einzelner Locks als auch den Umfang, den ein einzelner Rollback im Fehlerfall betreffen würde.

Die Größe eines einzelnen Chunks lässt sich über --chunk-size fest vorgeben oder über --chunk-time adaptiv steuern, sodass jeder Chunk im Schnitt eine Zielzeit von beispielsweise 0,5 Sekunden nicht überschreitet. Bei Systemen mit stark schwankender Last passt sich die Chunk-Größe damit automatisch an die aktuelle Belastung an, kleinere Chunks bei hoher Last, größere bei ruhigeren Phasen.

5. Der atomare Umschaltmoment am Ende der Migration

Sobald der komplette Datenbestand kopiert ist und die Trigger sämtliche zwischenzeitlichen Änderungen nachgezogen haben, folgt der kritischste Schritt: der Austausch von Original- und Shadow Table. pt-online-schema-change nutzt dafür einen atomaren RENAME-Trick mit drei Tabellen gleichzeitig, sodass zu keinem Zeitpunkt weder die alte noch die neue Tabelle unter ihrem regulären Namen fehlt. Anwendungscode, der parallel Anfragen stellt, bemerkt den Wechsel im Idealfall gar nicht.

Dieser Rename-Vorgang benötigt selbst einen kurzen exklusiven Metadata Lock, typischerweise im Bereich weniger Millisekunden bis niedriger einstelliger Sekunden, abhängig davon, wie viele andere Sessions gerade Locks auf der betroffenen Tabelle halten. Danach löscht das Tool die alte Tabelle sowie die drei Trigger und beendet die Migration. Mit der Option --no-drop-old-table lässt sich die alte Tabelle zur Sicherheit noch eine Weile aufheben, bevor sie manuell entfernt wird.

6. Fremdschlüssel: der häufigste Stolperstein

Fremdschlüsselbeziehungen sind die mit Abstand häufigste Fehlerquelle bei pt-online-schema-change. Da die Shadow Table zunächst eine eigenständige Tabelle mit eigenem Namen ist, zeigen bestehende Fremdschlüssel von anderen Tabellen weiterhin auf die alte Tabelle, nicht automatisch auf die neue. Das Tool bietet dafür die Option --alter-foreign-keys-method mit zwei grundsätzlich unterschiedlichen Strategien.

Die Methode rebuild_constraints ändert bei allen referenzierenden Tabellen die Fremdschlüsseldefinition per ALTER TABLE, was selbst wieder Zeit kostet und bei sehr vielen referenzierenden Tabellen aufwendig wird. Die Methode drop_swap ist schneller, benötigt dafür aber kurzzeitig das komplette Deaktivieren der Fremdschlüsselprüfung während des Umschaltmoments, was in Ausnahmefällen zu kurzfristig inkonsistenten Referenzen führen kann, falls parallel Schreibzugriffe stattfinden. Bei stark vernetzten Magento-Tabellen wie catalog_product_entity lohnt sich ein genauer Blick auf beide Strategien vor dem produktiven Einsatz.

7. Trigger-Konflikte und weitere Einschränkungen

Da pt-online-schema-change selbst Trigger auf der Originaltabelle anlegt, verweigert das Tool standardmäßig den Start, sobald auf dieser Tabelle bereits eigene Trigger existieren, etwa aus einem Custom-Modul oder einer alten Magento-1-Migration. Der Grund ist einfach: MySQL erlaubt zwar mehrere Trigger pro Ereignis, doch die Ausführungsreihenfolge und mögliche Seiteneffekte zwischen fremden und eigenen Triggern lassen sich nicht zuverlässig vorhersagen. Mit --preserve-triggers lässt sich dieses Verhalten kontrolliert übersteuern, aber nur nach sorgfältiger Prüfung der bestehenden Trigger-Logik.

Weitere Einschränkungen betreffen Tabellen ohne Primärschlüssel oder eindeutigen Index, bei denen der Nibble-Iterator keine sinnvollen Chunk-Grenzen berechnen kann, sowie replizierte Umgebungen mit aktiven Replikationsfiltern, die das Tool standardmäßig als riskant einstuft und nur mit expliziter Bestätigung akzeptiert. Auch Tabellen mit sehr breiten TEXT- oder BLOB-Spalten können den Kopiervorgang durch hohen I/O-Aufwand pro Chunk spürbar verlangsamen.

# Fremdschluessel-Strategie explizit wählen statt Standardverhalten
pt-online-schema-change --execute --alter="MODIFY COLUMN sku VARCHAR(191) NOT NULL" --alter-foreign-keys-method=rebuild_constraints D=magento,t=catalog_product_entity

# Replikations-Lag auf allen Replicas überwachen und bei Bedarf pausieren
pt-online-schema-change --execute --max-lag=5 --check-slave-lag=h=replica1.internal --alter="ADD COLUMN last_synced_at DATETIME NULL" D=magento,t=sales_order

8. Praktischer Workflow mit Dry-Run und Sicherheitsprüfungen

Ein produktiver Einsatz beginnt immer mit --dry-run, der sämtliche Prüfungen durchführt und die Shadow Table anlegt, aber keine Trigger installiert und keine Daten kopiert. Erst nach einem sauberen Dry-Run folgt der Lauf mit --execute. Das Tool prüft dabei automatisch unter anderem, ob Replikationsfilter aktiv sind, ob die Zieltabelle referenzielle Integrität erfordert und ob genügend freier Speicherplatz für die temporäre Shadow Table zur Verfügung steht.

Für produktive Umgebungen mit Replicas ist --max-lag zusammen mit --check-slave-lag unverzichtbar: das Tool pausiert die Kopierphase automatisch, sobald ein überwachter Replica die konfigurierte Verzögerung überschreitet, und setzt erst fort, wenn der Replica wieder aufgeholt hat. Ergänzend lässt sich mit einer Pause-Datei die gesamte Migration jederzeit manuell anhalten, etwa während eines geplanten Wartungsfensters für andere Arbeiten.

9. Wann pt-online-schema-change gegenüber nativem Online DDL sinnvoll bleibt

Natives ALGORITHM=INSTANT bleibt für unterstützte Operationen immer die schnellste und einfachste Wahl, ein externes Tool bringt hier keinen Vorteil. Sobald eine Operation jedoch zwingend eine Tabellenkopie erfordert, etwa eine inkompatible Datentyp-Konvertierung, oder wenn der native Row-Log auf einer sehr schreibintensiven Tabelle an seine Kapazitätsgrenze stoßen würde, ist pt-online-schema-change häufig die risikoärmere Wahl.

Ein weiterer Vorteil liegt in der Kontrollierbarkeit: Pause-Dateien, Lag-basiertes Throttling und ein sauberer Dry-Run-Modus geben deutlich mehr Steuerungsmöglichkeiten als ein natives ALTER TABLE, das einmal gestartet nur noch abgebrochen, aber nicht pausiert werden kann. Für Migrationen mit sehr hoher, konstanter Schreiblast auf der Zieltabelle ist allerdings gh-ost mit seinem binlog-basierten Ansatz oft die noch bessere Alternative, da es den zusätzlichen Trigger-Overhead vollständig vermeidet.

10. Zusammenfassung

11. FAQ: pt-online-schema-change im Praxiseinsatz