Tách database WooCommerce — HyperDB, master-slave, sharding multi-store

Tách database WooCommerce ra khỏi WordPress core là kỹ thuật scale cho shop trên 100k SKU hoặc trên 10k đơn/ngày. WooCommerce table tăng tốc độ khác hẳn WordPress core, slow query trên bảng order crowd out admin Posts/Pages.

Tách database giảm load master và tăng response time 2-3 lần. Bài này hướng dẫn 4 phase migration với HyperDB.

Vì sao shop scale cần tách database

WooCommerce mặc định dùng chung database với WordPress core. Khi shop phát triển, `wp_postmeta` đạt 10 triệu row và `wp_woocommerce_order_items` vượt 1 triệu row — chiếm trên 80% data trong toàn database.

Slow query của WooCommerce khoá table tạm thời, khiến mọi truy vấn Posts/Pages/Comments của WordPress core cũng phải đợi. Admin chậm 3-5 giây mỗi click, dù chỉ vào trang Posts xem bài viết blog.

5 dấu hiệu shop nên tách database

• Database vượt 50GB: Backup window vượt 30 phút, slow query log ghi hàng nghìn entry mỗi ngày — báo hiệu MySQL không còn xử lý nổi 1 database mono.
• WooCommerce chiếm trên 80% data: Pattern tăng trưởng của order/postmeta khác hẳn core posts — tách để tune index và config riêng cho từng nghiệp vụ.
• Admin Posts/Pages load trên 3 giây: Slow query WooCommerce làm nghẽn WordPress core — tách cho phép admin blog/page chạy mượt độc lập.
• Compliance PCI-DSS hoặc GDPR: Data khách hàng cần isolate trong database riêng để áp policy access control và audit log chặt chẽ hơn.
• Backup blocking traffic: mysqldump chạy 1h khiến site lag, khách bỏ giỏ — tách database cho phép backup từng phần không ảnh hưởng production.

Khi nào KHÔNG nên tách

Shop dưới 5k đơn/ngày và database dưới 20GB chưa cần tách. Đầu tư 4-8 tuần migration và risk break không tương xứng với gain performance ở scale này.

• HPOS chưa bật: WooCommerce HPOS (ra 2023) đã tách order khỏi wp_postmeta sang `wc_orders` riêng — bật HPOS trước, đo lại perf, đa số case không cần tách DB nữa.
• Index chưa optimize: Slow query log chỉ ra 3-5 query thiếu index — add index trước khi tính tách DB. Index 1 cột vài phút, tách DB tốn 1 tháng.

2 kiến trúc tách database phổ biến

Lựa chọn giữa 2 database trên cùng 1 server (SME) và 2 database trên 2 server riêng (enterprise). Cùng server đơn giản hơn về network, khác server cho isolation hoàn toàn về resource và failure domain.

Kiến trúc 2 database trên 1 server

# Architecture diagram

[WordPress App PHP]
        |
        ├─ Connection 1 → web22_wp (Posts, Pages, Comments, Options, Users)
        |
        └─ Connection 2 → web22_wc (Orders, Order Items, Sessions, Webhooks)

# MySQL my.cnf tune cho 2 database
[mysqld]
innodb_buffer_pool_size = 16G
innodb_buffer_pool_instances = 8

# Database web22_wp tune nhẹ
- Posts, postmeta core (~5GB)
- Users, options (~1GB)
- innodb_log_file_size: 1GB

# Database web22_wc tune nặng
- Orders, order_items (~20GB)
- Sessions, transients (~5GB)
- innodb_log_file_size: 4GB (handle transaction lớn)

Kiến trúc master-slave replication

Shop trên 50k đơn/ngày cần thêm slave replica cho read-heavy workload. Master nhận write từ order checkout, 1-2 slave handle toàn bộ read query của catalog browsing và admin reports.

Replication lag dưới 100ms với binlog row-based.

• Master: Single instance handle 100% write (CREATE order, UPDATE stock, INSERT customer) — focus tuning innodb buffer pool và redo log cho write throughput.
• Slave 1: Handle SELECT từ frontend (product page, category, search) — tune query cache và cover index cho catalog read.
• Slave 2: Dedicated cho admin reports và backup — tách workload analytics khỏi production read tránh ảnh hưởng UX khách.

4 phase migration với HyperDB

Tách database không thể làm trong 1 ngày. Workflow 4 phase chuẩn: setup DB mới, migrate data, switch connection, monitor và rollback nếu issue.

Tổng 4-8 tuần cho shop 50GB.

Phase 1 — Setup database mới

