Scale MySQL: Replication, Sharding & Kiến trúc TiDB

Mở rộng quy mô (scaling) một cơ sở dữ liệu quan hệ là một trong những thử thách khắc nghiệt nhất trong thiết kế hệ thống. Khi ứng dụng tăng trưởng từ hàng nghìn lên hàng triệu người dùng hoạt động, cơ sở dữ liệu không còn chỉ là một công cụ lưu trữ đơn thuần mà trở thành điểm nghẽn (bottleneck) chính của toàn bộ kiến trúc hệ thống.

Trong bài viết chuyên sâu này, chúng ta sẽ khám phá tiến trình phát triển kiến trúc để scale MySQL — bắt đầu từ các mô hình nhân bản (replication topologies), đi qua các bước phức tạp và rủi ro vận hành của việc phân mảnh database thủ công (manual sharding - bao gồm các giải pháp proxy trung gian như Vitess), và cuối cùng là đánh giá giải pháp thay thế NewSQL, cụ thể là kiến trúc phân tán của TiDB.

1. Giới hạn của mô hình Scale MySQL truyền thống

Hầu hết hành trình scale database đều bắt đầu với một thực thể chính (Primary instance) duy nhất xử lý cả tác vụ ghi (write) và đọc (read). Khi lượng đọc quá tải làm cạn kiệt băng thông CPU hoặc ổ đĩa, giải pháp giảm thiểu tiêu chuẩn là triển khai mô hình nhân bản Primary-Replica (Master-Slave).

flowchart TD
    App[Application Server] -->|Writes| Primary[(MySQL Primary)]
    App -->|Reads| Replica1[(MySQL Replica 01)]
    App -->|Reads| Replica2[(MySQL Replica 02)]
    Primary -->|Asynchronous Replication| Replica1
    Primary -->|Asynchronous Replication| Replica2

Điểm nghẽn Ghi trên Node Primary

Trong khi read replication giúp mở rộng băng thông đọc một cách tuyến tính bằng cách thêm các node replica, toàn bộ traffic ghi vẫn bắt buộc phải đi qua duy nhất một node primary. Node primary trở thành điểm nghẽn ghi vì các lý do:

• Điểm đột biến duy nhất (Single Point of Mutations): Tất cả các thay đổi dữ liệu phải được tuần tự hóa và ghi vào không gian bảng (table spaces) InnoDB và bộ đệm doublewrite buffer của primary.
• Trần giới hạn vật lý (Vertical Ceiling): Để xử lý nhiều giao dịch ghi trên giây (TPS) hơn, bạn bắt buộc phải nâng cấp phần cứng của node primary (ví dụ: nâng cấp core CPU, tăng dung lượng RAM, và chuyển sang ổ cứng NVMe SSD có chỉ số IOPS cao hơn). Tuy nhiên, việc scale dọc (vertical scaling) này sẽ nhanh chóng chạm tới ngưỡng giới hạn vật lý và có chi phí cực kỳ đắt đỏ.

Replication Lag và Luồng Áp dụng Đơn Luồng (Single-Threaded Applier)

Rủi ro vận hành lớn nhất trong mô hình nhân bản là replication lag (độ trễ nhân bản) — khoảng thời gian chênh lệch từ lúc một transaction được commit trên primary cho đến khi nó được áp dụng thành công trên replica. Các replica xử lý thay đổi thông qua cơ chế vận chuyển log gồm 2 bước:

1. Luồng I/O Thread của replica đọc binary logs (binlogs) từ primary và ghi vào relay logs local.
2. Luồng SQL Thread của replica đọc transactions từ relay logs và áp dụng chúng vào database local.

Trong lịch sử, luồng SQL Thread này hoạt động dưới dạng đơn luồng (single-threaded). Nếu một replica được cấu hình để chạy cập nhật tuần tự, một câu truy vấn chạy lâu (long-running query) hoặc một thao tác cập nhật hàng loạt (bulk operation) trên primary sẽ block tất cả các transaction phía sau trong hàng đợi.

