你在用 db.collection.find() 的時候，它返回的不是所有的資料，而實際上是乙個「cursor」。
它的預設行為是：第一次向資料庫查詢 101 個文件，或 1 mb 的文件，取決於哪個條件先滿足；
之後每次 cursor 中的文件用盡後，查詢 4 mb 的文件。另外，find() 的預設行為是返回乙個
10 分鐘無操作後超時的 cursor。如果我乙個 batch 的文件十分鐘內沒處理完，過後再處理完了，
再用同乙個 cursor id 向伺服器取下乙個 batch，這時候 cursor id 當然已經過期了，這也就能解釋為啥我得到 cursor id 無效的錯誤了。
stack overflow 上有人提出過解決方法，是在 find() 時傳入 timeout=false 來禁用 10 分鐘超時的保護措施。但是我覺得這是非常差的辦法，因為如果你迴圈時產生異常，甚至斷電或斷網，都會導致 mongodb 伺服器資源永遠無法被釋放。而更好的辦法是（我也發在了 stack overflow 上），估計乙個 batch 大小，讓 mongodb 客戶端每次抓取的文件在 10 分鐘內能用完，這樣客戶端就不得不 10 分鐘內至少聯絡伺服器一次，保證 cursor 不超時。
具體用法：
for document in db.collection.find().batch_size(30):
SSH 連線超時解決辦法
高版本的 linux 自帶的openssh 在使用的時候，幾分鐘不操作的話就會自動斷開連線，這是出於安全的考慮，但是對於需要長時間使用的使用者來說很麻煩，每次都要重新連線。原因有多種 環境變數 tmout 引起,clientalivecountmax 和clientaliveinterval 設定問...
SSH 連線超時解決辦法
高版本的linux 自帶的openssh 在使用的時候，幾分鐘不操作的話就會自動斷開連線，這是出於安全的考慮，但是對於需要長時間使用的使用者來說很麻煩，每次都要重新連線。原因有多種,環境變數tmout 引起,clientalivecountmax 和clientaliveinterval 設定問題或...
SSH 連線超時解決辦法
高版本的 linux 自帶的openssh 在使用的時候，幾分鐘不操作的話就會自動斷開連線，這是出於安全的考慮，但是對於需要長時間使用的使用者來說很麻煩，每次都要重新連線。原因有多種 環境變數 tmout 引起,clientalivecountmax 和clientaliveinterval 設定問...