Hinted Handoff：在寫入路徑中修復
有時，數據寫入時節點變爲無響應狀態。無響應的原因是硬件問題、網絡問題、重載節點或長時間垃圾回收（GC）暫停。通過design，hinted handoff允許Cassandra繼續執行相同數量的寫入，即使羣集以降低的容量運行。
在故障檢測器將節點標記爲關閉之後，如果在cassandra.yaml文件中啓用了 提示的切換，則協調器會在一段時間內保存丟失的寫入。在Cassandra 3.0及更高版本中，提示存儲在本地提示中在每個節點上改進重播。該提示包括關閉的節點的目標ID，作爲數據的時間UUID的提示ID，標識Cassandra版本的消息ID以及作爲blob的數據本身。提示每隔10秒刷新一次，減少提示的陳舊程度。當八卦發現一個節點已經恢復在線狀態時，協調器重新播放每個剩下的提示，將數據寫入新返回的節點，然後刪除提示文件。如果某個節點停機的時間超過了max_hint_window_in_ms（默認爲3小時），則協調器停止寫入新的提示。
協調員還會每隔十分鐘檢查一次提示，說明在停機期間超時的寫入操作太短，以便故障檢測器通過八卦通知。如果副本節點過載或不可用，並且故障檢測器尚未將節點標記爲關閉，則在由write_request_timeout_in_ms（默認爲10秒）觸發的超時之後，期望對該節點的大部分或全部寫入失敗。協調器返回一個TimeOutException異常，寫入將失敗，但是一個提示將被存儲。如果多個節點同時出現短暫中斷，則可能會在協調器上建立大量的內存壓力。協調者跟蹤當前正在寫入的提示數量，如果數量增加太多，協調者拒絕寫入並拋出 OverloadedException 例外。
寫入請求的一致性級別影響是否寫入提示，並且寫入請求隨後失敗。如果羣集由兩個節點A和B組成，複製因子爲1，則每行僅存儲在一個節點上。假設節點A是協調者，但在寫入行K之前下降，其一致性級別爲1。在這種情況下，不能滿足指定的一致性級別，並且由於節點A是協調者，因此不能存儲提示。節點B不能寫數據，因爲它沒有收到作爲協調者的數據，也沒有存儲提示。協調器檢查已啓動的副本數量，如果無法滿足客戶機指定的一致性級別，將不會嘗試寫入提示。一個暗示的切換失敗發生，並將返回一個UnavailableException例外。寫請求失敗，提示不被寫入。
通常，建議在集羣中擁有足夠的節點，並且複製因子足以避免寫請求失敗。例如，考慮一個由三個節點A，B和C組成的集羣，複製因子爲2.當將行K寫入協調程序（在此情況下爲節點A）時，即使節點C處於關閉狀態，可以滿足ONE或QUORUM的一致性級別。爲什麼？節點A和節點B都將接收數據，所以滿足一致性級別要求。節點C存儲提示，節點C出現時寫入提示。同時，協調員可以確認寫入成功。
對於希望Cassandra在所有常規副本關閉時都能接受寫入並且不能滿足一致性級別ONE的應用程序，Cassandra提供了一致性級別ANY。任何保證在適當的副本目標變爲可用並且接收提示重播之後寫入是持久的和可讀的。
死亡的節點可能存儲了未傳遞的提示，因爲任何節點都可以成爲協調者。死亡節點上的數據也會在長時間停機後過時。如果一個節點長時間關閉，應該進行手動修復。
乍一看，似乎暗示的切換消除了手動修復的需要，但這不是真的，因爲硬件故障是不可避免的，並具有以下分支：
丟失必要的歷史數據，告訴羣集的其餘部分究竟是什麼數據丟失。
失敗的提示 - 尚未重播的失敗節點協調的請求。
通過停用節點或使用nodetool removenode命令從集羣中刪除節點時，Cassandra會自動刪除針對不再存在的節點的提示。卡桑德拉也刪除掉桌子的提示。
有關提示存儲的更多解釋，請參閱“3.0中的新增內容：改進的提示存儲和交付”或討論基本內容的舊博客，“ 現代提示”切換。