Deploying Seata 2.6.0: TC, MySQL Storage, and Nacos Registration

Baseline: Seata 2.6.0, MySQL 8, and Nacos 2.x. The Seata Server, client, database scripts, and Spring Cloud Alibaba versions must be matched according to the official compatibility matrix.

1. Deployment Options

For local testing, you can use the file registry and file-based storage to quickly validate the flow. Production environments typically use a service registry and configuration center such as Nacos, along with a database or an officially supported highly available store.

Do not copy Seata 1.x registry.conf, file.conf, image tags, or database scripts directly into 2.x. Pin versions for all images and dependencies, and never use latest.

2. TC Database

Initialize the TC database using the MySQL script in the corresponding database directory of the Seata 2.6.0 release package. The core tables include:

global_table       全局事务
branch_table       分支事务
lock_table         全局锁
distributed_lock   TC 集群协调
vgroup_table       事务组映射

Each business database participating in AT also needs an undolog table corresponding to the client of the same version. Do not conflate the TC tables with the business database's undolog table.

3. Nacos Registration and Configuration

Explicitly configure the server address, namespace, group, cluster, username, and password for both the registry and configuration center. The transaction group mapping must remain consistent across all clients and TC configurations.

Inject production credentials through environment variables, secrets, or external configuration. Do not write them into Compose, Git, or public logs. Restrict access to Nacos, TC, and the database to the private network, and never expose management ports directly to the public internet.

4. Client Checks

After starting the business service, confirm that:

• The TM has registered with the TC;
• The RM has registered with the TC;
• The transaction group is mapped to an available TC cluster;
• The data source is proxied by AT;
• Each business database can write to undo_log;
• The XID can propagate through HTTP, RPC, or a messaging path.

5. Production Checks

Deploy the TC in a highly available configuration; back up the database and monitor its capacity; make lock waits, transaction timeouts, rollback retries, and undo_log counts observable; audit, canary-test, and roll back configuration changes; and rehearse compatibility across TC, Nacos, the database, and the client before upgrading.

AT cannot automatically roll back messages, caches, files, or calls to third-party APIs. When crossing these boundaries, use reliable messaging, idempotency, compensation, TCC, or Saga instead of assuming that all actions can be included in a single database transaction.