Posted inMySQL

Hướng dẫn quản lý High Availability cho MySQL với Orchestrator: Tự động vẽ topology và failover an toàn lúc 2h sáng

MySQL tutorial - IT technology blog
MySQL tutorial - IT technology blog

2 giờ sáng, chuông PagerDuty réo inh ỏi: CRITICAL - MySQL Master Unreachable. Bật vội terminal, SSH vào primary node thì connection timeout do kernel panic. Backend quăng lỗi 500 hàng loạt vì transaction bị nghẽn.

Nếu chưa có cơ chế High Availability (HA) tự động, bạn sẽ mất 15-30 phút toát mồ hôi. Bạn phải rà từng replica xem con nào ít lag nhất, promote nó lên rồi sửa connection string thủ công. Với Orchestrator, kịch bản nghẹt thở đó được xử lý gọn trong chưa đầy 15 giây.

Ba hướng tiếp cận HA phổ biến cho MySQL

Để dựng HA cho cụm MySQL replication, anh em DevOps thường cân nhắc ba giải pháp sau:

  • Keepalived / Corosync kết hợp VIP (Virtual IP): Dựng 2 node master-master hoặc active-passive dùng floating IP. Hai bên bắn heartbeat liên tục để kéo IP qua lại khi có sự cố.
  • MHA (Master High Availability): Bộ tool viết bằng Perl từng là tiêu chuẩn của ngành. MHA SSH vào từng node, check trạng thái, vá relay log còn thiếu rồi đẩy replica tốt nhất lên làm master.
  • Orchestrator: Công cụ mã nguồn mở do Shlomi Noach phát triển khi còn ở GitHub, viết bằng Go. Tool hoạt động như service độc lập, giao tiếp với MySQL qua cổng 3306 chuẩn, tự vẽ cây topology và failover dựa trên consensus giữa các replica.

So sánh chi tiết ưu nhược điểm

1. Keepalived + Virtual IP

Ưu điểm: Dựng rất nhanh, tốn ít tài nguyên và quen thuộc với dân sysadmin.

Nhược điểm: Thiếu hoàn toàn “tư duy database”. Keepalived chỉ check port 3306 hoặc ping ICMP. Nó không biết replica có đang lag 30 phút hay không, cũng không biết master có đang nghẽn I/O. Rủi ro lớn nhất là split-brain: hai node cùng nhận ghi đồng thời, khiến data bị phân mảnh và hỏng hoàn toàn.

2. MHA (Master High Availability)

Ưu điểm: Khả năng bù đắp dữ liệu binlog/relay log rất tốt, hạn chế tối đa mất mát transaction.

Nhược điểm: Bắt buộc cấp quyền SSH root không password giữa các server, tạo lỗ hổng bảo mật lớn. Dự án hiện đã ngừng bảo trì. Tool không có giao diện web và rất khó quản lý cụm replication nhiều tầng (intermediate master).

3. Orchestrator

Ưu điểm:

  • Không cần SSH, chỉ cần tài khoản MySQL riêng biệt với quyền replication cơ bản.
  • Giao diện Web UI trực quan, cập nhật topology theo thời gian thực. Bạn có thể kéo thả chuột để trỏ lại replica sang node mới khi bảo trì.
  • Cơ chế phát hiện lỗi theo cụm (holistic failure detection): Orchestrator chỉ kết luận master chết khi tất cả replica đều báo mất kết nối, tránh báo động giả do gián đoạn mạng cục bộ.
  • Hỗ trợ chuẩn MySQL GTID và Pseudo-GTID.

Nhược điểm: Orchestrator chỉ quản lý trạng thái topology và promote node. Bạn vẫn cần phối hợp với ProxySQL, Consul hoặc script chuyển VIP để trỏ traffic ứng dụng sang master mới.

Khi nào nên chuyển sang Orchestrator?

Nếu bạn quản lý cụm MySQL từ 1 Master và 3 Read Replicas trở lên, xử lý vài nghìn query mỗi giây, Keepalived sẽ bộc lộ rủi ro rất rõ. Orchestrator là lựa chọn cân bằng nhất: vừa cho phép đảo node thủ công bằng một cú click chuột khi bảo trì, vừa tự động cứu cụm database an toàn mà không lo split-brain.

Các bước triển khai Orchestrator thực tế

Bước 1: Tạo MySQL User cho Orchestrator

Trên tất cả các node trong cụm (cả Primary và Replicas), tạo một user giám sát:

