1、關於rcc引數
如果執行ttserver的時候，帶上了rcc引數。那麼在資料同步過程中，如果有一條資料執行錯誤，那麼同步就會停下來，直到有人工干預。反之，如果沒有rcc引數，同步會繼續進行，但是在日誌中，會報乙個error級別的錯誤。
建議，不帶rcc引數執行ttserver，同時監控ttserver的日誌，對error級別的日誌監控報警。
2、重連rconn引數
介面函式tcrdbtune，可以傳遞rdbtrecon開關，使ttserver有斷開重連的機制。但這並不可靠，ttserver的通訊機制設計是有缺陷的，即沒有message-id的考慮。在網路環境差的情況下，可能，你的第n次請求，得到的應答卻是第n-1次請求的應答。所以安全起見，如果你的程式一旦檢查到ttserver有網路異常情況（也同時要求程式必須檢查），立刻關閉並釋放掉ttserver控制代碼，要使用全新例項化的控制代碼進行接下來的操作。
3、ttserver的日誌文集不能超過2g
其實這不只是ttserver的問題，不作特殊處理，在32bit系統，檔案大小不能超過2g，但是這個問題容易被忽略。開始上線使用ttserver的時候，輸出了debug級別的日誌，導致日誌檔案膨脹迅速，很快就到了2g，導致了一次事故。採用的策略是：1、在一般情況下，可以不輸出debug級別的日誌；2、定時備份日誌（cp命令），清空日誌內容（echo "" > ttserver.log）；一般日誌切分使用移動(mv)，和重啟服務，在ttserver日誌切分上盡量不採用這樣的策略。
4、ttserver互為備份的兩台資料不一致的時候
由於某些特殊原因，比如上面的3中情況，在處理不當的時候，會導致互為備份的兩台伺服器資料不一致，這個時候應該怎麼處理，同時還不打斷系統的正常執行。採用的方法是，修改系統配置，使得系統讀寫資料庫時，只讀寫其中的那台正常的伺服器，把異常的伺服器從系統中剝離開來，然後採用ttserver的備份/恢復策略，使得兩台伺服器的資料一致。
我開始不是這樣操作的，總是異常的伺服器在重啟後（基於從正常伺服器的資料備份以及備份時的時間戳/版本號），就開始提供服務。這樣實際上異常的伺服器在提供正常服務（有讀寫操作）的同時，還要從正常伺服器同步從備份資料到重啟異常伺服器這段時間產生的新資料。操作幾次總不能成功，兩邊的資料總是有差異，沒有深入思考為什麼會這樣，就擱置了，一直到現在，應該抽時間想一想為什麼了
Tokyo Tyrant基本規範
tokyotyrant基本規範，翻譯自tokyo 主要內容為tokyotokyotyrant是名為tokyotyrant提供併發和遠端連線到tokyo 因為執行緒池模型實現和現代linux bsd核心的epoll kqueue機制，該伺服器提供高併發支援。伺服器端和它的客戶端通過基於tcp ip的簡...
Tokyo Tyrant備份和恢復
tokyo tyrant備份和恢復 備份 1.全量熱備份 備份命令為 tcrmgr copy port 1978 localhost dpath.tch.xx 其中 xx為備份時間 根據業務需求及資料庫執行狀態決定備份的頻度，全量熱備時資料庫庫會寫鎖定，讀不受影響。全量備份需記錄備份時間點以提供re...
Tokyo Tyrant備份和恢復
備份 1.全量熱備份 備份命令為 1 tcrmgr copy port 1978 localhost dpath.tch.xx 其中 xx為備份時間 根據業務需求及資料庫執行狀態決定備份的頻度，全量熱備時資料庫庫會寫鎖定，讀不受影響。全量備份需記錄備份時間點以提供replication恢復時所用，時...