🔥 [Sự cố Production]: Sập hệ thống dây chuyền do Batch Delete không index Triệu chứng: Cơ sở dữ liệu ghi bị khóa (lock up); các node đọc replica bị trễ nhiều giờ, trả về dữ liệu cũ cho khách hàng và hiển thị lịch sử thanh toán không chính xác. Nguyên nhân gốc rễ: Một lập trình viên đã thực thi lệnh DELETE FROM logs WHERE created_at < '2026-01-01' trên một bảng chứa 50 triệu dòng. Cột created_at không được đánh index. Node primary thực thi lệnh xóa này trong một transaction nguyên tử duy nhất. Khi đồng bộ sang replica, luồng SQL applier đơn luồng của replica buộc phải thực hiện quét toàn bộ bảng (full-table scan) liên tục để tìm và xóa từng dòng, làm cạn kiệt tài nguyên CPU và I/O ổ đĩa, block toàn bộ các cập nhật của read-replica phía sau. Tác động: Độ trễ nhân bản kéo dài 6 giờ khiến trạng thái thanh toán hiển thị là “Pending” trên UI của khách hàng dù giao dịch đã thành công ở phía cổng thanh toán, kích hoạt hàng nghìn ticket hỗ trợ khách hàng trùng lặp. Giải pháp: Chia nhỏ thao tác delete thành các lô nhỏ 5.000 dòng dựa trên khóa chính (id), đánh index cho cột created_at, và kích hoạt tính năng nhân bản đa luồng WRITESET. (Nguồn: Post-Mortem nội bộ năm 2026)

Để giảm thiểu điểm nghẽn của luồng applier đơn luồng, các phiên bản MySQL hiện đại (5.7 và 8.0+) hỗ trợ cơ chế nhân bản đa luồng (multi-threaded replication). Bằng cách cấu hình trên replica:

-- Kích hoạt luồng applier đa luồng trên replica
SET GLOBAL replica_parallel_workers = 8;
SET GLOBAL replica_parallel_type = 'LOGICAL_CLOCK';

Và trên primary:

-- Theo dõi sự phụ thuộc của transaction bằng writesets để tối đa hóa tính song song
SET GLOBAL binlog_transaction_dependency_tracking = 'WRITESET';

Database sẽ theo dõi xem transaction nào chỉnh sửa các dòng không chồng chéo nhau (writesets) và cho phép các replica áp dụng chúng song song. Tuy nhiên, ngay cả với applier song song, replication lag vẫn xảy ra nếu I/O ổ đĩa của replica bị cạn kiệt hoàn toàn bởi khối lượng ghi quá lớn.

2. MySQL Horizontal Scaling vs. Vertical Scaling

Khi scale dọc (scale-up) đạt đến giới hạn, bạn bắt buộc phải chuyển dịch sang scale ngang (scale-out).

3. Những nỗi đau khi triển khai MySQL Sharding

Database sharding là quá trình phân mảnh một cơ sở dữ liệu duy nhất trên nhiều máy vật lý khác nhau. Nó chia nhỏ dữ liệu theo chiều ngang dựa trên một shard key được lựa chọn (ví dụ: phân vùng người dùng bằng cách tính user_id % 4 trên bốn thực thể database).

Mặc dù sharding giúp scale năng lượng ghi, nó lại mang tới độ phức tạp kiến trúc khổng lồ khi đẩy trách nhiệm quản lý của database lên tầng ứng dụng (application layer).

flowchart TD
    App[Application Code / Routing Layer] -->|user_id: 101| Shard0[Shard 0: user_id % 2 == 1]
    App -->|user_id: 102| Shard1[Shard 1: user_id % 2 == 0]
    
    subgraph Shard0_Instance["MySQL Instance A"]
        Shard0
    end
    subgraph Shard1_Instance["MySQL Instance B"]
        Shard1
    end

A. Định tuyến tầng Ứng dụng và Shard Keys

Trong một môi trường sharding, ứng dụng không còn có thể mở một kết nối database duy nhất. Mã nguồn phải kiểm tra mọi câu truy vấn, trích xuất shard key, và định tuyến câu truy vấn đó đến connection pool chính xác. Nếu một câu truy vấn thiếu shard key, ứng dụng phải chạy truy vấn dạng “scatter-gather” — phát tán câu truy vấn tới tất cả các shard và gộp kết quả lại trong bộ nhớ. Việc này làm suy giảm nghiêm trọng hiệu năng truy vấn và tăng overhead mạng.

B. Mất khả năng Cross-Shard Joins

