Sự cố Database lúc 3 giờ sáng
Ít có điều gì phá hỏng ngày nghỉ cuối tuần tệ hơn một thông báo lúc 3 giờ sáng rằng node database chính của bạn đã bị sập. Trong mô hình single-master tiêu chuẩn, một lỗi nhỏ đồng nghĩa với việc ứng dụng của bạn sẽ ngừng hoạt động cho đến khi bạn nâng cấp một slave lên làm master hoặc khôi phục dịch vụ một cách thủ công. Sau khi quản trị MySQL, PostgreSQL và MongoDB trong nhiều môi trường production khác nhau, tôi nhận thấy rằng Galera Cluster cung cấp một trong những cách đáng tin cậy nhất để giữ cho dữ liệu luôn sẵn sàng mà không cần can thiệp thủ công.
Thiết lập Galera Cluster không chỉ đơn thuần là chạy các script. Nó đòi hỏi sự nắm vững về kiến trúc để duy trì thời gian hoạt động ngay cả khi toàn bộ trung tâm dữ liệu ngoại tuyến. Hướng dẫn này sẽ đi sâu vào cấu hình đã được kiểm chứng qua thực tế để đạt được tính sẵn sàng cao (High Availability).
Tại sao Multi-Master vượt trội hơn Replication truyền thống
Tại sao nên chọn Galera thay vì replication MySQL tiêu chuẩn? Hầu hết các thiết lập truyền thống sử dụng replication bất đồng bộ (asynchronous replication). Trong mô hình đó, master ghi dữ liệu và sau đó gửi nhật ký (logs) đến slave. Nếu phần cứng master bị lỗi trước khi các nhật ký đó được chuyển đi, bạn sẽ mất dữ liệu. Đối với một ứng dụng fintech hoặc nền tảng thương mại điện tử xử lý 10.000 USD doanh thu mỗi giờ, rủi ro đó là không thể chấp nhận được.
Galera Cluster sử dụng Synchronous Multi-Master Replication (Sao chép đa chủ đồng bộ). Mọi node trong cluster của bạn đều là các node ngang hàng giống hệt nhau. Khi Node A nhận được một lệnh ghi, nó sẽ ngay lập tức phát sóng lệnh đó tới Node B và Node C. Giao dịch chỉ được commit (xác nhận) khi toàn bộ cluster đạt được sự đồng thuận. Điều này có nghĩa là mọi node luôn có dữ liệu mới nhất, bất kể lệnh ghi xuất phát từ đâu.
Đánh giá các sự đánh đổi
Galera rất mạnh mẽ, nhưng nó không phải là giải pháp “vạn năng”. Bạn phải hiểu chi phí về hiệu năng trước khi chuyển đổi các workload thực tế của mình.
Ưu điểm
- Tính sẵn sàng cao thực thụ: Không có điểm lỗi duy nhất (single point of failure). Nếu một máy chủ gặp sự cố, các máy chủ khác vẫn tiếp tục phục vụ lưu lượng truy cập mà không gặp trở ngại nào.
- Đảm bảo tính toàn vẹn dữ liệu: Việc commit đồng bộ có nghĩa là không mất dữ liệu khi một node bị lỗi.
- Khả năng mở rộng đọc (Read Scalability): Bạn có thể phân phối các truy vấn đọc trên tất cả các node. Trong cluster 3 node, điều này giúp tăng gấp ba lần thông lượng đọc của bạn.
- Tự phục hồi: Các node mới tham gia và đồng bộ hóa thông qua State Snapshot Transfers (SST) một cách tự động.
Thách thức
- Độ trễ ghi tăng lên: Hãy chuẩn bị cho việc độ trễ tăng thêm từ 5ms đến 15ms cho mỗi lần ghi. Mọi node phải xác nhận giao dịch trước khi nó hoàn tất.
- Hiệu ứng “mắt xích yếu nhất”: Nếu Node C có CPU hoặc ổ đĩa chậm, nó sẽ kìm hãm hiệu năng của cả Node A và Node B.
- Xung đột Rollback: Nếu hai người dùng cập nhật chính xác cùng một hàng trên các node khác nhau vào cùng một mili giây, cluster sẽ buộc một trong hai phải rollback (hoàn tác).
Tiêu chuẩn 3-Node cho môi trường Production
Luôn hướng tới mục tiêu tối thiểu 3 node trong môi trường production. Điều này giúp tránh kịch bản “split-brain” (chia cắt não bộ) đáng sợ. Nếu cluster 2 node bị mất kết nối giữa các node, cả hai có thể giả định rằng node kia đã chết và cố gắng giành quyền kiểm soát. Với ba node, hai node vẫn có thể giao tiếp with nhau sẽ tạo thành một “quorum” (đa số). Chúng sẽ tiếp tục trực tuyến trong khi node bị cô lập sẽ tự tắt một cách an toàn để ngăn chặn hư hỏng dữ liệu.
Đối với thiết lập này, chúng ta sẽ sử dụng Ubuntu 22.04 và MariaDB. Trước khi bắt đầu, hãy đảm bảo các security group của bạn cho phép lưu lượng truy cập trên các cổng cụ thể sau:
- 3306: Lưu lượng MySQL tiêu chuẩn
- 4567: Galera Cluster replication
- 4568: Incremental State Transfer (IST)
- 4444: State Snapshot Transfer (SST)
Triển khai từng bước
1. Cài đặt MariaDB
Cập nhật trình quản lý gói và cài đặt MariaDB server trên cả ba node cùng lúc.
sudo apt update
sudo apt install mariadb-server -y2. Định nghĩa cấu hình Galera
Tạo một tệp cấu hình tùy chỉnh tại /etc/mysql/mariadb.conf.d/60-galera.cnf. Mặc dù địa chỉ cluster giống nhau cho tất cả các node, bạn phải tùy chỉnh wsrep_node_address cho từng máy chủ.
[galera]
# Cấu hình Cluster chính
wsrep_on = ON
wsrep_provider = /usr/lib/galera/libgalera_smm.so
wsrep_cluster_name = "prod_cluster_01"
wsrep_cluster_address = "gcomm://10.0.0.1,10.0.0.2,10.0.0.3"
binlog_format = row
default_storage_engine = InnoDB
innodb_autoinc_lock_mode = 2
# Định danh Node
wsrep_node_address = "10.0.0.1" # Sử dụng IP nội bộ của node này
wsrep_node_name = "node-01" 3. Khởi tạo Cluster
Bạn không thể khởi động tất cả các node cùng một lúc. Node đầu tiên cần phải “bootstrap” cluster vì chưa có node ngang hàng nào để tham gia. Trên Node 1, hãy dừng dịch vụ và chạy lệnh bootstrap:
sudo systemctl stop mariadb
sudo galera_new_clusterNode 1 hiện là thành phần chính của mạng lưới mới của bạn.
4. Kết nối các Node còn lại
Trên Node 2 và Node 3, chỉ cần khởi động lại dịch vụ MariaDB. Chúng sẽ nhìn thấy các IP trong cấu hình, kết nối tới Node 1 và bắt đầu quá trình đồng bộ hóa.
sudo systemctl restart mariadb5. Xác nhận trạng thái Cluster
Xác minh thiết lập bằng cách đăng nhập vào MariaDB shell. Kiểm tra kích thước cluster để đảm bảo tất cả các node đều hiển thị.
mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_cluster_size';"Nếu kết quả trả về là 3, cluster multi-master của bạn đã chính thức hoạt động.
Kinh nghiệm thực tế
Xây dựng cluster là bước đầu tiên, nhưng duy trì nó đòi hỏi các thói quen vận hành cụ thể. Dưới đây là ba bài học tôi đã rút ra từ việc quản lý các hệ thống quy mô lớn.
Ưu tiên IST hơn SST
Khi một node khởi động lại, nó thực hiện chuyển giao trạng thái (State Transfer). SST là việc xóa sạch và sao chép toàn bộ dữ liệu, điều này có thể làm nghẽn mạng nếu bạn có 500GB dữ liệu. IST chỉ gửi các giao dịch còn thiếu. Để ưu tiên IST, hãy tăng gcache.size của bạn lên một mức đáng kể, chẳng hạn như 1G hoặc 2G, tùy thuộc vào khối lượng ghi của bạn. Điều này cho phép các node phục hồi sau các đợt ngoại tuyến ngắn mà không cần đồng bộ hóa toàn bộ.
Triển khai Load Balancer
Galera đồng bộ hóa dữ liệu, nhưng nó không quản lý lưu lượng truy cập của bạn. Nếu ứng dụng của bạn trỏ đến một IP duy nhất, bạn vẫn có một điểm lỗi duy nhất. Hãy sử dụng ProxySQL hoặc HAProxy để đứng trước các node. Các công cụ này giám sát sức khỏe của node và tự động chuyển hướng lưu lượng nếu một máy chủ không phản hồi.
Quản lý các tác vụ ghi dữ liệu lớn
Galera hoạt động cực tốt với các giao dịch nhỏ và nhanh. Tuy nhiên, việc chạy lệnh DELETE trên 5 triệu hàng cùng một lúc có thể khiến toàn bộ cluster bị đình trệ. Điều này xảy ra vì mọi node phải xử lý tập hợp dữ liệu ghi khổng lồ đó cùng một lúc. Luôn chia nhỏ các thao tác lớn thành các đợt nhỏ từ 2.000 đến 5.000 hàng để giữ cho cluster luôn phản hồi nhanh chóng.
Chuyển sang mô hình High Availability đòi hỏi một cách tiếp cận vận hành khác so với việc quản lý một máy chủ đơn lẻ. Mặc dù Galera thêm vào một số phức tạp ban đầu, nhưng sự an tâm khi biết dữ liệu của bạn được sao chép theo thời gian thực trên nhiều vùng lỗi là hoàn toàn xứng đáng với công sức bỏ ra.
