動機
同樣是補6.824上沒有的部分
- 換成員
- raft博論的練習題 (有練習題你敢信，同時還有paxos的練習題!!)
換成員 (joint consensus)
不能直接用replicate state machine的方式換成員，因為copy log與commit log的時間不一致 這樣可能會選出兩個leader
在paper上，是引入一個過渡階段，讓所有新的與舊的成員都受到要換的通知(裡面就是當期與下一期的conf)
之後等commit過渡階段後(新的與舊的成員的大多數都收到了)，之後發新的conf 拿到什麼conf，就對同屬該conf的做回應(投票、appendEntries)
因此過渡階段的機器有以下特性
- 可以對兩邊的conf的機器做回應
- 兩邊的conf的機器都可以認成leader
- 如果要達成共識，必須要有兩邊的conf的多數同意
另外有3個有趣的情景
- 預熱: 新成員如果直接參加換成員要一段時間才能有新的log
- 讓新成員成為無法投票的腳色，接受appendEntries
- 可能有不包含自己的leader
- 在轉移階段可能leader不在新conf中
- 被移除的server可能發requestVote讓其他人亂掉
- 設定可以再投票的最低時間，這樣被移除的就算發投票也會被擋掉
有bug的一次換一個
在作者最初的thesis上有一個一次換一個的algo
一次換一個，每次都丟一個log，拿到該log馬上認新的 聽起來很合理，反正都有一個server在新舊conf中間，but!!
別忘了當初raft的quotum是過半數，所以像上面的圖，如果加到一台到dc-1，之後斷線，再變成新的conf之前dc-1與dc-2,3都會因為選不出leader而出事
而作者給出patch就是no-op，要等no-op到了才可以用新conf (其實這樣就與joint consensus很像，只不過這裡拆成提conf之後no-op，joint consensus是發換conf，之後apply新conf)
在這裡原po用quotum的觀點去看整個algo
一次換一個在上面的圖整個quotum的變化是 $Major(a,b,c) => Major(a,b,c,d) => Major(b,c,d)$
如果只用過半數，這樣從abc到abcd可能有人沒有被包含到!! 這樣就沒有quotum的正確性了
解法就是改寫quotum的定義，只要每次都包含bc(尤其是中間階段)就可以保證正確性了
這個時候回過頭來看joint consensus 會發現
joint consensus打從一開始就保證了正確性阿
練習題
raft
下面的log有沒有可能出現在raft中?
不可能，log term只會越來越大
可能
可能
不可能，raft的safety保證log不會有空洞 (append-only)
下面有哪些log可以安全commit?
第一個因為每個都有，所以可以安全commit 第二個也是多數都有，所以可以安全commit
第三個就比較神奇了，因為有不同term的!! 就算term2的是多數，也要考慮，會不會被trim，所以看第一個follower會不會成為leader
答案是會，所以可能會被trim，所以不能安全commit
下面是選完leader的畫面，下面follower，有那些log是對的
第一個與第二個不對，只要index與term一樣，前面的所有log都要一樣!! 其他都對
nextIndex被破壞了會影響raft的正確性嗎?
不會 太大，在appendEntries會變小 太小，之後會有別的appendEntries
如果說有超多台機器要一起raft，raft要做什麼調整?
把election timeout拉長
因為 第一，傳播時間變久 第二，需要更久時間完成投票，不然可能livelock
如果忘了voteFor會?
可能在同一個term投給不同的人!!
如果忘了一部分log?
忘了commit過的log，可能會commit不同的log!!
從舊leader到新leader之間的轉換時，如果舊leader沒有收到其他rpc就會以為自己還是leader繼續commit嗎? 如果是會有問題嗎?
可能，像是複製到多數時(這時還沒收到reply)，在這多數之中產生新leader，之後舊leader收到reply做commit
這沒問題，因為log已經copy到多數了，別忘了leader的選出條件是log夠新(當初就是栽在這裡)
如果換成員時當前leader不在新conf中，此時讓leader直接退位，會發生什麼事? 如果舊leader還能選，之後這位就會一直被選上之後退位，一直重複。 如果舊leader不能選，就是舊conf中的多數人都會經歷被選上之後退位
paxos
下面的basic paxos的log有不對的嗎?
沒有
在basic paxos中有5台的3台吃proposal 5.1 with value X 那其他server可能吃不同的value嗎?
能，只要沒有accept過其他value即可(本來就是空的)
在Multi-Paxos中，leader的prepare RPC的 lowerbound與upperbound是?
lowerbound: 1，直接拿到多數的noMoreAccepted=true upperbound: 有幾個空的log就有幾個prepare RPC
acceptor用firstUnchosenIndex(last_rnd)確認能accept這個value，如果沒有確認會怎樣? 類似，voteFor沒有記憶的問題 會倒退 value A打到一半停下來，之後下一個value B打完，之後value A回來，繼續打，就倒退了
proposal number (round number and unique server id)交換會發生什麼事?
正確性(安全性): 沒事，因為round number會保護好accpet 活性: 會飢餓，server id大的可以一直發prepare
在basic paxos，如果打到中間crash, recover後換了當初打得value會發生什麼事?
先發了一台ok，之後發剩下的，但是request被delay，同時crash restart後用新value打，把剩下的打完，但delay的request到了(為什麼accept可以改要看下面哪一題)，之後就被改了!! (感覺超像voteFor)
另一個版本的意外是 先發了一台ok，之後發剩下的到一半crash，之後起來重發新value的 之後下一位進來，做prepare拿到新value與舊value(多數讀，所以可以隨便選value)，之後用舊value發…
Accept RPC成功後會根據accpet的值，直接改minProposal，如果沒有這樣做會出什麼事? consensus-bugs
在換成員時，1 2 3是舊的，3 4 5是新的，如果1 2拿到新conf後直接下線會出什麼事? 最慘就是4 5都是空的，因為現在4 5是多數，但是前面的歷史都在3手上