Industrial Bank IT Architecture Transformation: From Mainframe DB2 to Distributed MySQL Solutions

Database Transformation Background

Industrial Bank, a large state‑owned bank, historically relied on mainframe + DB2 for core systems, which could not meet the rapid expansion of internet‑finance services.

1. Challenges of Traditional IT Architecture

Four main pain points were identified:

Processing capacity: Vertical scaling limited throughput for the bank's massive scale.

Operational risk: 24/7 service requirements could not be guaranteed by the legacy stack.

Rapid delivery: High coupling between applications caused long development cycles.

Cost control: Expensive mainframe operation and high‑priced commercial licenses.

The transformation goal was to build a flexible, open, efficient, and secure IT architecture that supports fast business innovation.

2. Core Demands and Strategy

The strategy focused on three pillars:

High concurrency, horizontal scalability, massive data storage, and two‑city‑three‑center high‑availability disaster recovery.

Cost reduction by adopting commodity hardware and minimizing reliance on commercial products.

Enhanced operational automation and intelligent management.

Three concrete tactics were applied:

Shift from centralized to distributed architecture.

Move from proprietary to generic solutions (i.e., “IOE” removal).

Limit commercial products and embrace open‑source.

Transformation Journey

1. Three‑Year Roadmap

The migration began in 2015, with significant progress from early 2016 to 2017, divided into three stages:

Stage 1 – Prototype Development and Exploration : Migrated personal‑account services from mainframe to an open‑platform, validating MySQL‑based solutions.

Stage 2 – Foundation Research and Pilot : Built MySQL capabilities, conducted pilot projects, and launched the prototype in May 2017.

Stage 3 – Large‑Scale Implementation and Promotion : From 2018 onward, deployed enterprise‑grade MySQL services, introduced distributed middleware, improved high‑availability, and increased resource utilization.

Selection Phase

1. Solution Evaluation

Extensive research from 2014‑2016 considered NewSQL, but the bank chose an open‑source distributed OLTP approach based on MySQL for its proven scalability and cost‑effectiveness.

2. Distributed Technology Stack

The stack includes distributed services, transaction frameworks, batch processing, caching, data reconciliation, messaging, configuration centers, and unified operation‑management platforms.

Key components:

Distributed services: Service‑oriented refactoring to reduce coupling and avoid distributed transactions.

Distributed transaction framework: Two‑phase commit and message‑driven models supporting strong and eventual consistency.

Distributed batch framework: Bulk operations across large data nodes.

Distributed middleware (DBLE): Enables vertical/horizontal/sharding and cross‑database queries.

3. MySQL High‑Availability Solution

Initially used MySQL 5.6/5.7 with semi‑synchronous replication, achieving RPO = 0 and rapid failover. The design expanded to a 1‑master‑3‑standby topology, ensuring true system‑level RPO = 0.

Implementation and Promotion

1. Foundation Research and Pilot

Validated features, performance, backup/recovery, and high‑availability designs; produced technical specifications for developers.

2. Distributed Middleware Deployment

Introduced DBLE to simplify development, providing vertical/horizontal/sharding and a unified query experience.

3. Operations Architecture Enhancement

Integrated DBLE with an automated operation platform covering high‑availability, monitoring, deployment, and automated data reconciliation.

4. Unified Operations Platform

Implemented one‑click installation, version upgrades, parameter configuration, and multiple HA strategies (automatic and manual).

5. Automated Failure Switching

Built an automated decision system handling RPO = 0 and RTO < 60 seconds, supporting both RPO‑priority and RTO‑priority scenarios.

Practical Optimizations

1. HA Scheme Improvements

Scaled from 1‑master‑2‑backup to 1‑master‑3‑backup, achieving true RPO = 0 at the system level.

2. Remote Disaster Recovery and Storage Optimization

Moved from disk‑based replication to asynchronous MySQL replication and introduced SSDs, eliminating I/O bottlenecks and cutting transaction latency by ~50%.

3. MySQL Containerization Exploration

Containerized MySQL to improve resource utilization (4‑5× efficiency) and support over 400 nodes, addressing data persistence and service exposure challenges.

Transformation Outcomes

1. Implementation Results

Deployed >120 applications, >2,000 servers, and >2,500 MySQL nodes, handling daily transaction volumes of 7 billion and peak TPS of 30,000 (design target 3 million TPS). Achieved same‑city RPO = 0 and RTO < 60 s:

RPO = 0, RTO < 60s

Reduced mainframe costs while maintaining 20% annual transaction growth.

2. Typical Case – Personal Account Platform

Migrated high‑concurrency, low‑latency personal‑account service (3 billion daily transactions, ≤100 ms latency) to a dual‑active sharding architecture, achieving RPO = 0 and RTO < 30 s.

3. Typical Case – Information Assistance Service

Implemented DBLE‑based sharding (128 shards) for a 2 billion daily transaction system with ≤10 ms latency, also achieving RPO = 0 and RTO < 30 s.

Future Work

1. Cloud Services

Track and adopt mature cloud technologies (SaaS, IaaS, PaaS) to keep pace with internet‑scale solutions.

2. Unified Data Exchange

Build system‑level real‑time data replication platforms beyond existing message‑based business exchanges.

3. Oracle Migration

Explore cost‑effective strategies to transition Oracle workloads while minimizing redevelopment effort.

4. Distributed Database Exploration

Continue evaluating emerging distributed database products to achieve autonomous, sovereign capabilities.