續前篇 裝好了MongoDB的Cluster後(1 Primary, 2 Secondaries)就開始進行大量的資料移轉
結果資料寫到一半, 突然發現Primary換人了, 雖然因為有Secondaries, 會有人上來替代, 因為Mongo只有Primary才可以被寫入, 這使得client必須重新建立對新的primary的connection, 一度以為機器被reboot了, 但查logs並沒這現象, 後來又以為, MongoDB也太不濟了吧, 這種量級的寫入居然可以擊倒它, 結果後來查了log發現, 他的確被restart了, 只是兇手不是他, 是別人叫他去死的
一切是Fleet惹的禍, 根據這篇Fleet engine stops units when etcd leadership change or has connectivity issues #1289, Fleet只要聯絡不到etcd, 就會認為不能獨活了, 就會把其他人也給殺了(可惡的殺人兇手),追根據底就是timeout設的太短了, 以至於當系統稍微(只是稍微而已)一忙, 就很容易超過timeout, 然後他就認為, 他的情人死了!(也太玻璃心了)
解決方案就是延長timeout, 修改cloud-config加上如下的東西(把etcd的heartbeat跟election timeout延長, 把fleet相關的也給延長):
#cloud-config
coreos:
etcd2:
heartbeat-interval: 600
election-timeout: 6000
fleet:
engine-reconcile-interval: 10
etcd-request-timeout: 5
agent-ttl: 120s
至於Azure上裝的coreos, cloud-config位置是在: /var/lib/waagent/CustomData, 改完restart機器就好