master的工作
對(duì)于ReplicationHandler的復(fù)制功能來(lái)說(shuō)，核心的問題確定是在一個(gè)時(shí)間點(diǎn)要復(fù)制哪些文件，這就用上了lucene的IndexDeletionPolicy的特性。
lucene在初始化時(shí)，會(huì)調(diào)用IndexDeletionPolicy.onInit(List commits)方法；
lucene在commit（觸發(fā)的時(shí)機(jī)也可以是optimize、close，solr在commit時(shí)實(shí)際上就是close了indexwriter）時(shí)，會(huì)調(diào)用IndexDeletionPolicy.onInit(List commits)。
IndexCommit對(duì)象中保存了該次提交關(guān)聯(lián)的文件列表等信息，這使得solr中的復(fù)制過程中，slave可以從master得到文件列表后跟本地文件做比較，跳過不變的文件，下載新文件，并刪除無(wú)用的文件。
IndexDeletionPolicy的兩個(gè)針對(duì)commits的函數(shù)，會(huì)對(duì)當(dāng)前存在的commits列表做些處理，比如lucene默認(rèn)的KeepOnlyLastCommitDeletionPolicy會(huì)只保留最新的IndexCommit，對(duì)那些過時(shí)的IndexCommit執(zhí)行delete操作以將無(wú)用的文件刪掉。
solr中，SolrDeletionPolicy默認(rèn)也是保留最新一個(gè)IndexCommit，但可以設(shè)置maxCommitAge、maxCommitsToKeep、maxOptimizedCommitsToKeep來(lái)保留更多的IndexCommit。但solr真正使用的IndexDeletionPolicy實(shí)現(xiàn)是IndexDeletionPolicyWrapper，它是SolrDeletionPolicy的wrap。
在slave從master復(fù)制文件的過程中，要保證當(dāng)前正在復(fù)制的IndexCommit點(diǎn)不能被刪除，這就用到了IndexDeletionPolicyWrapper中的void setReserveDuration(Long indexVersion, long reserveTime)方法，該方法會(huì)在master向slave響應(yīng)indexversion、filelist命令前、以及每向slave傳送5M的索引文件內(nèi)容時(shí)調(diào)用，而默認(rèn)的reserveTime時(shí)間是10s，如果慢速網(wǎng)絡(luò)傳輸5M數(shù)據(jù)需要10秒以上，就需要調(diào)整該值了。
ReplicationHandler復(fù)制文件沒有采用rsync，而是使用http，它在讀一個(gè)文件內(nèi)容傳輸?shù)絪lave時(shí)，默認(rèn)是按照1M大小分段輸出內(nèi)容到slave（http chunked？），并且默認(rèn)是對(duì)每段內(nèi)容做了checksum，保證傳輸?shù)膬?nèi)容的正確性。上面提到的setReserveDuration點(diǎn)，主要就是它在packetsWritten % 5 == 0次數(shù)后觸發(fā)一次修改。
ReplicationHandler還可以備份索引文件。由于lucene的索引文件只是追加新文件而不會(huì)修改已有文件，所以只要針對(duì)一個(gè)IndexCommit點(diǎn)做備份，其過程還是很簡(jiǎn)單的。
slave的工作
slave啟動(dòng)時(shí)會(huì)創(chuàng)建SnapPuller對(duì)象，SnapPuller會(huì)啟動(dòng)一個(gè)線程定時(shí)的（pollInterval間隔）從master復(fù)制數(shù)據(jù)（fetchLatestIndex方法）。對(duì)于一次復(fù)制過程，slave和master交互處理細(xì)節(jié)如下：
1、slave首先向master詢問最新的索引版本號(hào)（indexversion命令），slave檢查得到的latestVersion、latestGeneration有效后，和本地的IndexCommit的getVersion()、getGeneration()比較，如果不相等，則需要往下進(jìn)行，否則等待下一次調(diào)度。
2、slave向master請(qǐng)求之前得到的indexversion下的文件列表（filelist命令，包括索引文件和可選的配置文件）。如果文件列表為空，則返回等待下一次調(diào)度。否則，就需要檢查哪些文件需要被下載過來(lái)。這里做的判斷有：1）如果本地的commit.getGeneration() >= latestGeneration，說(shuō)明本地索引文件被破壞（比如對(duì)slave不小心提交了修改索引的命令），需要完全將master的文件復(fù)制過來(lái)。2）逐個(gè)檢查文件列表中的文件是否在本地存在，不存在就下載下來(lái)。
3、對(duì)于下載文件內(nèi)容，對(duì)應(yīng)命令是filecontent。下載的文件顯然需要放到臨時(shí)目錄中，這個(gè)臨時(shí)目錄和已有的索引目錄（默認(rèn)名字index）在同一數(shù)據(jù)目錄下，只是命名為index.<時(shí)間戳>。下載完畢后，copy數(shù)據(jù)有兩種情況：
1）如果是完全下載，則不需要將臨時(shí)目錄中的文件copy到已有目錄中，而是修改數(shù)據(jù)目錄中的index.properties，標(biāo)識(shí)索引目錄為新生成的臨時(shí)目錄，而舊索引目錄并不會(huì)被刪除，可以手工刪掉，當(dāng)然，通常是不應(yīng)該出現(xiàn)slave的Generation大于master的異常情況。
2）通常就是把臨時(shí)索引目錄的文件copy到舊索引目錄，copy時(shí)要把segments_N放到最后copy，避免copy中途出現(xiàn)異常造成數(shù)據(jù)被毀。
4、當(dāng)新索引和可選的配置文件copy完畢之后，slave會(huì)對(duì)solrcore的UpdateHandler做commit操作，這會(huì)close掉indexwriter并強(qiáng)制重啟新的indexsearcher提供服務(wù)。同時(shí)，如果solrcore的UpdateHandler是DirectUpdateHandler2（不應(yīng)該不是），會(huì)強(qiáng)制調(diào)用handler.forceOpenWriter()來(lái)刪除舊的無(wú)用的索引文件，并調(diào)用replicationHandler.refreshCommitpoint()來(lái)更新slave的indexCommitPoint。
5、如果索引復(fù)制失敗，slave會(huì)向數(shù)據(jù)目錄下的replication.properties輸出復(fù)制失敗的信息。
聯(lián)系客服
