Amazon Aurora MySQL Bài 9: Quản lý Endpoints trong Aurora: Cluster Endpoint vs Reader Endpoint vs Instance Endpoint

Khi cấu hình kết nối từ ứng dụng backend (Laravel, Go, Node.js) vào cơ sở dữ liệu Aurora MySQL, việc hiểu và sử dụng đúng các loại Endpoints quyết định đến tính sẵn sàng cao (High Availability) và khả năng cân bằng tải của hệ thống.

Khác với MySQL truyền thống nơi bạn phải cấu hình IP thủ công của Master/Slave, Amazon Aurora cung cấp sẵn các DNS Endpoints thông minh tự động quản lý việc định tuyến kết nối.

1. Phân loại các Endpoints trong Aurora MySQL

Một cụm Aurora Cluster cung cấp 3 loại endpoint chính phục vụ các mục đích khác nhau:

a. Cluster Endpoint (Writer Endpoint)

• Bản chất: Đây là điểm kết nối chính và quan trọng nhất của cụm, trỏ trực tiếp đến Writer Instance hiện tại.

• Cơ chế hoạt động:

  • Mọi câu lệnh ghi dữ liệu (INSERT, UPDATE, DELETE, DDL) bắt buộc phải đi qua endpoint này.

  • Tính năng Failover tự động: Khi Writer instance gặp sự cố và Aurora thực hiện quy trình bầu chọn (Failover) một Reader lên làm Writer mới, AWS sẽ tự động cập nhật bản ghi DNS của Cluster Endpoint để trỏ sang instance mới này trong vòng vài giây. Ứng dụng chỉ cần ngắt kết nối cũ và mở kết nối mới mà không cần đổi chuỗi cấu hình (DB_HOST).

• Ví dụ định dạng: hieu-aurora-cluster.cluster-c123456789.us-east-1.rds.amazonaws.com

b. Reader Endpoint (Load-balanced Read Endpoint)

• Bản chất: Endpoint chuyên trách cho các tác vụ đọc (SELECT), thực hiện cân bằng tải tự động cho toàn bộ các nút đọc trong cụm.

• Cơ chế hoạt động:

  • Mỗi khi ứng dụng gửi một request kết nối qua Reader Endpoint, Aurora sẽ sử dụng thuật toán DNS Round-Robin để phân phối kết nối đến một trong các Reader Instances hiện có trong cụm.

  • Nếu bạn scale thêm Read Replicas hoặc một Reader gặp sự cố, Reader Endpoint sẽ tự động cập nhật danh sách các node khả dụng mà không làm gián đoạn hệ thống.

• Ví dụ định dạng: hieu-aurora-cluster.cluster-ro-c123456789.us-east-1.rds.amazonaws.com

c. Instance Endpoint (Direct Node Endpoint)

• Bản chất: Endpoint riêng biệt định danh cho từng node cụ thể (cả Writer lẫn các Reader) trong cụm.

• Cơ chế hoạt động: Nó gắn chặt với một instance phần cứng cụ thể và không thay đổi theo thời gian hay trạng thái failover.

• Trường hợp sử dụng thực tế:

  • Rất ít khi được dùng trong chuỗi kết nối của ứng dụng production chính.

  • Thường dùng bởi các Database Administrator (DBA) hoặc công cụ giám sát khi cần debug hiệu năng, kiểm tra log, hoặc chạy câu lệnh EXPLAIN trên một node đọc cụ thể mà không muốn bị ảnh hưởng bởi cơ chế cân bằng tải của Reader Endpoint.

• Ví dụ định dạng: hieu-aurora-writer.c123456789.us-east-1.rds.amazonaws.com

2. Mở rộng nâng cao: Custom Endpoints

Ngoài 3 loại trên, Aurora còn cung cấp tính năng Custom Endpoints.

• Cho phép bạn nhóm một tập hợp các Read Replicas có cấu hình phần cứng lớn (db.r6g.2xlarge) thành một endpoint riêng biệt chuyên chạy các báo cáo nặng, tách biệt hoàn toàn với các Reader cấu hình nhỏ (db.r6g.large) phục vụ traffic đọc thông thường của người dùng.

3. Góc nhìn vận hành & Best Practices cho Backend Engineer

• Cấu hình chuỗi kết nối tách biệt (Read/Write Splitting):

  • Trong tệp cấu hình môi trường (.env của Laravel hoặc file config kết nối trong Go), hãy tách rõ ràng:

    • DB_WRITE_HOST = Cluster Endpoint (dùng cho các Model/Repository thực hiện ghi hoặc transaction).

    • DB_READ_HOST = Reader Endpoint (dùng cho các câu lệnh thống kê, lấy danh sách, trang chủ).

• Lưu ý về DNS TTL và Connection Persistence:

  • Khi xảy ra sự cố Failover, dù AWS cập nhật DNS của Cluster Endpoint ngay lập tức, một số ngôn ngữ hoặc framework (như PHP-FPM giữ persistent connection hoặc Go giữ long-lived connection pool) có thể vẫn lưu cache IP cũ.

  • Vì vậy, ứng dụng backend cần được cấu hình cơ chế bắt lỗi kết nối (Exception Handling) và tự động thử lại (Retry / Reconnect) thông minh để xử lý mượt mà trong khoảng thời gian diễn ra Failover ngắn ngủi.