“Foursquare长达11小时的宕机”分析

TomLeng

主要原因：
----- MongoDB -----
1. sharding间数据分配不平衡，一台67GB，一台50GB
2. 数据碎片的回收和复用机制太烂，repairDatabase()后减小到了20GB
3. repairDatabase()方法效率较低，无法使用多核CPU
----- Foursquare OPS -----
4. 监控不到位，物理内存66GB，sharding达到67GB了都不知道
5. 容量规划不够超前

从中学习：
1. 监控数据量，很重要
2. 定期对slave下线做repairDatabase()，再替换Master
3. sharding达到物理内存的80%，就要做扩容规划
4. sharding容量分配的适当人工干预，手动搬迁部分chunk
5. 如果sharding出现容量问题，最先做repairDatabase()，再加新sharding