Inside JD.com’s Intelligent Database Automation Platform: Architecture, Features, and Future Roadmap

Intelligent Database Operations Platform (DBS)

The JD MySQL Database Management Platform (DBS) automates the full lifecycle of MySQL services. Its core functional modules are:

Metadata Management : Stores hierarchical asset data across datacenter, host, business, cluster, instance, and schema dimensions to support reliable automation.

Automated Deployment : Orchestrates server provisioning, MySQL instance installation, data synchronization, consistency checks, and cut‑over with multi‑level approval workflows, achieving end‑to‑end service deployment.

Intelligent Analysis & Diagnosis : Collects OS and MySQL metrics, performs performance profiling, slow‑SQL, index, space‑forecast, lock analysis, and triggers fault self‑healing.

Intelligent Switching : Provides automatic and semi‑automatic failover at instance, cluster, and datacenter levels. The process updates monitoring, asset metadata, backup policies, and role assignments in a single click.

Automated Backup & Recovery : Uses an APScheduler‑based scheduler supporting interval, crontab, and date triggers. Features include concurrent execution, fault‑tolerant task persistence, backup‑strategy CRUD, automatic retry (up to three attempts within 6 h), and post‑recovery validation.

Key architectural diagrams illustrate the platform stack, deployment workflow, monitoring pipeline, and failover logic.

ContainerDB → ContainerDB 2.0

ContainerDB replaces the original containerized MySQL service, which suffered from coarse resource granularity and static allocation, with an elastic, load‑aware scheduling system.

Resource Delivery

Initial allocation: 64 GB disk per service.

Vertical scaling: Up to 256 GB disk; CPU/Memory can be expanded within tiered limits (2C/4G → 4C/8G → 8C/16G → 16C/32G).

Online resharding is triggered when the disk limit is reached.

Load‑Based Elastic Scheduling

Resources are classified as:

Instantaneous resources (CPU, Memory) – tiered lower/upper bounds; excess resources are allocated on demand and released when load normalizes.

Incremental resources (Disk) – monitored for 80 % usage; if below 256 GB, a vertical upgrade adds 64 GB; otherwise online resharding creates new shards.

Anti‑Affinity & Rebalancing

Placement constraints prevent multiple instances of the same shard from residing in the same rack, IDC, or room. A background daemon continuously checks anti‑affinity violations and rebalances shards, preferring slave redistribution to avoid service disruption.

Online Expansion, Self‑Healing, and Migration

ContainerDB supports:

Online vertical upgrades and resharding without downtime.

Automatic master‑failover: selects the GTID‑most‑up‑to‑date slave, rebuilds replication, and updates routing metadata.

Slave‑failover and planned switch‑overs with deterministic target selection (local first, then remote, based on connection count and QPS).

Zero‑downtime data migration via JTransfer , which copies data in parallel (windowed incremental + bulk) and switches the domain name once lag < 5 s.

All client traffic is routed through a Gate layer that performs transparent MySQL‑protocol routing based on topology metadata, ensuring full MySQL compatibility.

Automated Backup & Recovery Architecture

The backup system consists of a scheduler, backup engine, recovery engine, validation module, and auto‑repair component.

Scheduler Design

Implemented with APScheduler for flexibility and low maintenance. Supports three trigger types: interval: periodic tasks with weeks/days/hours/minutes/seconds granularity. crontab: cron‑style expressions (year, month, day, week, day_of_week, hour, minute, second). date: one‑off execution at a specific timestamp.

Concurrency control limits the number of simultaneous backup jobs to avoid resource contention. Trigger and execution are decoupled: lightweight triggers enqueue jobs, while heavy execution runs in a separate worker pool.

Reliability Features

Task persistence across host maintenance – APScheduler resumes missed jobs after restart.

Backup‑strategy stored by domain name (not IP) to survive host failover.

Automatic retry for failures within 6 h (max 3 attempts).

Automatic recovery validation after each restore.

Auto‑repair subsystem attempts to fix environment‑related backup failures.

Frontend UI Modules

Backup Strategy Management – create, modify, pause, or delete strategies (time, server, method).

Backup Details – view total/successful counts, success rate, 24 h trend, and filter records by cluster or project.

Recovery Detection – monitor daily detection count, success rate, and visualize status via pie/bar charts.

Future Roadmap

Planned enhancements focus on five pillars:

Deep‑learning‑driven resource tuning to automatically adjust CPU/Memory limits per instance.

Pre‑emptive host defragmentation for faster vertical scaling.

Development of a cost‑effective multi‑model storage engine.

Zero‑migration MySQL compatibility for seamless client adoption.

Open‑source release of ContainerDB and related tooling to foster community collaboration.