Amazon Aurora MySQL Bài 41: Xử lý sự cố cực đoan và Post-Mortem các ca sập cụm database thực tế (Disaster & Outage Post-Mortems)

Dù bạn đã thiết kế hệ thống tối ưu đến đâu, các sự cố ngoài ý muốn vẫn có thể xảy ra do lỗi mạng diện rộng của AWS, lỗi ứng dụng gây bão kết nối, hoặc xung đột transaction cấp hệ thống. Bài viết này sẽ phân tích cách chẩn đoán và xử lý các ca sự cố "khó nhằn" nhất trên Aurora MySQL.

1. Ca sự cố 1: Suy giảm Quorum lưu trữ (Storage Quorum Degradation)

• Triệu chứng: Ứng dụng đột ngột báo lỗi Lock wait timeout exceeded hoặc không thể thực hiện lệnh INSERT/UPDATE, trong khi CPU của Writer vẫn thấp.

• Nguyên nhân sâu xa:

  • Kiến trúc Aurora dựa trên 6 bản sao lưu trữ phân tán qua 3 AZ (như đã phân tích ở Bài 2).

  • Để ghi dữ liệu thành công, Aurora yêu cầu đạt mức Quorum (tối thiểu 4/6 bản sao phải xác nhận ghi). Nếu do sự cố hạ tầng ngầm của AWS khiến một AZ bị cô lập hoàn toàn, cụm storage có thể rơi vào trạng thái suy giảm khả năng ghi.

• Cách xử lý & Khắc phục:

  1. Kiểm tra trạng thái vùng lưu trữ trên AWS Personal Health Dashboard và RDS Console xem có thông báo bảo trì hoặc sự cố AZ hay không.

  2. Nếu cụm Writer mất khả năng ghi do hỏng Quorum, hãy chủ động kích hoạt lệnh Failover sang một Read Replica ở AZ khác đang hoạt động bình thường để khôi phục dịch vụ ngay lập tức.

2. Ca sự cố 2: Cascading Failure do Metadata Lock (MDL) bế tắc

• Triệu chứng: Toàn bộ API của backend bị treo (Pending / Timeout), số lượng kết nối DatabaseConnections vọt max chạm trần, nhưng trong Performance Insights không thấy câu lệnh SQL nào nặng.

• Nguyên nhân sâu xa:

  • Có một tiến trình dài hạn (ví dụ một câu lệnh SELECT chạy chậm hoặc transaction chưa commit) đang giữ bảng.

  • Khi một kỹ sư chạy lệnh ALTER TABLE hoặc một câu lệnh thay đổi cấu trúc bảng chen vào, lệnh đó bị xếp hàng chờ khóa metadata (Waiting for table metadata lock).

  • Toàn bộ các request SELECT/INSERT tiếp theo nối đuôi phía sau cũng bị khóa cứng theo, tạo ra hiệu ứng dây chuyền làm sập toàn bộ kết nối.

• Cách xử lý & Khắc phục:

  1. Truy cập database với quyền admin và chạy lệnh kiểm tra tiến trình đang bị kẹt:

     SQL

     SHOW PROCESSLIST;
     -- Hoặc truy vấn performance_schema để tìm tiến trình MDL đang khóa
     SELECT * FROM performance_schema.metadata_locks WHERE LOCK_STATUS = 'PENDING';
     
     

  2. Xác định PROCESS ID đang gây nghẽn và tiến hành ngắt kết nối an toàn:

     SQL

     KILL <process_id>;
     
     

  3. Ngay sau khi giết tiến trình kẹt, hàng ngàn request đang treo sẽ được giải phóng đồng loạt. Lúc này cần chuẩn bị sẵn sàng RDS Proxy để hứng lượng request dội về.

3. Ca sự cố 3: Đột biến Buffer Pool Eviction và Disk I/O Thashing

• Triệu chứng: Độ trễ (Latency) của các câu lệnh đọc tăng vọt từ vài mili-giây lên vài giây, chỉ số VolumeReadIOPS tăng đột biến, dù code ứng dụng không hề thay đổi.

• Nguyên nhân sâu xa:

  • Tập dữ liệu nóng (Working set size) của ứng dụng đã vượt quá dung lượng RAM của Buffer Pool hiện tại (ví dụ do bảng lịch sử log phình to đột ngột hoặc có câu lệnh SELECT quét toàn bộ bảng không index chạy lặp đi lặp lại).

  • Aurora liên tục phải đẩy dữ liệu cũ ra khỏi RAM để nạp dữ liệu mới vào (Buffer Pool Eviction), dẫn đến việc liên tục phải đọc từ tầng storage phân tán bên dưới.

• Cách xử lý & Khắc phục:

  1. Kiểm tra chỉ số BufferPoolHitRate trên CloudWatch. Nếu tụt dưới 95%, hệ thống đang thiếu RAM trầm trọng.

  2. Kiểm tra Performance Insights để tìm ra câu lệnh quét bảng lớn đang làm ô nhiễm Buffer Pool.

  3. Bổ sung Index ngay lập tức cho câu lệnh đó hoặc tiến hành Scale-up Aurora Instance lên một tier cao hơn (ví dụ từ db.r6g.large lên db.r6g.xlarge) để mở rộng dung lượng RAM tạm thời.

4. Quy trình Post-Mortem chuẩn Enterprise sau mỗi sự cố

Khi hệ thống đã ổn định trở lại sau một cơn sập nguồn, việc tổ chức họp Post-Mortem (Đánh giá sau sự cố) là bắt buộc để đội ngũ engineering không lặp lại vết xe đổ:

1. Timeline sự cố: Ghi lại chính xác từng mốc thời gian từ lúc hệ thống bắt đầu báo động đến khi khôi phục xong.

2. Xác định Root Cause (Nguyên nhân gốc rễ): Đừng chỉ dừng lại ở bề nổi (ví dụ: "do quá tải kết nối"), mà phải tìm đến cùng (vì sao quá tải? do thiếu RDS Proxy hay do một câu lệnh cronjob chạy sai logic?).

3. Action Items (Hành động khắc phục lâu dài): Đưa ra các hạng mục cải tiến kỹ thuật cụ thể (viết lại câu lệnh, bổ sung Alert cảnh báo sớm trên CloudWatch, hoặc tối ưu lại cấu hình Connection Pool).