• Tạo database `web22_wc`: Cùng MySQL server hoặc server riêng tuỳ kiến trúc — set character set utf8mb4 giống `web22_wp` để tránh emoji break.
• Identify table WooCommerce: Pattern `wp_woocommerce_*`, `wp_wc_*`, `wp_actionscheduler_*` — tổng khoảng 15-25 table tuỳ plugin extension.
• Backup full database hiện tại: mysqldump nén gzip ra ổ riêng — đây là rollback cuối cùng nếu mọi thứ fail.
• Schedule maintenance window: Low traffic 2-4 giờ (đêm khuya 2h-6h sáng) — thông báo customer qua banner site trước 24-48 giờ.

Phase 2 — Migrate WooCommerce data

# Step 1: dump WC tables only
mysqldump -u root -p web22_wp 
  wp_woocommerce_attribute_taxonomies 
  wp_woocommerce_downloadable_product_permissions 
  wp_woocommerce_log 
  wp_woocommerce_order_itemmeta 
  wp_woocommerce_order_items 
  wp_woocommerce_payment_tokens 
  wp_woocommerce_sessions 
  wp_actionscheduler_actions 
  wp_actionscheduler_groups 
  wp_actionscheduler_logs 
  wp_actionscheduler_claims 
  > wc_export.sql

# Step 2: import vào DB mới
mysql -u root -p web22_wc < wc_export.sql

# Step 3: verify row count match
mysql -e "SELECT COUNT(*) FROM web22_wp.wp_woocommerce_order_items;"
mysql -e "SELECT COUNT(*) FROM web22_wc.wp_woocommerce_order_items;"
# Phải match exactly trước phase 3

Phase 3 — Switch connection qua HyperDB

WordPress mặc định chỉ biết 1 database. HyperDB drop-in (Automattic) cho phép route từng pattern table sang database khác.

Config nằm trong `db-config.php` cấp root WordPress.

Phase 4 — Monitor và rollback plan

Sau switch, monitor sát 1-2 tuần qua error log, slow query log, APM (New Relic hoặc Datadog). Có rollback script chuẩn bị sẵn — issue critical revert về single DB trong 30 phút.

• Smoke test 50 case: Tạo order, edit product, view admin Posts, search product, browse category — verify mọi flow chính chạy đúng trước go-live.
• Replication lag monitor: Nếu setup master-slave, monitor `Seconds_Behind_Master` qua `SHOW SLAVE STATUS` — alert khi vượt 5 giây.
• Connection pool check: 2 database = 2x connection — verify MySQL `max_connections` đủ buffer (mặc định 151 thường thiếu).

HyperDB config chi tiết

HyperDB là drop-in plugin Automattic chạy production trên WordPress.com với hàng triệu site. Free, không có UI — config hoàn toàn qua PHP file.

Cài qua FTP upload vào `wp-content/db.php` và root `db-config.php`.

// db-config.php — file cấu hình HyperDB
// Đặt ở root WordPress (cùng level với wp-config.php)

$wpdb->add_database(array(
    'host'     => DB_HOST,
    'user'     => DB_USER,
    'password' => DB_PASSWORD,
    'name'     => 'web22_wp',
    'write'    => 1,
    'read'     => 1,
    'dataset'  => 'global',
    'timeout'  => 0.2,
));

$wpdb->add_database(array(
    'host'     => DB_HOST,
    'user'     => DB_USER,
    'password' => DB_PASSWORD,
    'name'     => 'web22_wc',
    'write'    => 1,
    'read'     => 1,
    'dataset'  => 'wc',
    'timeout'  => 0.2,
));

// Route WooCommerce tables sang dataset 'wc'
$wpdb->add_table('wc', 'wp_woocommerce_*');
$wpdb->add_table('wc', 'wp_wc_*');
$wpdb->add_table('wc', 'wp_actionscheduler_*');

// Callback xử lý wp_postmeta theo nghiệp vụ
$wpdb->add_callback('wc_postmeta_callback');

function wc_postmeta_callback($query) {
    if (strpos($query, 'wp_postmeta') !== false) {
        if (strpos($query, '_woocommerce_') !== false ||
            strpos($query, '_billing_') !== false) {
            return 'wc';
        }
    }
    return false;
}

Sharding multi-store qua Multisite

Shop có nhiều brand hoặc nhiều thị trường (vd 1 brand thời trang nam, 1 brand nữ, 1 brand kids) chạy WordPress Multisite + WooCommerce trên mỗi subsite. Mỗi subsite có table prefix riêng (`wp_2_`, `wp_3_`) — sharding tự nhiên theo brand.

• Multi-site + multi-DB: Mỗi subsite WooCommerce route sang database riêng qua HyperDB — vd `wp_2_woocommerce_*` → `web22_brand_men`, `wp_3_woocommerce_*` → `web22_brand_women`.
• Shared customer database: Bảng `wp_users` và `wp_usermeta` để chung 1 DB cho phép SSO giữa brand — khách login 1 lần dùng cả 3 site.
• Reporting consolidate: Cron job nightly aggregate order từ 3 DB sang 1 reporting DB riêng — admin xem report tổng không phải query cross-DB realtime.