Các câu lệnh SQL JOIN tiêu chuẩn chỉ hoạt động trong phạm vi một thực thể MySQL vật lý duy nhất. Nếu bạn cần join thông tin profile của người dùng trên Shard A với các giao dịch đơn hàng trên Shard B, bạn không thể viết một câu lệnh JOIN đơn giản. Thay vào đó, bạn phải:

1. Truy vấn Shard A để lấy thông tin người dùng.
2. Truy vấn Shard B để lấy thông tin đơn hàng.
3. Tự gộp hai tập dữ liệu này bằng code ứng dụng.

Mẫu thiết kế này phá vỡ các mô hình database quan hệ và đẩy công việc tính toán nặng nề từ bộ tối ưu hóa (optimizer) của database lên server ứng dụng.

C. Mất thuộc tính ACID và Phức tạp hóa Giao dịch Phân tán

MySQL cung cấp các đảm bảo ACID (Atomicity, Consistency, Isolation, Durability) trong phạm vi một instance duy nhất sử dụng công cụ giao dịch của InnoDB. Trên môi trường sharding, các đảm bảo này biến mất.

Nếu một nghiệp vụ yêu cầu ghi vào Shard A (trừ số dư tài khoản) và Shard B (tạo hóa đơn), bạn phải tự triển khai cơ chế điều phối giao dịch phân tán:

• Two-Phase Commit (2PC): Giao thức điều phối commit trên tất cả các shard tham gia. Tuy nhiên, 2PC chạy rất chậm, gây nghẽn mạng và dễ làm khóa toàn bộ hệ thống nếu bộ điều phối (coordinator) bị sập giữa chừng.
• Saga Pattern: Một chuỗi các transaction local nơi mỗi bước sẽ cập nhật dữ liệu trong một shard duy nhất. Nếu một bước phía sau bị lỗi, ứng dụng phải tự thực thi các transaction bù trừ (reversal transactions) theo thứ tự ngược lại để rollback. Việc này tăng độ phức tạp rất lớn cho các máy trạng thái ở tầng ứng dụng.

D. Re-sharding và các Hot Shards

Nếu 80% giao dịch của bạn được tạo ra bởi một vài người dùng nổi tiếng, shard chứa những người dùng này sẽ chịu áp lực cực lớn tạo ra điểm nghẽn “Hot Shard”. Để giải quyết vấn đề này, bạn phải thực hiện re-sharding — chia nhỏ hot shard đó thành hai hoặc nhiều node database mới.

Re-sharding là một quy trình vận hành vô cùng rủi ro:

1. Bạn phải dựng lên các instance MySQL mới.
2. Copy một tập con dữ liệu từ shard đang hoạt động trong khi nó vẫn đang phải phục vụ traffic.
3. Giữ các node mới đồng bộ bằng nhân bản binlog.
4. Chuyển đổi các luật định tuyến một cách nguyên tử ở tầng ứng dụng.

Bất kỳ sai sót nào trong đường ống đồng bộ này đều có thể dẫn đến mất nhất quán dữ liệu hoặc hỏng dữ liệu ngầm.

E. Vitess Middleware: Giải pháp Trung gian

Vitess hoạt động như một SQL proxy và tầng điều phối nằm giữa ứng dụng và hệ thống các instance MySQL. Nó cung cấp một giao diện SQL hợp nhất cho ứng dụng, tự động xử lý định tuyến truy vấn, re-sharding, và hỗ trợ các truy vấn cross-shard join cơ bản.

Mặc dù Vitess giúp giữ lại hạ tầng lưu trữ MySQL (InnoDB) và các công cụ DBA hiện có, nó lại mang tới một control plane rất phức tạp:

• Bạn phải chạy và quản trị các thành phần VTGate (routing proxies), VTTablet (tiến trình agent chạy song song với mỗi instance MySQL), và các Topology Servers (như etcd hoặc ZooKeeper).
• Các lập trình viên vẫn bắt buộc phải định nghĩa cấu trúc phân vùng database thông qua VSchemas (Vitess Schemas) và VIndexes (Vitess Indexes).

4. NewSQL: TiDB — Giải pháp Thay thế Sharding

