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主從復制的原理