在 LAMP 堆棧中，有哪些明顯的方法可以利用臨時 SSD 儲存？
在這裡，我說的是雲伺服器（來自任何供應商），它具有一定數量的臨時 SSD 儲存。使用標準映像時，預設情況下，此臨時 SSD 儲存被浪費且未被利用。
在此類 VM 上部署 LAMP 堆棧時，有哪些明顯的方法可以利用臨時 SSD 儲存？
一個明顯的例子是將交換文件和 /tmp 放在臨時文件上。
還有什麼是低垂的果實？事情如此明顯以至於只有不稱職的系統管理員才會錯過？
/tmp和 swap 確實是顯而易見的唾手可得的果實。我建議，我能想到的其他任何東西都將是特定於應用程序的。
要麼，要麼你和我都是比較無能的系統管理員，因為我們都忽略了一些明顯的東西。
臨時儲存是免費且快速的，並且可以在使用者啟動的實例重啟後繼續存在，所以實際上，任何最終“一次性”的東西都可以（自動）從其他地方暫存（可能從程式碼儲存庫複製或從儲存在 S3 中的壓縮包中提取）當實例啟動或以其他方式從其來源派生時。
當您完全“思考雲”時，許多人會爭辯說，基本上許多或大多數伺服器上的所有東西都應該是一次性的……我建議我們中的許多人或大多數人認識到這種趨勢，但只是在我們那裡——我們還沒有t 完全到達。
如果您的系統日誌是遠端收集的，那麼您的本地系統日誌可能會轉到一個臨時磁碟。Web 伺服器或代理日誌也是如此，當日誌的內容不被認為特別有價值或者您收集它們主要是因為您可以。
說到“僅僅因為你可以”，在一種情況下，我在物理數據中心有一台帶有 SAN 陣列的舊式伺服器，其中有大量靜態資產最終將遷移到 S3。在那之前，除了計劃的備份之外，在臨時驅動器沒有任何特別明確用途的某些情況下，文件還會同步到臨時驅動器。這些用作線上備用副本，並且在發生災難性事件時比從備份恢復要快得多。
我們有一個應用程序，它每天兩次完全從頭開始（從其他來源）建構大量 SOLR 索引，然後將其推送到主伺服器。這不是經典意義上的“臨時”空間，但是是的，它建立在臨時磁碟上。
我的一個暫存數據庫伺服器設置作為一個特定於應用程序的範例浮現在腦海中……它僅用於針對生產數據庫的複製測試程式碼。整個 MySQL 備份儲存在一個臨時磁碟上。我已經自定義了 initscript，因此“sudo service mysql resync”停止 MySQL 伺服器守護程序，將目前目錄移開（用文件名中的日期和時間重命名），複製（從 EBS）新的備份儲存MySQL安裝，符號連結
/usr/local/mysql/data到新的臨時目錄，啟動 MySQL，獲取生產數據庫的實時副本，載入它……開發人員現在擁有生產數據庫的相同複製……當然，這是一次性的，因為它立即“陳舊” " 並且僅用於測試程式碼。如果您從 AMI 啟動其中一個新的，它會醒來並意識到它沒有數據庫，並立即獲取主數據庫的新副本。另一種情況可能是集群數據庫，其中所有節點都擁有所有數據的副本並作為仲裁執行（如 MariaDB Galera 集群）。這樣的集群，特別是在地理分佈的情況下，需要適當選擇（通常是奇數）數量的正常執行的節點，因為作為保護措施，整個集群將在隔離事件（分區）中變得不可用，除非仍然存在單個分區包含分裂發生前線上的節點數的一半以上。2 節點集群或 4 節點集群在從中間拆分時變得無用，因為沒有剩餘多數。這有時通過一個“仲裁者”節點來解決，該節點在仲裁中投票，但實際上並沒有數據的副本。它的全部存在是為了讓集群保持快樂。
一個可能有趣的想法是在 RAID-1 配置中將臨時卷與 EBS 卷結合起來。取決於你相信誰，當同時讀取多個文件時，讀取 I/O 可能會增加近一倍。
我擔心我已經在某種程度上偏離了 DBA 領域的答案，但這些是我在我的世界中使用臨時卷的類型……除了顯而易見的，你已經確定了。