Các cơ sở dữ liệu NewSQL đại diện cho một thế hệ database quan hệ hiện đại, cung cấp khả năng mở rộng ngang của hệ thống NoSQL nhưng vẫn giữ nguyên các đảm bảo giao dịch ACID và cú pháp SQL tiêu chuẩn. TiDB (phát triển bởi PingCAP) là một cơ sở dữ liệu NewSQL phân tán, mã nguồn mở, được thiết kế để thay thế trực tiếp cho các hệ thống MySQL đã quá tải.

Kiến trúc Cốt lõi: Tách biệt Tính toán và Lưu trữ

TiDB được thiết kế từ đầu với tầng tính toán stateless (không lưu trạng thái) tách biệt hoàn toàn khỏi tầng lưu trữ giao dịch phân tán.

flowchart TD
    App[Application Client] -->|MySQL Protocol| TiDB1[TiDB Server Compute]
    App -->|MySQL Protocol| TiDB2[TiDB Server Compute]
    
    PD[Placement Driver Cluster] <--> TiDB1
    PD <--> TiDB2
    
    TiDB1 <--> TiKV_Group
    TiDB2 <--> TiKV_Group
    
    subgraph TiKV_Group["TiKV Distributed Storage Layer (OLTP)"]
        TiKV1[(TiKV Node 01)]
        TiKV2[(TiKV Node 02)]
        TiKV3[(TiKV Node 03)]
    end
    
    TiKV_Group -.->|Asynchronous Raft Replication| TiFlash[(TiFlash Columnar Engine - OLAP)]

A. TiDB Server (Tầng Tính toán)

Các node stateless tiếp nhận các kết nối từ MySQL client. Chúng parse câu truy vấn SQL, tạo ra các kế hoạch thực thi phân tán được tối ưu hóa, và chuyển đổi các câu lệnh SQL thành các yêu cầu key-value gửi xuống tầng lưu trữ. Vì các node TiDB server là stateless, bạn có thể dễ dàng scale ngang chúng bằng cách đặt phía sau một bộ cân bằng tải tiêu chuẩn (như HAProxy hoặc Nginx).

B. TiKV (Tầng Lưu trữ)

Một kho lưu trữ key-value phân tán, có hỗ trợ transaction. Dữ liệu được tự động phân chia thành các vùng key liên tục gọi là Regions (mặc định có kích thước 96MB). Mỗi Region được replicate qua nhiều node TiKV bằng giao thức đồng thuận Raft (Raft consensus protocol) để tạo thành một Raft Group.

C. Placement Driver (PD - Bộ não Điều phối)

Một cluster các node lưu trữ metadata của hệ thống, theo dõi sức khỏe của các node TiKV, và quản lý việc lập lịch dữ liệu tự động. PD hoạt động như bộ điều phối của cluster, tự động chia đôi các Region khi chúng vượt quá 96MB và migrate chúng sang các node TiKV ít tải hơn để tránh các điểm hot spot. Nó cũng hoạt động như một Timestamp Oracle (TSO), cấp phát các mốc thời gian (timestamps) duy nhất, tăng dần đều trên toàn cầu cho các giao dịch phân tán.

Tích hợp RocksDB và Multi-Version Concurrency Control (MVCC)

Mỗi node TiKV lưu trữ các phân vùng dữ liệu local của nó bên trong RocksDB, một công cụ key-value LSM-tree hiệu năng cao. Để hỗ trợ cô lập giao dịch (transactional isolation), TiKV ghi dữ liệu trên ba phân mục RocksDB Column Families (CF):

• Default CF: Lưu trữ giá trị thực tế được đánh chỉ mục theo key và timestamp phiên bản.
• Lock CF: Lưu trữ các khóa (locks) của transaction đang hoạt động.
• Write CF: Lưu trữ metadata commit (mốc thời gian commit commit_ts và con trỏ trỏ tới phiên bản trong Default CF).

Khi một câu truy vấn đọc dữ liệu, TiDB kiểm tra Write CF sử dụng mốc thời gian bắt đầu transaction (start_ts) để xác định phiên bản commit mới nhất. Cơ chế Multi-Version Concurrency Control (MVCC) này cho phép các thao tác đọc không bị khóa — giao dịch ghi không bao giờ block giao dịch đọc, và ngược lại.

Giao dịch Phân tán Percolator

