Question
Does YugabyteDB Need a Compensating Transaction for Partially Applied Online Schema Changes?
Mira River
0 reputation · 20 Aug 2024, 03:33 UTC
20.4K views
Loading…
0 reputation · 20 Aug 2024, 03:33 UTC
The goal is to guarantee that a schema change applied via YugabyteDB's online DDL can be safely reverted if the migration has only progressed on a subset of tablets, without risking data loss or inconsistency.
Currently, once a background migration starts altering tablets, there is no built‑in mechanism to roll back those tablets to the previous schema; certain DDL operations such as adding a NOT NULL column with a default or changing a data type are irreversible once the table rewrite begins. This raises an open design question about whether a compensating transaction or manual rollback procedure should be introduced for partially propagated changes.
32775 reputation · 20 Aug 2024, 04:59 UTC
No, YugabyteDB does not require a user‑provided compensating transaction when an online schema change is only partially applied.
Because the schema change follows the same Raft‑based consensus and schema‑versioning mechanism as regular user transactions, a failure on any replica causes the master to reject the new schema version. The cluster therefore remains at the previous version without any manual intervention.
No special steps are needed; rely on the built‑in abort mechanism. To verify that a failed DDL was rolled back, you can:
yugabytedbyb-admin or the SQL SHOW CREATE TABLE still reflects the old schema.In practice, the master records the schema change in its catalog with a pending state; once all tablets acknowledge, the state moves to committed. If any tablet fails, the state moves to aborted and the catalog entry is removed.
If you suspect a master‑quorum loss during the DDL, please provide the master‑quorum status at the time of the failure; that detail would change the recommendation.
Use comments to ask for clarification. Post a solution as an answer.
4,940 reputation · 20 Aug 2024, 08:06 UTC
While the distributed transaction ensures the schema version is committed atomically across the cluster, it is important to distinguish between the metadata update and the physical data migration for operations that trigger a table rewrite.
In YugabyteDB (YSQL), certain DDLs use a multi-state transition protocol (inspired by Google F1) to prevent inconsistencies. If a migration is interrupted, the system relies on these intermediate states (e.g., delete-only or write-only) to maintain safety. However, for operations that physically rewrite the underlying SSTables, the "rollback" is typically a matter of the cluster ignoring the partially written new data once the schema version is reverted or aborted.
To verify the current state during a suspected hang, users should check the yb-master logs for the specific schema version transition. If the version has not incremented, the physical changes on the tablets are effectively orphaned and will be cleaned up by the system's background compaction processes.