在讀取之前計劃讀取修復

我有一個從Cassandra讀取數據的報告工具。配置是一致性級別是LOCAL_QUORUM，壓縮策略是大小等級和RF = 3。在讀取之前計劃讀取修復

當報表工具向Cassandra發出拉請求時，按照Cassandra設計，它會觸發讀數據一致性修復。實際上這是很好的設計。但閱讀維修費用昂貴，報告花費的時間更長。

我的報告用戶只在上午6點IST之後纔開始生成報告。是否有任何方法在用戶開始使用報告之前計劃讀取修復。例如，我確實計劃並在6 AM IST之前完成讀取修理。因此，在6點IST之後，所有的數據將包含在整個集羣中。

在這種情況下，一旦報告開始從Cassandra讀取數據，它就不應該再次觸發讀取修復，因爲我們剛剛完成作爲計劃作業的修復讀取。 6 AM IST發生後，我很滿意不一致的數據寫入/更新。哪種技術可以安排讀取維修，如果最近完成，我們是否真的避免讀取維修？ -Suyodha

來源

2016-07-31 Madhu Mohan Kommu

如果您使用傳統的反熵修復，那麼您可以在一致性級別上進行讀取：ONE。

有很多方法可以做到反熵修復，最明顯的是nodetool repair（有可能與nodetool repair -par -inc或類似的命令行開關），或使用一些第三方工具來修復很小的範圍內，如保持Cassandra Range Repair工具作者Brian Gallew或Spotify's Cassandra Reaper。

來源

2016-07-31 02:29:05

嗨克里斯和Jeff..Based禁用表上讀修理...我有我的問題回答。感謝你們。 –

什麼讓你覺得閱讀修理是什麼讓它減慢？檢查（jmx）org.apache.cassandra.metrics:type=ReadRepair,name=RepairedBackground和org.apache.cassandra.metrics:type=ReadRepair,name=RepairedBlocking以驗證是否發生修理。如果數據在讀取時不一致，讀取維修只會啓動，這應該不那麼常見。

如果真的有問題，你可以通過設置有機會在你輸入0

ALTER TABLE yourtable WITH read_repair_chance = 0;

來源

2016-07-31 03:48:32

嗨克里斯和傑夫，謝謝你看着它。我會盡快回復你們。非常感謝。 –

使用ALTER TABLE禁用讀取修復只能防止非阻塞的後臺讀取修復。前景閱讀修復只能通過使用較低的一致性級別來禁用。 –

這是真的，你需要CL.ONE和'read_repair_chance = 0'來防止阻塞和背景讀取修復。只有做一個人纔會讓其他人發生。我認爲它很可能不是報告花費很長時間的真正原因 –

在讀取之前計劃讀取修復

回答

相關問題