TiDB triển khai các giao dịch ACID phân tán trên toàn bộ cluster lưu trữ bằng cách sử dụng một biến thể tối ưu hóa từ mô hình Percolator của Google, thực thi giao thức Two-Phase Commit (2PC) trực tiếp tại tầng lưu trữ:

1. Giai đoạn Prewrite: Client yêu cầu một start_ts từ PD. Nó ghi các thay đổi xuống TiKV, chọn một key làm “Primary Lock” và các key khác làm “Secondary Locks”. Hệ thống sẽ khóa các key mục tiêu trong RocksDB Lock CF và ghi dữ liệu tạm thời vào Default CF.
2. Giai đoạn Commit: Client yêu cầu một commit_ts từ PD. Nó cố gắng commit khóa Primary Lock trước. Nếu thành công, giao dịch được coi là đã commit về mặt logic. Các bản ghi Lock CF được dọn dẹp, và các commit markers được ghi vào Write CF. Các khóa secondary locks còn lại sẽ được commit bất đồng bộ sau đó.

Thiết kế này giúp tránh việc sử dụng các bộ quản lý khóa tập trung (centralized lock managers) và phân tán chi phí giao dịch trên toàn bộ các node lưu trữ TiKV.

Xử lý HTAP Thời gian thực thông qua TiFlash và Raft Learners

Một trong những tính năng mạnh mẽ nhất của TiDB là năng lực xử lý hỗn hợp cả giao dịch và phân tích thời gian thực (HTAP - Hybrid Transactional/Analytical Processing). Trong khi TiKV lưu trữ dữ liệu theo dòng (row-based) tối ưu cho các thao tác ghi OLTP nhanh chóng, các truy vấn phân tích (SUM, AVG, GROUP BY) lại chạy rất chậm trên cấu trúc lưu trữ này.

TiDB giải quyết bài toán này bằng cách tích hợp TiFlash, một công cụ lưu trữ dạng cột (column-oriented). Các node TiFlash kết nối trực tiếp với tầng lưu trữ TiKV:

• Nhân bản Raft Learner: Các node TiFlash tham gia vào các Raft group của TiKV Regions với vai trò là các Learners.
• Không ảnh hưởng tới tải OLTP: Khác với các follower thông thường, các Raft Learner không tham gia vào việc bỏ phiếu đồng thuận (consensus voting) hay bầu chọn leader. Dữ liệu dạng dòng được replicate bất đồng bộ từ TiKV sang TiFlash và chuyển đổi thành cấu trúc dạng cột theo thời gian thực. Vì các learner không tham gia biểu quyết, mọi trễ mạng hay nghẽn ghi trên các node TiFlash hoàn toàn không ảnh hưởng tới hiệu năng và độ trễ giao dịch OLTP trên TiKV.
• Định tuyến Thông minh (Smart Routing): Bộ tối ưu hóa của TiDB tự động định tuyến các câu truy vấn phân tích (OLAP) sang TiFlash và các truy vấn giao dịch (OLTP) sang TiKV, cho phép các đội ngũ chạy các dashboard báo cáo thời gian thực trên dữ liệu live mà không cần xây dựng các pipeline ETL phức tạp.

5. Kiến trúc Database Mở rộng: Lựa chọn Giải pháp Phù hợp

Khi thiết kế một nền tảng database, không có một giải pháp đơn lẻ nào là “tốt nhất”. Lựa chọn đúng đắn phụ thuộc vào quy mô, ngân sách vận hành và các yêu cầu cụ thể của ứng dụng của bạn.

Bảng So sánh các Kiến trúc Database

Lộ trình và Công cụ Dịch chuyển (Migration)

Nếu bạn quyết định dịch chuyển từ hệ thống MySQL cũ sang TiDB, bạn có thể tận dụng các công cụ dịch chuyển có sẵn:

[Database nhỏ và vừa < 1 TiB]
MySQL Source ───────────────── TiDB Data Migration (DM) ────────────────► TiDB Target

[Database lớn > 1 TiB]
MySQL Source ──► Dumpling (CSV/SQL Export) ──► TiDB Lightning (Physical Mode) ──► TiDB Target

1. TiDB Data Migration (DM):
   • Được thiết kế cho các tập dữ liệu dưới 1 TiB.
   • Tự động hóa toàn bộ vòng đời dịch chuyển: copy table schemas, import dữ liệu lịch sử, và đọc MySQL binary logs để thực hiện nhân bản tăng dần thời gian thực (incremental replication).
