solr的主從復制原理

這篇文章主要講解了“solr的主從復制原理”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“solr的主從復制原理”吧！

master的工作

對于ReplicationHandler的復制功能來說，核心的問題確定是在一個時間點要復制哪些文件，這就用上了lucene的IndexDeletionPolicy的特性。

lucene在初始化時，會調用IndexDeletionPolicy.onInit(List commits)方法；
lucene在commit（觸發的時機也可以是optimize、close，solr在commit時實際上就是close了indexwriter）時，會調用IndexDeletionPolicy.onInit(List commits)。


IndexCommit對象中保存了該次提交關聯的文件列表等信息，這使得solr中的復制過程中，slave可以從master得到文件列表后跟本地文件做比較，跳過不變的文件，下載新文件，并刪除無用的文件。

IndexDeletionPolicy的兩個針對commits的函數，會對當前存在的commits列表做些處理，比如lucene默認的KeepOnlyLastCommitDeletionPolicy會只保留最新的IndexCommit，對那些過時的IndexCommit執行delete操作以將無用的文件刪掉。

solr中，SolrDeletionPolicy默認也是保留最新一個IndexCommit，但可以設置maxCommitAge、maxCommitsToKeep、maxOptimizedCommitsToKeep來保留更多的IndexCommit。但solr真正使用的IndexDeletionPolicy實現是IndexDeletionPolicyWrapper，它是SolrDeletionPolicy的wrap。

在slave從master復制文件的過程中，要保證當前正在復制的IndexCommit點不能被刪除，這就用到了IndexDeletionPolicyWrapper中的void setReserveDuration(Long indexVersion, long reserveTime)方法，該方法會在master向slave響應indexversion、filelist命令前、以及每向slave傳送5M的索引文件內容時調用，而默認的reserveTime時間是10s，如果慢速網絡傳輸5M數據需要10秒以上，就需要調整該值了。

ReplicationHandler復制文件沒有采用rsync，而是使用http，它在讀一個文件內容傳輸到slave時，默認是按照1M大小分段輸出內容到slave（http chunked？），并且默認是對每段內容做了checksum，保證傳輸的內容的正確性。上面提到的setReserveDuration點，主要就是它在packetsWritten % 5 == 0次數后觸發一次修改。

ReplicationHandler還可以備份索引文件。由于lucene的索引文件只是追加新文件而不會修改已有文件，所以只要針對一個IndexCommit點做備份，其過程還是很簡單的。

slave的工作

slave啟動時會創建SnapPuller對象，SnapPuller會啟動一個線程定時的（pollInterval間隔）從master復制數據（fetchLatestIndex方法）。對于一次復制過程，slave和master交互處理細節如下：

1、slave首先向master詢問最新的索引版本號（indexversion命令），slave檢查得到的latestVersion、latestGeneration有效后，和本地的IndexCommit的getVersion()、getGeneration()比較，如果不相等，則需要往下進行，否則等待下一次調度。

2、slave向master請求之前得到的indexversion下的文件列表（filelist命令，包括索引文件和可選的配置文件）。如果文件列表為空，則返回等待下一次調度。否則，就需要檢查哪些文件需要被下載過來。這里做的判斷有：1）如果本地的commit.getGeneration() >= latestGeneration，說明本地索引文件被破壞（比如對slave不小心提交了修改索引的命令），需要完全將master的文件復制過來。2）逐個檢查文件列表中的文件是否在本地存在，不存在就下載下來。

3、對于下載文件內容，對應命令是filecontent。下載的文件顯然需要放到臨時目錄中，這個臨時目錄和已有的索引目錄（默認名字index）在同一數據目錄下，只是命名為index.<時間戳>。下載完畢后，copy數據有兩種情況：
1）如果是完全下載，則不需要將臨時目錄中的文件copy到已有目錄中，而是修改數據目錄中的index.properties，標識索引目錄為新生成的臨時目錄，而舊索引目錄并不會被刪除，可以手工刪掉，當然，通常是不應該出現slave的Generation大于master的異常情況。
2）通常就是把臨時索引目錄的文件copy到舊索引目錄，copy時要把segments_N放到最后copy，避免copy中途出現異常造成數據被毀。

4、當新索引和可選的配置文件copy完畢之后，slave會對solrcore的UpdateHandler做commit操作，這會close掉indexwriter并強制重啟新的indexsearcher提供服務。同時，如果solrcore的UpdateHandler是DirectUpdateHandler2（不應該不是），會強制調用handler.forceOpenWriter()來刪除舊的無用的索引文件，并調用replicationHandler.refreshCommitpoint()來更新slave的indexCommitPoint。

5、如果索引復制失敗，slave會向數據目錄下的replication.properties輸出復制失敗的信息。

感謝各位的閱讀，以上就是“solr的主從復制原理”的內容了，經過本文的學習后，相信大家對solr的主從復制原理這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！