LudicrousDB và alternative plugin

HyperDB là default nhưng có alternative đáng cân nhắc. LudicrousDB là fork HyperDB do JJJ (John James Jacoby) maintain active hơn — feature gần tương đương nhưng update thường xuyên hơn, fix bug nhanh hơn.

So sánh HyperDB và LudicrousDB

• HyperDB: Maintain bởi Automattic, production-tested ở WordPress.com scale tỉ request/tháng — update 1-2 lần/năm nhưng stable cực kỳ cao.
• LudicrousDB: Maintain bởi JJJ, update 4-6 lần/năm, code clean hơn, có support PHP 8.x sớm hơn HyperDB.
• WP DB Driver (paid 199 USD): UI quản lý dễ hơn nhưng không production-tested scale lớn — recommend chỉ cho shop SME cần UI.

Migration giữa HyperDB và LudicrousDB

Cả 2 dùng cùng API và config file structure. Switch giữa 2 chỉ cần đổi file `db.php` drop-in, không phải reconfigure connection hay re-migrate data.

Test trên staging 1 tuần trước khi switch production.

Backup 3 lớp với replica

Database tách 2 phần cần strategy backup tương ứng. Backup 3 lớp đảm bảo recovery ở mọi scenario fail: corruption từng record, server hardware fail, datacenter outage.

Lớp 1 — Binlog replication realtime

• MySQL binlog enable: Bật `log_bin = mysql-bin` và `binlog_format = ROW` — every transaction ghi log realtime.
• Replica server slave: Setup slave database trên server khác, replicate từ master qua binlog — RPO dưới 5 giây.
• Failover plan: Slave promote thành master khi master fail — downtime 5-15 phút thay vì giờ.

Lớp 2 — mysqldump hàng ngày

• Cron nightly 2h sáng: Dump cả 2 database (`web22_wp` và `web22_wc`) ra file SQL nén gzip — chạy trên slave để không lock master.
• Retention 30 ngày: Giữ 30 bản nightly để rollback xa hơn — chiếm khoảng 30GB cho database 50GB nén gzip 60%.
• Off-site storage: Upload backup lên S3 hoặc Cloudflare R2 — protect khỏi datacenter outage hoặc ransomware tại server.

Lớp 3 — Snapshot disk hàng tuần

• VPS provider snapshot: Vultr, DigitalOcean, AWS đều có snapshot disk weekly — capture full state OS + data + config.
• Restore nhanh hơn mysqldump: Snapshot 50GB restore trong 10-15 phút vs mysqldump SQL restore 1-2 giờ — phù hợp disaster recovery.
• Retention 4 tuần: Giữ 4 snapshot rolling — đủ cover trường hợp phát hiện corruption sau vài tuần mới.

5 lỗi phổ biến khi tách database

• Foreign key reference break: WC table reference user/post ở WP core qua app layer (không phải FK MySQL) — verify integrity ở app code sau tách, đừng tin tưởng DB constraint.
• Plugin third-party fail silently: Plugin custom expect 1 connection — test toàn bộ plugin trên staging trước, plugin nào không multi-DB-aware phải patch hoặc drop.
• Backup script không sync timing: 2 DB cần 2 mysqldump cùng moment để order với product consistent — dùng Percona XtraBackup hoặc custom script lock-then-snapshot.
• Migration data loss vài row: Import miss 1-2 row do encoding utf8 vs utf8mb4 — verify count và checksum (`CHECKSUM TABLE`) trước switch connection.
• Object cache conflict với HyperDB: Plugin object cache cache `$wpdb` instance — disable cache khi setup HyperDB, re-enable sau khi verify stable 1 tuần.

Câu hỏi thường gặp

Tài nguyên và bước tiếp theo

Tách database là phase cuối của stack tối ưu performance WooCommerce. Trước khi tách, đảm bảo đã làm xong các layer cache và HPOS để loại trừ optimization rẻ hơn.

Bài liên quan cùng cụm performance WooCommerce:

• Redis Object Cache cho WooCommerce — setup và hit rate 90% — layer đầu tiên giảm load DB, làm trước khi tính tách.
• CDN cho shop online — 3 lớp asset, image, page — giảm origin load qua edge cache, tách DB chỉ giải phần backend.
• WooCommerce lưu lượng cao — kiến trúc scale — overview toàn stack performance gồm cache, DB, CDN, queue.
• Dịch vụ thiết kế website WooCommerce — gói thi công shop kèm tư vấn architecture scale.

Cần Web22 audit + tách database WooCommerce + setup HyperDB và migration plan turnkey? Báo giá website bán hàng WooCommerce — đội architect Web22 review kiến trúc shop và đề xuất roadmap scale phù hợp budget.