摘要：次版本號當做了向下兼容的功能性新增。因為此時集群的版本已經是更高的版本了，而加入舊版本的節點需要對舊版本進行兼容，為了防止已有的特性降級，直接拒絕不兼容的版本加入，目前默認主版本號和此版本號一樣則為兼容的版本。

在 TiDB 的產品迭代中，不免會碰到一些兼容性問題出現。通常協議上的兼容性 protobuf 已經能幫我們處理的很好，在進行功能開發，性能優化時，通常會保證版本是向后兼容的，但并不保證向前兼容性，因此，當集群中同時有新舊版本節點存在時，舊版本不能兼容新版本的特性，就有可能造成該節點崩潰，影響集群可用性，甚至丟失數據。目前在有不兼容的版本升級時，會要求進行離線升級，但這會影響到服務，我們需要一個適合的機制來進行不停服務的升級。因此我們需要在進行滾動升級時，讓這些不能保證整個集群的向后兼容性的功能不被啟用。只有在保證集群中所有節點都已經升級完成后，我們才安全的啟用這些功能。

常見的當我們對引入新的 RaftCommand 的時候，舊版本的 TiKV 并不能識別新的添加的 RaftCommand，對于不能認知的 RaftCommand TiKV 有不同的處理，可能會報錯退出或忽略。比如為了支持 Raft Learner, 在 raftpb 里對添加新的 ConfChange 類型。 當 PD 在進行 Region 調度時，會先發送 AddLearner 到 TiKV 上，接受到這個命令的肯定是這個 Region 的 Leader，在進行一系列檢查后，會將該命令 Proposal, 而 Follwer 如果是舊版本的話，在 Apply 這條 Command 就會出錯。而在滾動升級時，很有可能存在 Leader 是新版本，Follwer 是老版本的情況。

TiDB 的版本定義是遵循 Semver 的版本規則的。版本格式一般由主版本號（Major），次版本號（Minor），修訂號（Patch），版本號遞增規則如下：

主版本號：當進行了不兼容的 API 修改。

次版本號：當做了向下兼容的功能性新增。

修訂號：當做了向下兼容的問題修正。

先行版本號（PreRelase）及版本編譯信息可以加到“主版本號.次版本號.修訂號”的后面，作為延伸。比如 TiDB 目前的版本是 2.1.0-beta，先行版號為 beta 版。

在此之前，集群并沒有版本的概念，雖然每個組件都有各自的版本信息，但各個節點的各自組件的版本都可以任意的。沒有一個管理機制可以管理或查看所有組件的版本信息。為了解決滾動升級過程中存在多個版本的兼容性問題，這里引入集群版本的概念，并由 TiDB 集群的中心節點 PD 來進行管理和檢查。

在 PD 中，會設置一個 cluster_version 的鍵值對，對應當前運行集群中 TiKV 節點中最舊的版本。也就是必須要兼容這個版本， 因此不能打開集群中其他新版本的節點的一些不兼容的特性。

在集群啟動的時候，每個 TiKV 都需要向 PD 注冊，注冊時會帶上版本信息。當當前 TiKV 的版本低于集群版本的時候，該 TiKV 會注冊失敗。因為此時集群的版本已經是更高的版本了，而加入舊版本的節點需要對舊版本進行兼容，為了防止已有的特性降級，直接拒絕不兼容的版本加入，目前默認主版本號和此版本號一樣則為兼容的版本。

如果 TiKV 的版本高于或等于當前的 cluster_version 時， TiKV 能夠注冊成功并成功啟動。每次注冊都會觸發 PD 的一次檢查，會檢測當前集群中正常運行的 TiKV 的最低版本，并與當前的 cluster_version 進行比對，如果最低版本比 cluster_version 更加新，則將 cluster_version 更新。因此每次滾動升級的時候，能夠自動更新集群的版本。

TiKV 很多功能是需要 PD 的參與，目前這些新功能的開啟也是通過 PD 進行控制的。在 PD 中，會將每個版本新特性記錄下來，在 TiKV 2.0 中，對應有 Raft Leaner， Region Merge。 TiKV 2.1 中有 Batch Split，Joint Consensus 等。這些特性都需要 PD 的參與與控制。比如說 Add Leaner，Region Merge，Joint Consensus 需要 PD 下發調度給 TiKV，Batch Split 則是 TiKV 主動發起并請求 PD 分配新的 Region ID。因此這些功能都是能通過 PD 進行控制的。PD 會通過比對當前的集群版本，選擇開啟當前集群版本所支持的新特性。從而保證版本的兼容性。

當升級完成后，如果遇到問題需要進行集群進行回滾時， 需要手動修改集群版本后。PD 提供了 pdctl 可以通過命令手動修改集群的 cluster_version，這時舊版本的 TiKV 就能注冊并啟動，從而進行回滾。

PD 對 cluster_version 是通過 etcd 進行了持久化，在每次 PD 啟動的時候，leader 都會從 etcd kv 中加載出 clustrer_version，然后提供服務。從而保證在 PD leader 切換后 cluster_version 的一致性。另外 PD 本身的版本可能會小于當前 cluster_version。因此在滾動升級的時候，需要先升級 PD，如果只升級了 TiKV，雖然 cluster_version 已經更新到新的版本的，但 PD 并不能開啟新的功能，因為對它來說是不支持的。如果出現這種情況，PD 的日志中會有報警。在升級的時候，最好按 PD，TiKV，TiDB 的順序逐一對各個組件。

上面提到的新功能特性一般都是需要 PD 參與的。而有些特性不需要PD的參與，因此需要保證這種特性在 TiKV 之間是可以兼容的，實現的時候可以采用類是 http2 <-> http 的方式，對請求進行降級裝發，保留兩套接口等。另為 TiDB 目前是自身保證可以無縫兼容，但與 TiKV 可能存在兼容性問題，往后同樣考慮讓TiDB 也在 PD上進行注冊。

作者：陳書寧