Joint Consensus
多邊（聯合）共識
The solution is to use two phases to change the configuration. Raft switches first to an intermediate phase called joint consensus. During this phase, the cluster consists of all of the servers in both the new and the old configuration(so the union of those configurations). But decisions such as elections and commitment require a separate majority separate agreement from both the old configuration and the new configuration.
解決方案是使用兩個階段來更改配置。Raft首先切換到稱爲多邊共識的中間階段。在此階段，羣集由新配置和舊配置中的所有服務器組成。但是如選舉和提交的決策，需要在新舊兩個配置狀態下分別達成一致。
Let me show you how this works. So we start off in an existing configuration, i will call Cold on the slide. And the way a configuration change is initiated that a client makes a request of the leader just like it would for any other state machine operation. When the server receives that request then the leader adds an entry to its log describing this joint configuration, which i will call Cold+new, that’s just a log entry like any other log entry. The server puts it in its log and then the leader propagates it out to the other servers in the cluster using AppendEntries RPC just like any other log entry. The only thing different about the configuration changes is that they take effect immediately, so soon as server places a new configuration into its log. It begins living by that configuration entry. It doesn’t wait for the configuration entry but for the log entry to become committed before applying it like it would for normal log entries. So back to our timeline here, leader places the new configuration entry in its log and then as far as that leader is concerned that’s the configuration in effect, so that leader makes all of its decisions according the old plus new configuration that means that for example for any log entry to be committed it must be logged majority of the machines in the old cluster and a majority of machines in the new configuration. Now, for a while until that entry becomes replicated or reached a point of being committed, it’s possible that decisions might be made either with Cold or Cold+new.1 For example if the leader crashes shortly after logging the new configuration entry, it’s possible that some other machine is still operating under the old, could be elected and take over the cluster but at some point this new configuration entry will become committed Cold+new. Once that happens now it’s not possible for any machine to make a decision based purely on Cold.
我來告訴你這是怎麼工作的。所以我們從現有的配置開始，我稱之爲幻燈片上的Cold。配置更改的方式是客戶端向領導者發出請求，就像其他狀態機操作一樣。當服務器收到該請求時，領導者在其日誌中添加一個條目來描述這個聯合配置，我將稱之爲Cold+new，就像任何其他日誌條目一樣只是一個日誌條目。服務器將其放入其日誌中，然後領導者使用AppendEntries RPC將其傳播到集羣中的其他服務器，就像其他日誌條目一樣。配置更改的唯一不同之處在於，只要服務器將新配置放入其日誌中，它們就會立即生效。一旦服務器將新配置記錄到日誌中，那麼它就立刻生效，它不會等待配置條目在應用之前提交（就像普通日誌條目一樣）。所以回到時間軸2，領導者將新的配置條目放到其日誌中，然後就這個領導者而言，Cold+new就是實際上的配置，以便領導者根據舊的加上新的配置做出所有決定，這意味着對於要提交的任何日誌條目，要求該條目分別在新舊配置服務器下同時都成爲大多數。現在，在該條目被複制或到達提交點之前，可能會使用Cold或Cold+new作出決定。例如，如果領導者在記錄新配置記錄後就發生崩潰，有可能某些其他舊配置的機器仍然處於工作狀態，被選舉成領導者管理集羣。但在某個時間點，Cold+new會變爲已提交的狀態3，在此種狀態下，任何機器就無法只根據Cold來做出決策。
