基本的 AWS 工程備忘單： EC2 → 伺服器 Lambda → 假伺服器 EBS → 硬碟 S3 → 慢硬碟 VPC → LAN 角色扮演 IAM → 許可被拒 CloudWatch → "我們家有 datadog"

永遠不要在沒有超時的情況下執行查詢。 一個惡意查詢或負載高峰可能會導致停滯或應用程式停機，沒有它們的話。我們來思考一下原因。 考慮一個情況，一個長時間運行的查詢不小心被引入到我們的應用程式中。數據庫通常只處理短暫的查詢（10毫秒或更少），而突然之間我們有了一個每次執行需要1000毫秒的新查詢。 這不僅會佔用資源，還會增加同時交易的數量。我們將會達到連接限制、交易限制，或者使用100%的數據庫CPU / IOPS。 現在考慮相同的情況，但我們在每個交易（數據庫端）上設置了250毫秒的超時，並且使用指數退避重試邏輯 + 顫動（應用程式端）。我們現在限制了任何單一查詢的影響範圍。長時間運行的查詢將被終止，而退避邏輯最小化了雷霆部隊的風險。 通過監控這些超時，我們可以快速識別出問題查詢並回滾更改。

預寫日誌（WAL）是資料庫快速提交和安全從崩潰中恢復的方式。 除了 B 樹之外，它可能是 Postgres 和 MySQL 中最重要的結構。 （在 MySQL 界，它被稱為 "重做日誌"）