“Foursquare長達11小時的宕機”分析

TomLeng

主要原因：
----- MongoDB -----
1. sharding間數(shù)據(jù)分配不平衡，一臺67GB，一臺50GB
2. 數(shù)據(jù)碎片的回收和復(fù)用機制太爛，repairDatabase()后減小到了20GB
3. repairDatabase()方法效率較低，無法使用多核CPU
----- Foursquare OPS -----
4. 監(jiān)控不到位，物理內(nèi)存66GB，sharding達到67GB了都不知道
5. 容量規(guī)劃不夠超前

從中學(xué)習(xí)：
1. 監(jiān)控數(shù)據(jù)量，很重要
2. 定期對slave下線做repairDatabase()，再替換Master
3. sharding達到物理內(nèi)存的80%，就要做擴容規(guī)劃
4. sharding容量分配的適當人工干預(yù)，手動搬遷部分chunk
5. 如果sharding出現(xiàn)容量問題，最先做repairDatabase()，再加新sharding