卡桑德拉操作超時

操作超時 - 只收到0的響應'，信息： '表示從服務器'，代碼的錯誤消息：4608，稠度：1，接收：0， blockFor：1 ， isDataPresent：0， ...卡桑德拉操作超時

我每天都有幾次嘗試在我的cassandra集羣上執行SELECT查詢時發生此錯誤。我們在m1.large aws實例上有一個3節點的集羣。他們大部分時間都成功了，但每過一段時間我們都會遇到上述錯誤。我們還沒有生產，所以所有的桌子都很小。我們沒有超過幾千行的任何表，並且相同的查詢在其他時間完成罰款。提高時間不是一種選擇，我不相信它會解決問題（查詢應該很短，並且錯誤中的查詢每次都不相同）

這可能是一些連接過時節點之間還是網絡問題？什麼是測試這些的最佳方法？我也只在客戶端看到這個錯誤，是否應該在cassandra日誌中看到這個地方？

來源

2016-07-06 Alex Yurkowski

這實際上是從負責處理您的請求的C *服務器（又名'協調器'）返回的錯誤。

看起來您正在查詢一致性級別爲'ONE'，因此只有1個持有數據的副本需要響應服務器上cassandra.yaml文件中配置的read_request_timeout_in_ms內的協調器（默認值爲5秒），但在這段時間內沒有副本回復。

超時可能發生，您的應用程序應準備處理它們根據自己的喜好（或平出故障，重試，增加複製因子使其不太可能，等等）

這裏有一些事情你應該考慮：

增加您正在查詢數據的密鑰空間的複製因子。如果您的複製因子爲1，則依賴於1個節點可用於響應特定分區的查詢。將您的RF增加到3這樣的東西將使您的應用程序更好地適應性能不佳的節點或節點。
配置您的RetryPolicy根據您的行爲方式重試讀取操作。 nodejs-driver的默認設置是隻重試一次，只有在received>blockFor（在你的情況下不是這樣）。
在您的cassandra.yaml中增加read_request_timeout_in_ms。儘管如此，我仍然不鼓勵這樣做，除非你的配置/環境/查詢不合適，否則5000毫秒應該足夠綽綽有餘。

來源

2016-07-06 19:06:52

我們目前使用的是射頻（RF），所以數據至少包含2個節點。我減少了超時，因爲我不相信失敗的查詢會成功。這樣我們可以更快地失敗。它看起來像默認情況下10秒鐘內的範圍查詢超時。我知道我們應該能夠處理失敗，並且我們正在捕捉錯誤，但請求中的延遲對我們來說是個問題。我不認爲一個3節點的集羣應該經歷與我們的負載超時（小）這是我最關心的問題。我不希望更多的用戶超時，但這似乎與加載無關。 –

您是否在C *端進行任何類型的監控以查看是否可以對延遲進行任何可能的解釋？我建議看一看nodetool cfstats，看看是否能揭示任何東西，並監控任何類型的os統計信息，看看是否能給出任何見解。另一件可能有趣的事情是啓用查詢跟蹤，這將有助於解釋爲什麼查詢有時可能需要一段時間。 –

我們使用新的監督服務器和os統計數據，但沒有直接與cassandra關聯，但都看起來很好。我今天發現了這個實際問題，我們正在創建一個很長的feed，並且使用cassandra lucene插件進行的某個查詢花了很長時間，我們一次性解僱了很多人。這隻會偶爾發生，這就是爲什麼它很難追查。我改變了查詢，而不是在我們的流程中使用插件和過濾器，現在它運行良好。謝謝！ –

卡桑德拉操作超時

回答

相關問題