Amazon Aurora MySQL Bài 18: Tùy chỉnh Priority Tier cho việc bầu chọn Writer mới khi Failover

Ở Bài 17, chúng ta đã tìm hiểu cách Aurora tự động chuyển đổi quyền ghi sang một Reader mới khi Writer instance gặp sự cố. Tuy nhiên, một câu hỏi quan trọng đặt ra cho đội ngũ vận hành là: Làm sao để hệ thống biết chính xác nên chọn nút nào làm Writer mới trước tiên khi có từ 2 đến 3 Read Replicas đang chạy trong cụm?

Nếu bạn để AWS tự chọn ngẫu nhiên, một Read Replica có cấu hình phần cứng nhỏ (db.r6g.large) hoặc nằm ở một Availability Zone phụ có thể vô tình được đẩy lên làm Writer thay vì nút phần cứng khủng (db.r6g.2xlarge) chạy ở AZ chính, dẫn đến nguy cơ quá tải ngay sau khi Failover.

Bài viết này sẽ mổ xẻ cách sử dụng Promotion Tier (Cấp độ ưu tiên) để kiểm soát hoàn toàn quy trình này.

1. Cơ chế Promotion Tier trong Aurora MySQL là gì?

Promotion Tier là một tham số cấu hình trên mỗi Read Instance trong cụm Aurora, cho phép bạn xếp hạng mức độ ưu tiên của các nút khi diễn ra quá trình Failover tự động.

• Thang đo ưu tiên: Giá trị dao động từ 0 đến 15.

  • Tier 0: Mức ưu tiên cao nhất. Nút mang giá trị này sẽ được Aurora ưu tiên tuyệt đối đẩy lên làm Writer đầu tiên khi sự cố xảy ra.

  • Tier 1 đến Tier 15: Các mức ưu tiên giảm dần. Nếu nút ở Tier 0 không khả dụng (ví dụ cả AZ chứa nút đó chết), Aurora sẽ quét đến các nút có Tier tiếp theo.

• Quy tắc khi trùng Tier: Nếu có nhiều Read Replicas cùng được cấu hình chung một mức Tier (ví dụ cùng là Tier 1), Aurora sẽ tự động ưu tiên chọn nút có kích thước phần cứng lớn nhất (Instance Size) để làm Writer mới nhằm đảm bảo hiệu năng xử lý.

2. Chiến lược thiết kế Promotion Tier chuẩn Production

Để tối ưu hóa hiệu năng và giảm thiểu rủi ro khi xảy ra sự cố, bạn nên áp dụng mô hình phân bổ Tier thực tế sau cho cụm Aurora gồm 1 Writer và 3 Readers:

• Writer hiện tại: Mặc định luôn có Promotion Tier tương ứng (thường quản lý tự động bởi cluster).

• Reader 1 (Bản sao chủ lực - Cùng cấu hình Writer, đặt cùng AZ chính):

  • Cấu hình Promotion Tier = 0.

  • Lý do: Đảm bảo khi Writer chết, nút này lên thay thế lập tức với cấu hình phần cứng tương đương, không làm gián đoạn tải ghi lớn.

• Reader 2 (Bản sao dự phòng vùng khác - Cùng cấu hình, đặt ở AZ phụ):

  • Cấu hình Promotion Tier = 1.

  • Lý do: Nếu toàn bộ AZ chính sập nguồn, nút này ở AZ khác sẽ được kích hoạt làm Writer.

• Reader 3 (Bản sao cấu hình nhỏ chuyên phục vụ báo cáo / analytics):

  • Cấu hình Promotion Tier = 15 (hoặc đặt giá trị false cho khả năng promote).

  • Lý do: Nút này có cấu hình phần cứng nhỏ (db.r6g.large), tuyệt đối không bao giờ muốn nó lên làm Writer cho hệ thống chính, tránh việc bị nghẽn CPU/RAM ngay lập tức khi gánh lượng request ghi của toàn bộ ứng dụng.

3. Cấu hình Promotion Tier qua Terraform

Trong môi trường Enterprise, việc cấu hình này được quản lý chặt chẽ bằng code Terraform. Dưới đây là đoạn script minh họa:

Terraform

# Reader 1: Ưu tiên số 1 khi Failover (Tier 0)
resource "aws_rds_cluster_instance" "aurora_reader_1" {
  identifier         - "hieu-aurora-reader-high-priority"
  cluster_identifier - aws_rds_cluster.aurora_cluster.id
  instance_class     - "db.r6g.xlarge"
  engine             - aws_rds_cluster.aurora_cluster.engine
  engine_version     - aws_rds_cluster.aurora_cluster.engine_version
  
  # Cấu hình Promotion Tier cao nhất
  promotion_tier     - 0
}

# Reader 2: Nút chuyên báo cáo, KHÔNG BAO GIỜ cho lên làm Writer (Tier 15)
resource "aws_rds_cluster_instance" "aurora_reader_analytics" {
  identifier         - "hieu-aurora-reader-analytics"
  cluster_identifier - aws_rds_cluster.aurora_cluster.id
  instance_class     - "db.r6g.large"
  engine             - aws_rds_cluster.aurora_cluster.engine
  engine_version     - aws_rds_cluster.aurora_cluster.engine_version
  
  # Cấu hình Promotion Tier thấp nhất để tránh việc bị promote nhầm
  promotion_tier     - 15
}

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

• Kiểm tra định kỳ (Failover Drills): Việc thiết lập Promotion Tier trên giấy là chưa đủ. Đội ngũ kỹ thuật nên thực hiện các bài tập giả lập sự cố (Manual Failover trên AWS Console bằng lệnh Failover DB cluster) trong môi trường Staging để kiểm tra xem hệ thống có chọn đúng node ưu tiên hay không và thời gian ứng dụng tự kết nối lại mất bao lâu.

• Tránh "Hố đen" cấu hình: Đừng bao giờ để tất cả các Read Replicas đều mang giá trị Tier 1 nếu chúng có cấu hình phần cứng khác nhau, vì điều đó sẽ làm mất quyền kiểm soát chủ động của bạn đối với tài nguyên cơ sở dữ liệu trong các tình huống khẩn cấp.