-- Chạy lệnh này trên cả Master và tất cả Replicas
CREATE USER 'orc_client'@'192.168.1.%' IDENTIFIED BY 'MatKhauSieuKho123!';
GRANT SUPER, PROCESS, REPLICATION SLAVE, RELOAD ON *.* TO 'orc_client'@'192.168.1.%';
GRANT SELECT ON performance_schema.* TO 'orc_client'@'192.168.1.%';
FLUSH PRIVILEGES;

Bước 2: Chuẩn bị database backend cho Orchestrator

Orchestrator cần một database riêng để lưu trạng thái topology. Bạn có thể dùng SQLite khi test, nhưng trên production hãy tách riêng một instance MySQL:

CREATE DATABASE IF NOT EXISTS orchestrator;
CREATE USER 'orc_server'@'127.0.0.1' IDENTIFIED BY 'BackendPassOrc456!';
GRANT ALL PRIVILEGES ON orchestrator.* TO 'orc_server'@'127.0.0.1';
FLUSH PRIVILEGES;

Bước 3: Cài đặt và cấu hình Orchestrator service

Tải gói cài đặt trên server giám sát (Ubuntu/Debian):

curl -LO https://github.com/openark/orchestrator/releases/download/v3.2.6/orchestrator_3.2.6_amd64.deb
sudo dpkg -i orchestrator_3.2.6_amd64.deb

Cập nhật file cấu hình /etc/orchestrator.conf.json với các thông số quan trọng sau:

{
  "Debug": false,
  "EnableSyslog": true,
  "ListenAddress": ":3000",
  "MySQLOrchestratorHost": "127.0.0.1",
  "MySQLOrchestratorPort": 3306,
  "MySQLOrchestratorDatabase": "orchestrator",
  "MySQLOrchestratorUser": "orc_server",
  "MySQLOrchestratorPassword": "BackendPassOrc456!",
  "MySQLTopologyUser": "orc_client",
  "MySQLTopologyPassword": "MatKhauSieuKho123!",
  "DiscoverByShowSlaveHosts": true,
  "InstancePollSeconds": 5,
  "RecoveryPeriodBlockSeconds": 300,
  "Processes": {
    "PreGracefulTakeoverProcesses": [],
    "PostMasterFailoverProcesses": [
      "/usr/local/bin/notify_failover.sh {failureType} {failedHost} {successorHost}"
    ]
  }
}

Khởi chạy service:

sudo systemctl enable --now orchestrator
sudo systemctl status orchestrator

Bước 4: Nhận diện cụm replication

Truy cập Web UI tại http://<IP_ORCHESTRATOR>:3000. Để Orchestrator quét cụm, bạn nhập IP master vào menu Clusters > Discover hoặc chạy lệnh:

orchestrator -c discover -i 192.168.1.10:3306

Orchestrator sẽ kết nối vào node 192.168.1.10, chạy SHOW REPLICA HOSTS và tự động dựng sơ đồ cây phân cấp hoàn chỉnh trên giao diện.

Bước 5: Kích hoạt và thử nghiệm kịch bản failover

Để Orchestrator tự động xử lý khi master gặp sự cố, bật 3 tùy chọn sau trong /etc/orchestrator.conf.json:

{
  "ApplyMySQLPromotionAfterMasterFailover": true,
  "FailMasterPromotionIfSQLThreadNotUpToDate": true,
  "AutoMasterRecovery": true
}

Áp dụng cấu hình mới: sudo systemctl restart orchestrator.

Bây giờ, hãy thử mô phỏng sự cố: tắt tiến trình MySQL trên Master (192.168.1.10):

# Giả lập Master bị crash đột ngột
sudo systemctl stop mysql

Theo dõi luồng xử lý qua log:

sudo journalctl -u orchestrator -f

Orchestrator sẽ thực hiện chuỗi hành động theo thứ tự:

  1. Xác nhận mất kết nối tới 192.168.1.10 từ server Orchestrator.
  2. Kiểm tra tất cả Replica. Thấy IO thread của các node con đều ngắt kết nối, Orchestrator xác nhận trạng thái DeadMaster.
  3. So sánh Executed_Gtid_Set giữa các Replica và chọn node có dữ liệu mới nhất (ví dụ: 192.168.1.11).
  4. Chạy lệnh thăng cấp trên 192.168.1.11: tắt replication và mở quyền ghi (SET GLOBAL read_only = 0).
  5. Chuyển hướng các replica còn lại sang đồng bộ dữ liệu từ master mới 192.168.1.11.
  6. Gọi hook PostMasterFailoverProcesses để cập nhật route trên ProxySQL hoặc cập nhật DNS record.

Toàn bộ chuỗi thao tác hoàn tất trong khoảng 10-15 giây. Hệ thống phục hồi ghi mà không cần ai thức dậy can thiệp thủ công.

Share:
Tags: