Amazon Aurora MySQL Bài 8: Hiểu rõ vai trò của Writer Instance và Reader Instance trong Aurora Cluster

Khi ứng dụng backend kết nối vào một cụm Amazon Aurora MySQL, việc phân định rõ ràng vai trò của từng loại instance (nút tính toán) là tối quan trọng. Nếu cấu hình sai, ứng dụng có thể gặp lỗi ghi trên nút đọc hoặc lãng phí tài nguyên hệ thống.

Bài viết này sẽ mổ xẻ chi tiết vai trò, kiến trúc phân phối tải và cách quản lý giữa Writer Instance và Reader Instance trong Aurora Cluster.

1. Phân định vai trò cốt lõi trong Aurora Cluster

Một cụm Aurora MySQL hoàn chỉnh bao gồm một lớp lưu trữ chung (Storage Volume) và hai loại node tính toán (Compute Nodes) chính:

• a. Writer Instance (Nút ghi chính):

  • Chức năng duy nhất: Xử lý tất cả các câu lệnh thao tác ghi dữ liệu (INSERT, UPDATE, DELETE, DDL như CREATE TABLE, ALTER TABLE, v.v.).

  • Số lượng: Trong một cụm tiêu chuẩn, luôn có đúng 1 Writer Instance chịu trách nhiệm nhận mọi request thay đổi dữ liệu và thực hiện các transaction ghi trực tiếp xuống tầng lưu trữ phân tán.

  • Đọc/Ghi: Writer cũng có khả năng đọc dữ liệu (SELECT), nhưng thông thường trong các hệ thống lớn, ta hạn chế dùng Writer cho các câu lệnh SELECT nặng để tập trung tài nguyên cho việc ghi.

• b. Reader Instance (Nút đọc phụ / Replica):

  • Chức năng: Chuyên trách xử lý các câu lệnh truy vấn đọc (SELECT).

  • Số lượng: Có thể cấu hình từ 0 đến tối đa 15 Reader Instances trong một cụm Aurora. Các Reader này hoạt động hoàn toàn độc lập về CPU và RAM, giúp chia nhỏ tải đọc (Read-heavy workloads) cho ứng dụng.

  • Tính chất: Reader không thể thực thi các câu lệnh ghi dữ liệu. Nếu ứng dụng cố tình gửi một câu lệnh INSERT hoặc UPDATE vào Reader Instance, Aurora sẽ trả về lỗi OperationalError: The MySQL server is running with the --read-only option.

2. Điểm khác biệt trong cơ chế đồng bộ so với MySQL truyền thống

• MySQL truyền thống (Master-Slave Replication): Master phải ghi binlog xuống ổ đĩa cục bộ của nó, sau đó truyền luồng binlog đó qua mạng tới Slave. Slave nhận được rồi phải ghi tiếp xuống đĩa của nó và chạy lại (replay) các câu lệnh đó. Quá trình này tạo ra độ trễ (Replication Lag) rất lớn và tốn băng thông mạng.

• Aurora MySQL Cluster: Tất cả các Reader Instances đều đọc chung một Aurora Storage Volume bên dưới (như đã phân tích ở Bài 2 và 3). Khi Writer thực hiện ghi dữ liệu và hoàn thành xác nhận log xuống tầng storage, các Reader gần như lập tức "nhìn thấy" sự thay đổi dữ liệu đó ở tầng lưu trữ.

  • Kết quả: Replication Lag trong Aurora cực kỳ thấp, thường chỉ từ vài mili-giây đến dưới 10ms, giúp dữ liệu trên các nút đọc luôn ở trạng thái gần như tức thời (Near Real-time).

3. Chiến lược định tuyến kết nối từ Backend Application

Để tận dụng tối đa sức mạnh của mô hình Writer/Reader, ứng dụng backend (Node.js, Go, Laravel, v.v.) cần được cấu hình hai loại kết nối riêng biệt:

• Kết nối Ghi (Write Connection): Trỏ thẳng vào Cluster Endpoint của Aurora. Endpoint này luôn tự động phân giải (DNS routing) trỏ về đúng Writer Instance hiện tại, ngay cả khi xảy ra sự cố Failover và Writer đổi sang một node khác.

• Kết nối Đọc (Read Connection): Trỏ vào Reader Endpoint của Aurora. Endpoint này tự động cân bằng tải (Load Balancing) vòng tròn (Round-Robin) giữa các Reader Instances có trong cụm.

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

• Tránh hiện tượng "Nghẽn cổ chai" ở Writer: Đừng cấu hình các tiến trình cronjob quét dữ liệu lớn, báo cáo thống kê phức tạp (SELECT hàng triệu dòng kèm GROUP BY) trỏ vào Writer Endpoint. Hãy luôn tách biệt rõ ràng luồng Write chạy qua Cluster Endpoint và luồng Read (báo cáo, thống kê, tìm kiếm) chạy qua Reader Endpoint.

• Tự động mở rộng Reader: Khi hệ thống chuẩn bị bước vào mùa cao điểm (ví dụ chiến dịch Flash Sale tại Hasaki), bạn có thể dễ dàng scale thêm số lượng Reader Instance chỉ bằng vài cú click trên AWS Console hoặc một lệnh apply qua Terraform để gánh lượng truy cập đọc khổng lồ từ người dùng mà không làm gián đoạn hệ thống.