Cassandra repair 流程
文章分3塊：1.為什麼需要repair？；2.repair大概流程？；3.repair可能的問題。
為什麼需要repair
cassandra 如何修複副本資料
我們知道Cassandra是一個強調最終一緻性的系統，副本間的資料并不能保證強一緻(但是從用戶端角度，通過QUORUM等級别讀寫還是可以保證用戶端視角的強一緻[1])。因為副本間資料是最終一緻，是以Cassandra通過hinted-handoff、read-repair、repair 進行副本間資料補齊；這三個方式各有優缺點：
- hinted-handoff 用來補齊節點挂掉期間的資料，但是挂掉時間太久這個特性會失效且hint機制存在資料可靠性風險；
- read-repair：隻有被讀到的不一緻資料才會被修複，那麼如果沒有被讀到的資料很多怎麼辦？
- repair：全量的修複方案，保證做多個副本在某個時間點（觸發repair時刻）前的資料全量修複一緻。
從上述描述看出，repair是一個兜底修複副本資料的方案，那麼既然上面說了，通過quorum可以保證用戶端視角的強一緻，我們還需要通過repair來修複全量副本資料麼？答案是：必須要，而且官方也建議在一定周期（gc_grace_seconds）内必須要做一次[2]，才能保證系統的正确性。
如果不做repair會怎麼樣？
假設3個副本(A/B/C)，quorum級别的讀寫删資料，時刻t1使用者最初以quorum級别成功寫入資料1，假設A/B/C都寫入成功；時刻t2使用者quorum級别删除1資料，假設這裡C副本删除失敗，但是客戶依舊顯示删除成功；時刻t3（這裡假設t3-t2 > gc_grace_seconds，且使用者沒有做repair 且期間）。那麼A/B副本會compaction把1資料合并删除掉，但是c副本沒有删除mark。
最終結果一條被使用者認為删除成功的key ，”死灰複燃“的讀到了。
是以：repair必須要做。
repair大概流程
全量資料repair需要人為手工通過節點nodetool送出外圍任務，具體的nodetool 指令行參數 可以下次介紹，這裡大概分享下一輪repair在副本節點之間進行的流程。假設開始做A 節點負責的資料，對應副本涉及B/C節點，那麼一次執行的修複鍊路是：
- 計算A/B/C三個相關副本資料的全量merkle-tree[3]，這是一個二分hash樹；從底往上計算hash、葉子節點是小range範圍的資料的sha2 hash值，内部節點是其左右子節點的hash值（xor）；
- 通過兩兩對比merkle-tree，可以知道具體節點間不一緻的資料範圍；
- 兩兩走内部stream 拖資料流程補齊相關資料。
repair可能的問題
- 運維複雜：
- 節點資料量如果較大，整個執行過程可能會耗時很久，時間越久出現問題的可能性就越大；
- 為了避免repair對叢集影響較大，repair需要針對節點差異化執行，那麼對運維複雜性會帶來挑戰；
- 需要表級别gc_grace_seconds 内做一次，如果表過多，會造成運維差異化難度較大；
- 資源消耗較大：
- 一般cassandra被用于線上服務場景，但是做repair會帶來瞬時資源較大開銷：cpu、io、網絡，影響服務穩定性；
現在社群解決方案有：incremental repair、schedule repair等方案[4],此外datastax公司也有nodesync[5],scylladb 公司有row-level repair。對應我們也有相關的定制功能。目的是降低運維複雜度，降低repair時候對線上服務的影響。
入群邀約
為了營造一個開放的 Cassandra 技術交流環境，社群建立了微信群公衆号和釘釘群，為廣大使用者提供專業的技術分享及問答，定期開展專家技術直播，歡迎大家加入。
另外阿裡雲提供商業化Cassandra使用，中國站和國際站都支援：
https://www.aliyun.com/product/cds 引用：
[1]
https://www.allthingsdistributed.com/2008/12/eventually_consistent.html[2]
https://cassandra.apache.org/doc/latest/operating/repair.html[3]
https://en.wikipedia.org/wiki/Merkle_tree[4]
https://issues.apache.org/jira/browse/CASSANDRA-14346[5]
https://docs.datastax.com/en/dse/6.0/dse-dev/datastax_enterprise/config/aboutNodesync.html[6]
https://docs.scylladb.com/operating-scylla/procedures/maintenance/repair/