SolrCloud Wiki翻譯(5)讀寫容錯性

Read Side Fault Tolerance

「讀」容錯

With earlier versions of Solr, you had to set up your own load balancer. Now each individual node load balances requests across the replicas in a cluster. You still need a load balancer on the 'outside' that talks to the cluster, or you need a smart client. (Solr provides a smart Java Solrj client called CloudSolrServer.)

在舊版本的Solr中，你必須本身實現一個負載均衡器，然而如今在集羣中的每一個節點均可以把請求自動的負載均衡到全部的replica節點上去。可是對於整個集羣來講，你仍然須要一個外部的負載均衡器，或者是一個智能客戶端（Solr已經在Java的客戶端Solrj中提供了一個CloudSolrServer的智能客戶端）

A smart client understands how to read and interact with ZooKeeper and only requests the ZooKeeper ensembles' address to start discovering to which nodes it should send requests.

智能的客戶端知道怎麼去讀取ZooKeeper裏面的信息並和ZooKeeper交互，並且只經過請求ZooKeeper集羣來判斷應該向哪一個節點發送請求。

Write Side Fault Tolerance

「寫」容錯

SolrCloud supports near real-time actions, elasticity, high availability, and fault tolerance. What this means, basically, is that when you have a large cluster, you can always make requests to the cluster, and if a request is acknowledged you are sure it will be durable; i.e., you won't lose data. Updates can be seen right after they are made and the cluster can be expanded or contracted.

SolrCloud支持一些近實時操做、彈性伸縮、高可用和可容錯的特性。這意味着，基本上只要你有一個大型集羣，你就能夠一直把請求發送到這個集羣中去，而且只要這個請求是節點公認的，就能夠肯定這個請求操做能夠一直使用；好比，你不會在集羣中丟失任何數據。全部的更新操做只要在完成以後而且集羣能夠正常的伸縮的話，結果均可以正確可見。

Recovery

數據恢復

A Transaction Log is created for each node so that every change to content or organization is noted.  The log is used to determine which content in the node should be included in a replica. When a new replica is created, it refers to the Leader and the Transaction Log to know which content to include. If it fails, it retries.

每個節點都會建立一個Transaction Log來記錄全部索引內容或結構的變動。這個Log被用來肯定在各個replica節點中應該包含哪些索引內容。當一個新的replica節點建立以後，它會查閱Leader節點和它的Transaction Log來了解本身應該包含哪些索引內容。若是這個過程失敗了的話，它會自動重試。

Since the Transaction Log consists of a record of updates, it allows for more robust indexing because it includes redoing the uncommitted updates if indexing is interrupted.

Transaction Log由一個保存了一系列的更新操做的記錄構成，它能增長索引操做的健壯性，由於只要某個節點在索引操做過程當中意外中斷了，它能夠重作全部未提交的更新操做。

If a leader goes down, it may have sent requests to some replicas and not others. So when a new potential leader is identified, it runs a synch process against the other replicas.  If this is successful, everything should be consistent, the leader registers as active, and normal actions proceed. If the a replica is too far out of synch, the system asks for a full replication/replay-based recovery.

假如一個leader節點宕機了，可能它已經把請求發送到了一些replica節點可是卻沒有發送到另外一些卻沒有發送，因此在一個新的leader節點在被選舉出來以前，它會依靠其餘replica節點來運行一個同步處理操做。若是這個操做成功了的話，全部節點的數據就都保持一致了，而後leader節點把本身註冊爲活動節點，普通的操做就會被處理。若是一個replica節點的數據脫離總體同步太多了的話，系統會請求執行一個全量的基於普通的replication同步恢復。

an update fails because cores are reloading schemas and some have finished but others have not, the leader tells the nodes that the update failed and starts the recovery procedure. 

一個更新操做可能在core在加載schema的時候失敗，由於一些節點可能已經加載完成了，另外一些節點卻沒有，leader節點會告訴那些更新數據失敗的節點啓動一個回覆處理。