不少網友都在問我關於Cassandra Repair的問題，諸如參數配置，如何進行repair。
repair介紹
Cassandra repair 作用就是修復數據的不一致性問題，在分佈式環境中，數據爲了保障高可用，通常遵循的是最終一致性。所以各個節點的數據有可能出現不一致的問題。repair就是爲了解決這個問題
repair機制
Cassandra repair有三種
1. read repair 讀修復，針對的維度是column family
發生在讀請求時觸發的一個後臺任務，由read_repair_chance參數控制，默認值是0.1，即10個讀請求觸發1次修復動作。另外一個參數dclocal_read_repair_chance，這是限定只修復本數據中心，防止跨數據中心數據同步耗時長。
另外如果是DTCS 壓縮策略，需要將讀修復關閉，因爲DTCS要求插入的數據嚴格按照時間有序。
2. hinted handoff
這個發生在節點down掉後，原本應該寫入到該節點的數據會先寫到coordinate node，在一定時間窗口內，節點重新up後，有該節點當時寫入的數據的coordinate node會將這些數據再寫到這個節點上。
3. 手動repair
即使用nodetool工具來進行repair,因爲從1,2中的描述我們可以知道是不能完全保證數據的一致性的。
https://docs.datastax.com/en/cassandra/latest/cassandra/tools/toolsRepair.html
那麼在生產環境中nodetool repair job如何去執行呢，總不能發現數據不一致了，手動跑一遍吧。
repair 主要分兩種，一種全量(full),一種增量(incr)意思很好理解，全量就是掃描merkle tree上的所有節點，增量就是添加了一個標記，已修復的就不再修復了。
兩種方式切換時需要額外操作。
從full-incr 需要禁止compaction,跑一遍full repair,然後重啓節點，
從incr-full需要清除repair標記，
在4.x之前，
由於repair然後標記時，沒有應答機制，常常會有些節點標記失敗https://issues.apache.org/jira/browse/CASSANDRA-9143
所以官方是推薦full repair.
定期(一週)跑一次
對於刪除頻繁的table，週期需要更短。
刪除數據時，會發送一個tombstone標記，標記數據被刪除，然後在compaciton階段將數據刪除。
如果在發送delete request到節點時，某個擁有該數據的節點down了，Cassandra會一直重新發送。
只要節點在gc_grace_seconds時間內恢復過來，他就會收到delete request。如果節點超過了這個時間。tombstone 就會被gc回收，節點就會丟失刪除數據的delete request，這樣這條被刪除的數據會被恢復出來。
本文分享自微信公衆號 - 方丈的寺院（gh_c98f244e174d）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。