Bảng cheat sheet kỹ thuật AWS cần thiết: EC2 → máy chủ Lambda → máy chủ giả EBS → ổ cứng S3 → ổ cứng chậm VPC → cosplay LAN IAM → quyền truy cập bị từ chối CloudWatch → "chúng tôi có datadog ở nhà"

Không bao giờ chạy truy vấn mà không có thời gian chờ. Một truy vấn bất thường hoặc đột biến tải có thể dẫn đến tình trạng ngừng hoạt động hoặc thời gian chết của ứng dụng nếu không có chúng. Hãy cùng suy nghĩ về lý do tại sao. Hãy xem xét trường hợp một truy vấn chạy lâu được vô tình đưa vào ứng dụng của chúng ta. Cơ sở dữ liệu thường chỉ xử lý các truy vấn ngắn hạn (10ms hoặc ít hơn) và đột nhiên chúng ta có một truy vấn mới mất 1000ms cho mỗi lần thực thi. Không chỉ điều này sẽ chiếm dụng tài nguyên, mà còn làm tăng số lượng giao dịch đồng thời. Chúng ta sẽ gặp phải giới hạn kết nối, giới hạn giao dịch, hoặc sử dụng 100% CPU / IOPS của cơ sở dữ liệu. Bây giờ hãy xem xét cùng một kịch bản, nhưng chúng ta đặt thời gian chờ 250ms cho mỗi giao dịch (ở phía cơ sở dữ liệu), với logic thử lại theo kiểu backoff mũi tên + jitter (ở phía ứng dụng). Chúng ta đã giới hạn phạm vi ảnh hưởng của bất kỳ truy vấn nào. Các truy vấn chạy lâu sẽ bị hủy, và logic backoff giảm thiểu rủi ro của việc hàng loạt truy vấn đồng thời. Bằng cách theo dõi những thời gian chờ này, chúng ta có thể nhanh chóng xác định truy vấn có vấn đề và hoàn tác thay đổi.

Nhật ký ghi trước (WAL) là cách mà các cơ sở dữ liệu cam kết nhanh chóng và cách mà chúng phục hồi an toàn từ các sự cố. Ngoài B-trees, có lẽ đây là cấu trúc quan trọng nhất trong Postgres và MySQL. (nó được gọi là "nhật ký redo" trong thế giới MySQL)