Which MySQL Tables Need Cross‑Cloud Sync? A Disaster Recovery Guide

Background

The primary goal of a disaster‑recovery (DR) system is to ensure continuity of data and services. When a failure occurs, the DR system must quickly restore services and guarantee data integrity. To protect against natural or man‑made disasters, IT systems are deployed in the same city or across regions, with data synchronization being the core task.

This article focuses on the application‑level DR scenario, discussing which data tables need cross‑cloud synchronization and which do not. A concrete case study helps readers organize sync and filter tables to meet DR requirements.

Related Terms

RDS MySQL – Alibaba Cloud’s managed MySQL service offering high performance and flexible deployment.

DTS – Data Transmission Service for real‑time data migration, subscription, and synchronization across relational, NoSQL, and OLAP sources.

ASR‑DR – Apsara Stack Resilience Disaster Recovery, a cloud product providing DR capabilities for RDS MySQL with rapid cut‑over.

Sync Table – Tables that must be backed up from one cloud to another.

Filter Table – Tables that should not be backed up across clouds.

Application Config Table – Stores application‑level configuration such as IPs, domains, and task switches.

Sequence – Globally unique IDs used for transaction numbers, user IDs, etc., often serving as primary keys.

Key Technical Issues About Filter Tables

Why identify filter tables?

Non‑DR applications: Limited resources in the backup center may prevent deployment, so their databases need not be synchronized.

Temporary backup tables created by DBAs during maintenance are already backed up by RDS, so cross‑cloud sync is unnecessary.

Applications without DR support: Some cloud products lack DR capability during early project phases; their tables can be excluded until full support is available.

Configuration tables with differences

Application configuration should be stored separately from code, using configuration centers or dedicated tables.

Environment parameters (IP, domain, credentials) differ between same‑city and cross‑region deployments; tables containing differing parameters must not be synced across clouds.

Business tables requiring dual writes

In active‑active (dual‑center) scenarios, both centers write to the same tables.

In cross‑region active‑passive setups, the backup center often has read‑only access, so dual‑write tables must be carefully filtered.

Designing Non‑Sync Tables in Application DR

From the cloud‑provider perspective, understand the synchronization capabilities of each vendor’s RDS MySQL (automatic, DTS‑based, or script‑driven) and configure filter tables accordingly. Alibaba Cloud DTS allows specifying databases and tables to exclude during link creation, and ASR‑DR can automatically apply the filter list when switching sync direction.

From the application perspective, adopt the following practices:

Design phase: Plan for multi‑cloud deployment, avoid hard‑coded parameters, and use configuration centers to manage environment‑specific settings.

Development phase: Prefer configuration centers (e.g., Alibaba Cloud EDAS) for dynamic parameters; if unavailable, isolate configuration data in dedicated MySQL tables.

Deployment phase: Verify the rationale for each filter table, ensure ASR‑DR correctly applies the filter list, and test functionality in the backup center.

Operations phase: Keep filter‑table changes synchronized between clouds, adjust tables from filter to sync (or vice‑versa) as business needs evolve.

The diagram below illustrates the logic of sync and filter tables in a cross‑region DR architecture.

Case Study

A cross‑region DR project mistakenly listed the global sequence table xx_table as a filter table, causing primary‑key conflicts after failover.

Problem : After switching RDS MySQL read/write rights from Cloud A to Cloud B, the backup center reported “primary key conflict”.

Analysis : The sequence IDs used by the backup center were outdated because the sequence table was not synchronized. The root cause was the erroneous inclusion of the sequence table in the filter list.

Emergency Measures :

Manually correct the sequence range in the backup center’s table.

Restart the backup‑center application to fetch a fresh sequence range.

Improvements :

Remove the sequence table from the filter list so it syncs across clouds.

Modify the application to handle read‑only mode gracefully and re‑acquire a valid sequence after failover.

Validate the changes through DR drills.

Before‑and‑after screenshots of the DR test results are shown below.

Conclusion

DR drills are the starting point for uncovering systemic issues; regular drills are essential.

Cloud‑level DR does not equal application‑level DR; the latter requires comprehensive engineering.

Effective DR involves cloud, application, and network engineering, as well as processes for fault detection, decision‑making, cut‑over, and emergency response.