Amazon Aurora MySQL Bài 43: Deep Dive vào cơ chế Disaster Recovery & Multi-AZ Automatic Failover thực tế

Trong các hệ thống backend chạy ở môi trường Production, việc cụm cơ sở dữ liệu gặp sự cố phần cứng đột ngột là điều không thể tránh khỏi. Sự khác biệt giữa một hệ thống bình thường và một hệ thống chuẩn Enterprise nằm ở khả năng tự phục hồi (Self-healing) và thời gian gián đoạn tối thiểu (Downtime).

Bài viết này sẽ mổ xẻ chi tiết cơ chế Disaster Recovery (DR) và quy trình Multi-AZ Automatic Failover bên trong hạ tầng phân tán của Amazon Aurora MySQL.

1. Kiến trúc High Availability (HA) cơ bản của Aurora

Khác với MySQL truyền thống thường phụ thuộc vào các tiến trình replication ứng dụng dễ bị nghẽn, Aurora được thiết kế từ gốc để đạt tính sẵn sàng cao:

• Tầng lưu trữ phân tán (Storage Tier): 6 bản sao (Storage Volumes) tự động phân bổ trên ít nhất 3 vùng sẵn sàng (Availability Zones - AZs). Ngay cả khi 2 AZ bị sập hoàn toàn cùng một lúc, dữ liệu vẫn được bảo vệ tuyệt đối và cụm database vẫn tiếp tục đọc/ghi được (nhờ cơ chế Quorum).

• Tầng tính toán (Compute Tier): Gồm 1 Writer Instance (chịu trách nhiệm ghi và đọc) và từ 1 đến nhiều Reader Instances (chịu trách nhiệm đọc và dự phòng nóng).

2. Cơ chế Automatic Failover diễn ra như thế nào khi Writer "Sập nguồn"?

Khi Writer instance hiện tại gặp sự cố bất ngờ (lỗi phần cứng vật lý, treo tiến trình, hoặc mất kết nối mạng nghiêm trọng):

1. Phát hiện sự cố (Health Check): Aurora tự động giám sát sức khỏe của Writer liên tục. Nếu Writer không phản hồi các gói tin tín hiệu (heartbeats) trong một khoảng thời gian ngắn, AWS Control Plane sẽ đánh dấu Writer đó đã chết (Unhealthy).

2. Bầu chọn Reader làm Writer mới (Promotion):

   • Aurora sẽ chọn một trong các Read Replicas hiện có (ưu tiên replica có cấu hình phần cứng lớn nhất hoặc có độ trễ thấp nhất) để thăng cấp lên làm Writer mới.

   • Quá trình thăng cấp diễn ra cực kỳ nhanh chóng vì tầng lưu trữ (Storage Volume) đã được chia sẻ sẵn sàng; instance mới không cần phải copy lại dữ liệu từ đầu mà chỉ cần gắn kết (mount) trực tiếp vào phân vùng storage đó.

3. Cập nhật DNS nội bộ: Endpoint của cụm (Cluster Endpoint) được tự động trỏ lại sang IP của Writer mới.

3. Thời gian Downtime thực tế (RTO) trong quá trình Failover

• RTO (Recovery Time Objective): Toàn bộ quá trình từ lúc Writer cũ chết đến khi Reader mới lên thay thế và bắt đầu nhận các câu lệnh ghi thường chỉ kéo dài từ 15 đến 30 giây.

• Ảnh hưởng đối với ứng dụng Backend: Trong khoảng thời gian ngắn ngủi này, các câu lệnh INSERT/UPDATE gửi tới database sẽ trả về lỗi kết nối tạm thời. Nếu ứng dụng của bạn có cơ chế thử lại (Retry mechanism) hoặc sử dụng AWS RDS Proxy (như đã học ở Bài 26), các request này sẽ được giữ lại trong hàng đợi của proxy và tự động thực thi ngay khi Writer mới sẵn sàng, giúp ứng dụng hoàn toàn không cảm thấy sự gián đoạn.

4. Chủ động thực hiện Manual Failover (Switchover) phục vụ bảo trì

Đôi khi, đội ngũ DevOps cần thực hiện bảo trì định kỳ, nâng cấp phiên bản phần cứng hoặc vá lỗi hệ thống mà không muốn chờ sự cố xảy ra. Lúc này, bạn có thể chủ động ra lệnh Failover thủ công (Switchover):

Bash

# Thực hiện Failover thông qua AWS CLI
aws rds failover-db-cluster \
    --db-cluster-identifier hieu-aurora-cluster \
    --target-db-instance-identifier hieu-aurora-reader-az2

• Lợi ích: Quá trình chuyển đổi diễn ra an toàn, có kiểm soát, giúp bạn kiểm chứng tính sẵn sàng của hệ thống trong môi trường giờ hành chính thay vì phải đối mặt với sự cố bất ngờ giữa đêm khuya.

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

• Phân bổ Multi-AZ chính xác: Khi thiết lập cụm Aurora, tuyệt đối không đặt Writer và tất cả các Reader nằm chung trong một AZ. Hãy đảm bảo các instance được phân bổ rải rác ít nhất trên 2 đến 3 AZ khác nhau để cơ chế Failover có không gian hoạt động khi một trung tâm dữ liệu của AWS gặp sự cố.

• Xử lý ngoại lệ trong Code (Exception Handling): Đảm bảo mã nguồn backend luôn có các khối try-catch bắt lỗi mất kết nối cơ sở dữ liệu và kích hoạt lại kết nối (reconnect) thông minh để hệ thống tự phục hồi mượt mà sau các tình huống chuyển đổi cụm.