Data Migration & Distributed Transactions: XA, BASE, TCC, AT Guide

Preface

By vertically or horizontally splitting data we solve capacity and performance issues, but face data migration and consistency challenges.

Data migration must consider fast, smooth, zero‑downtime migration and post‑migration integrity verification.

Data consistency requires deciding whether distributed transactions are needed; if so, choose between XA or BASE‑style flexible transactions.

Data Migration

Data migration is prone to failures; it should be smooth, accurate, fast, minimize downtime, and have low business impact, especially with heterogeneous data structures.

Full Migration

The full migration process:

Business system downtime.

Database migration and data consistency verification.

Business system upgrade and connection to the new database.

Drawbacks of Full Migration

Requires business system downtime.

Long migration time, greater impact on business; heterogeneous data may need custom programs, extending duration.

Full + Incremental Migration

This method relies on the data creation timestamp:

Synchronize data up to a recent timestamp (creation time).

Publish system upgrade notice.

Synchronize data changes that occurred after that point.

Upgrade the system and connect to the new database.

Compared with pure full migration, this approach greatly reduces downtime and business impact.

Binlog + Full + Incremental

Binlog combined with full and incremental migration parses and reconstructs data from primary or replica databases, usually requiring middleware tools that support multithreading, resumable transfer, and automatic scaling.

Common tools include Canal and ShardingSphere‑scaling.

Distributed Transactions

XA Distributed Transactions

XA is a protocol supported by the database itself, providing strong consistency.

Components of an XA transaction:

Application Program (AP): defines transaction boundaries.

Resource Manager (RM): e.g., database, file system.

Transaction Manager (TM): assigns transaction IDs, monitors progress, handles commit/rollback.

Key XA interface calls:

xa_start – start or resume a transaction branch.

xa_end – dissociate the current thread from the transaction branch.

xa_prepare – ask RM if it is ready to commit.

xa_commit – instruct RM to commit the branch.

xa_rollback – instruct RM to roll back the branch.

xa_recover – recover in‑doubt XA transactions.

MySQL supports XA transactions for InnoDB starting from version 5.0.3.

Typical XA transaction flow diagram:

Main XA frameworks: Atomikos, Narayana, Seata.

Problems with XA:

Synchronization blocking – global transaction requires all branches to succeed; high isolation levels (SERIALIZABLE) degrade performance.

Single point of failure – TM must be highly available.

Data inconsistency – network failures during two‑phase commit can leave some RMs unaware of the commit.

Flexible Transactions (BASE)

BASE focuses on basic availability, soft state, and eventual consistency, allowing systems to be generally available while achieving final data consistency via mechanisms such as message passing.

Basic Availability – participants may not be online simultaneously.

Soft State – system state may be temporarily inconsistent.

Eventual Consistency – final consistency is achieved over time.

Flexible transaction core idea: move lock handling from the RM layer to the business layer, relaxing strong consistency to improve throughput.

TCC – manual compensation.

AT – automatic compensation.

TCC Overview

TCC splits each service operation into Try, Confirm, and Cancel phases.

Try – reserve resources after business checks.

Confirm – execute business logic using reserved resources; must be idempotent.

Cancel – release reserved resources; also idempotent.

AT Mode

AT is a two‑phase commit that automatically generates reverse SQL for rollback when exceptions occur.

Seata’s support for AT:

First phase records business data and rollback logs in the same local transaction, releasing local locks and connections.

Second phase commits asynchronously; rollback uses the previously recorded logs for compensation.

Transaction Properties under Flexible Transactions

Atomicity – generally guaranteed.

Consistency – temporary inconsistencies may exist, but eventual consistency is achieved.

Isolation – possible dirty reads during intermediate states.

Durability – once committed, data is persisted like a local transaction.