2. Dumpling + TiDB Lightning (Physical Import Mode):
   • Được thiết kế cho các tập dữ liệu lớn trên 1 TiB.
   • Dumpling xuất dữ liệu bảng thành các file SQL hoặc CSV.
   • TiDB Lightning chạy ở chế độ Physical Mode, phân tích các file thô và tạo trực tiếp các file SST của database. Sau đó, nó ghi trực tiếp các file SST này vào tầng lưu trữ TiKV, hoàn toàn bỏ qua tầng tính toán SQL. Chế độ import vật lý này cực kỳ nhanh, đạt tốc độ import lên tới 250 GiB/giờ cho mỗi node.
   • Lưu ý quan trọng: Trong quá trình chạy Physical Mode, các bảng mục tiêu trên TiDB phải trống, và cluster không được phép phục vụ traffic của ứng dụng. Sau khi hoàn thành, bạn phải cấu hình TiDB DM để đồng bộ nốt lượng dữ liệu ghi phát sinh trong thời gian chạy import.

Hạn chế về Khả năng Tương thích

Mặc dù TiDB tương thích rất cao với giao thức MySQL, nó không phải là một giải pháp thay thế hoàn hảo cho mọi hệ thống. Nó thiếu sự hỗ trợ cho:

• Triggers & Stored Procedures: Các database phân tán không thể chạy các tiến trình thay đổi trạng thái tuần tự một cách hiệu quả bên trong từng phân vùng lưu trữ mà không gây ra nghẽn hiệu năng nghiêm trọng.
• Câu lệnh DDL đa đối tượng: Bạn không thể thay đổi nhiều cột hoặc ràng buộc trong một câu lệnh ALTER TABLE đơn lẻ nếu chúng xung đột hoặc tham chiếu đến cùng một bảng.
• Ràng buộc Khóa ngoại (Foreign Key Constraints): Mặc dù TiDB hỗ trợ cú pháp khóa ngoại, việc ép buộc khóa ngoại trên các node phân tán đòi hỏi các bước xác thực chéo node rất tốn kém tài nguyên. Các ứng dụng quy mô lớn nên tự quản lý việc ràng buộc toàn vẹn ở tầng ứng dụng.

Đối với các hệ thống không phụ thuộc nhiều vào stored procedure hay trigger ở tầng database, việc chuyển dịch sang TiDB sẽ giúp loại bỏ gánh nặng vận hành của sharding, cung cấp một con đường rõ ràng để scale ngang năng lực ghi của database.

Các Câu hỏi Thường gặp (FAQ)

Làm thế nào để scale một database MySQL? Bạn bắt đầu bằng cách scale dọc (nâng cấp phần cứng) và thêm các read replicas. Khi băng thông ghi trở thành điểm nghẽn, bạn bắt buộc phải chuyển sang scale ngang (sharding) hoặc áp dụng một database NewSQL phân tán như TiDB.

Sự khác biệt giữa sharding và partitioning là gì? Partitioning thường ám chỉ việc chia nhỏ một bảng lớn thành các phần nhỏ hơn, dễ quản lý hơn ngay bên trong cùng một instance database. Sharding là phân mảnh dữ liệu theo chiều ngang trên các instance database vật lý hoàn toàn riêng biệt, yêu cầu cơ chế định tuyến ở tầng ứng dụng.

Tại sao TiDB là giải pháp thay thế tốt cho MySQL sharding? TiDB mang lại khả năng scale ngang năng lực ghi giống như sharding nhưng không làm phức tạp hóa tầng ứng dụng. Nó tự động quản lý phân vùng dữ liệu (Regions), định tuyến truy vấn, và tự cân bằng tải. Nó cũng hỗ trợ các giao dịch ACID phân tán một cách tự nhiên, điều cực kỳ khó tự triển khai trong môi trường MySQL sharding thủ công.

🔗 Bước tiếp theo: Để hiểu cách scale database và các mô hình tính sẵn sàng cao (high-availability) khớp với thiết kế hạ tầng cloud quy mô lớn, hãy đọc hướng dẫn của chúng tôi về thiết kế hệ thống quy mô lớn và so sánh hệ thống database vùng truyền thống với các dòng database cho edge computing.