Question
YSQL online DDL rollback safety after committed ALTER TABLE in YugabyteDB 2.x
Sora Echo
0 reputation · 21 Aug 2023, 12:42 UTC
132.9K views
Loading…
0 reputation · 21 Aug 2023, 12:42 UTC
Determine whether a committed YSQL ALTER TABLE can be safely rolled back in YugabyteDB 2.x after the distributed master catalog and tablet leaders adopt the new catalog version.
Online DDL is applied incrementally across tablets rather than as a single-node atomic commit, so clients attached to different nodes can temporarily observe different schema states. Forward-only migration guidance implies that rollback after a committed DDL is not guaranteed once catalog updates propagate. Safety may depend on the ALTER operation, cluster health, tablet leader placement, and concurrent writes, and the exact boundary is version-sensitive.
Confirm the exact boundary in the release notes for the target release before relying on any rollback behavior.
Is rollback supported for a committed ALTER TABLE after catalog version propagation? Which ALTER types, if any, permit automatic reversion without manual catalog repair? What compatibility boundary separates safe forward-only changes from changes requiring manual intervention?
Once a YSQL ALTER TABLE is committed and the new catalog version has propagated to tablet leaders, there is no built‑in rollback mechanism to revert the schema state. The operation is forward‑only; to return to the previous definition you must execute an inverse DDL statement (e.g., DROP COLUMN to undo an ADD COLUMN), which creates a new catalog version rather than truly rolling back.
yugabytedbALTER TABLE statement was executed (this determines whether an inverse DDL is feasible).yb_server_status or the internal ysql_catalog_version metric on all nodes and ensure they report the same version.ADD COLUMN, RENAME COLUMN), run the corresponding inverse DDL:ALTER TABLE tbl DROP COLUMN new_col; to undo ADD COLUMN new_col TYPE;ALTER TABLE tbl RENAME COLUMN new_col TO old_col; to undo a rename.catalog version mismatch errors from clients and retry transactions as needed.If the ALTER TABLE performed was a destructive change (drop column, type change, adding NOT NULL), the answer shifts from "run inverse DDL" to "rollback is not possible; restore from backup." Knowing the exact ALTER type is therefore the single missing diagnostic detail that changes the recommendation.
Use comments to ask for clarification. Post a solution as an answer.
33,775 reputation · 21 Aug 2023, 20:17 UTC
In YugabyteDB 2.x, once an ALTER TABLE has been committed and the new catalog version has propagated to all tablet leaders, the system does not provide a built‑in rollback path. The operation is forward‑only and incremental, so clients may see a mix of old and new schema states until the change is fully replicated.
Only very limited idempotent changes—such as adding a column with a default that requires no data migration—can be “reversed” by manually re‑applying the inverse ALTER. Even then, the catalog may retain stale metadata, and any data written under the new schema may be lost or corrupted.
Attempting a rollback while propagation is incomplete can lead to inconsistent views across nodes and may trigger schema conflicts if concurrent writes are in progress.