Amazon Aurora MySQL Bài 4: Aurora Multi-AZ vs Read Replicas: Hiểu đúng về độ sẵn sàng cao (High Availability)

Khi xây dựng các hệ thống production chịu tải cao, khái niệm High Availability (HA) và Scale Đọc thường hay bị nhầm lẫn hoặc cấu hình chưa tối ưu. Trong Aurora MySQL, hai khái niệm này được thiết kế theo một cách hoàn toàn khác biệt so với MySQL truyền thống.

1. Khái niệm Multi-AZ trong Aurora MySQL nghĩa là gì? Ở cơ sở dữ liệu truyền thống (như RDS MySQL Multi-AZ), bạn có một Master instance ở AZ này và một Standby instance nằm ở AZ khác. Standby này hoàn toàn "ngủ đông" (không nhận query đọc), chỉ nhận dữ liệu đồng bộ qua binlog và chờ khi Master chết thì nó lên thay thế.

• Trong Aurora MySQL Multi-AZ:

  • Tầng lưu trữ (Storage Layer) mặc định luôn luôn Multi-AZ (6 bản sao trải trên 3 AZs như chúng ta đã tìm hiểu ở Bài 3).

  • Về tầng tính toán (Compute Layer), một cụm Aurora tối thiểu gồm 1 Writer Instance và có thể gắn thêm các Reader Instance nằm ở các AZ khác nhau.

  • Khi cấu hình Multi-AZ cho compute, AWS triển khai các bản sao tính toán (Reader/Standby compute) ở các AZ khác để sẵn sàng nhận quyền Writer nếu instance chính gặp sự cố.

2. Phân biệt rõ: Aurora Multi-AZ (Failover) vs Read Replicas (Scale đọc) Nhiều kỹ sư hay nhầm lẫn giữa việc thêm Read Replica để scale đọc và việc cấu hình Multi-AZ để chống sập hệ thống. Hãy phân tách rõ ràng:

• Aurora Multi-AZ Deployment (Đảm bảo High Availability & Failover):

  • Mục đích chính: Giảm thiểu Downtime khi phần cứng của Writer gặp sự cố hoặc mất mạng ở một AZ.

  • Cách hoạt động: Nếu Writer instance bị lỗi, Aurora tự động kích hoạt tiến trình Failover, chuyển một Reader hiện có (hoặc tạo một tiến trình compute mới) lên làm Writer mới trong vòng chưa đầy 30 giây. Ứng dụng gần như không bị gián đoạn kết nối dài.

• Aurora Read Replicas (Đảm bảo Scale Đọc & Tải nặng):

  • Mục đích chính: Chia sẻ tải đọc (Read-heavy workload) cho ứng dụng, giảm tải cho Writer instance.

  • Cách hoạt động: Bạn có thể scale thêm từ 1 đến tối đa 15 Read Replicas trong một cụm Aurora. Các Replica này đều trỏ chung vào một Aurora Storage Volume duy nhất, do đó không có độ trễ đồng bộ dữ liệu phức tạp như MySQL truyền thống.

3. Cơ chế Failover thông minh của Aurora so với RDS MySQL truyền thống

• RDS MySQL truyền thống: Khi xảy ra Failover, Standby phải thực hiện quá trình crash recovery trên ổ cứng cục bộ của nó, dẫn đến thời gian downtime có thể kéo dài từ 1 đến vài phút tùy thuộc vào lượng transaction chưa flush.

• Aurora MySQL: Do tầng storage đã tách biệt hoàn toàn và luôn ở trạng thái sẵn sàng, khi Writer die, Standby/Reader lên thay thế không cần thực hiện recovery dữ liệu trên đĩa. Dữ liệu đã sẵn sàng có sẵn trên shared storage volume, giúp thời gian Failover của Aurora cực kỳ nhanh (thường dưới 30 giây).

4. Góc nhìn vận hành cho Backend Engineer

• Thiết kế cụm tối ưu cho Production: Đối với hệ thống thật, bạn nên cấu hình ít nhất 1 Writer và 1 Reader nằm ở 2 Availability Zones khác nhau. Vừa đảm bảo có sẵn Read Replica để tối ưu hóa truy vấn đọc từ ứng dụng, vừa đóng vai trò là standby sẵn sàng Failover tự động khi cần.

• Định tuyến kết nối thông minh: Sử dụng Cluster Endpoint của Aurora cho mọi thao tác Ghi (INSERT, UPDATE, DELETE) và kết nối tới Reader Endpoint cho các tác vụ Đọc (SELECT).