Meituan's TiDB Adoption: Architecture, Deployment, and Operational Practices

In recent years, Meituan's explosive business growth made traditional MySQL‑based relational databases unable to keep up, leading the team to explore more scalable storage solutions.

After comparing scale‑out and scale‑up options, TiDB was selected for its MySQL compatibility, strong consistency, online scaling, and multi‑datacenter resilience.

By early 2018 a pilot project launched a distributed‑database initiative, deploying TiDB on 10 clusters and nearly 200 physical nodes, serving OLTP workloads for delivery, travel, payment, and hospitality services.

1. Background and Current Situation

The team performed extensive solution comparisons, ultimately choosing TiDB and cooperating closely with PingCAP and the open‑source community.

2. Preliminary Research and Testing

Key evaluation criteria for TiDB included MySQL protocol compatibility, online scaling, strong distributed transactions, secondary indexes, OLTP performance, cross‑datacenter failover, and cross‑datacenter dual‑write support.

Research also covered academic papers such as Google Spanner, F1, and consensus algorithms to understand TiDB’s storage structure and transaction mechanisms.

Performance and functional tests confirmed TiDB’s ability to maintain three‑replica cross‑datacenter deployment without losing a majority of replicas during a single‑datacenter outage.

3. Storage Ecosystem Construction

3.1 Business Access Layer – Initially DNS + load‑balancer was used; later a Zebra client will be adopted for transparent migration from MySQL.

3.2 Monitoring and Alerting – Meituan uses Mt‑Falcon for alerting and integrates TiDB metrics via Prometheus + Grafana, converting metrics to Falcon‑compatible formats.

3.3 Batch Deployment – Ansible automates TiDB deployment; multiple version directories are maintained on a control machine.

3.4 Automated Operations Platform – Components such as SQL audit, DTS, and backup are replicated from the MySQL platform.

3.5 Heterogeneous Data Synchronization – Tools like DM, Mydumper + Loader, and Pump + Drainer enable MySQL↔TiDB and Hive↔TiDB synchronization.

4. Production Experience

Initial roll‑out followed a cautious path: offline → non‑core → core services. Typical issues and resolutions include:

Write stall in TiKV due to RocksDB L0 overload – mitigated by adjusting Raft log GC, snapshot speed, and compaction parameters.

GC lag when deleting massive data – addressed by increasing TiKV nodes and awaiting multithreaded GC in upcoming releases.

Insert latency growth – solved by extending heartbeat intervals and enabling Region‑merge in TiDB 2.1.

Incomplete space reclamation after TRUNCATE – fixed by using DeleteFilesInRange in TiDB 2.1.

Region‑merge activation – improved query latency after TiDB 2.1 upgrade.

Additional challenges such as JDBC kill‑query permission were resolved by upstream patches (e.g., kill query no longer requires SUPER).

5. Summary and Outlook

Meituan plans to expand TiDB usage across more business systems, integrate it into the next‑generation database strategy, and collaborate with PingCAP on future innovations like the Titan storage engine, Cloud TiDB (Docker + K8s), and the TiDB HTAP platform.