參賽日記day3-tidb性能競賽-tikv/pd#2950git
在線版：https://www.processon.com/view/link/5f8d9cb9e401fd06fd941265github
changelog
- 2020/10/18 day7 繼續補day3的參賽日記，把幾個相關issue翻譯成中文理解，有了DeepL減輕很大的翻譯恐懼，DeepL翻譯的像人話
- 2020/10/17 day6 繼續補day3的參賽日記，準備翻譯issue的，拖延了
- 2020/10/16 day5 補day3的參賽日記
- 2020/10/15 day4 沒看
- 2020/10/14 day3 gaosong老師講zoom講了issue來源和思路
gaosong老師提議晚上zoom講下這個issue需求的來源和思路，因此須要白天看完三篇文章。 因此中午看下第三篇，按道理應該昨天看完的，畢竟文章不長。網絡
建立分支
先建立倉庫分支，不能搞了半天代碼都沒準備好。按照 community/high-performance-tidb-challenge-cn.md at master · pingcap/community ，須要以特定hash版本爲開發起點，因此用「github 克隆指定hash」關鍵詞搜到Git clone particular version of remote repository - Stack Overflow，因此下面是操做步驟：負載均衡
# fork https://github.com/tikv/pd.git git clone https://github.com/eatcosmos/pd.git cd ~/git/pd git reset --hard c05ef6f95773941db5c1060174f5a62e8f864e88 git checkout -b dev git push --set-upstream origin dev git push # git clone --single-branch --branch dev https://github.com/eatcosmos/pd.git # git checkout dev
閱讀文章
三篇文章瞭解 TiDB 技術內幕 - 談調度 | PingCAP運維
請思考下面這些問題：性能
- 如何保證同一個 Region 的多個 Replica 分佈在不一樣的節點上？ 這個應該簡單吧，標記不一樣就行了吧。
- 更進一步，若是在一臺機器上啓動多個 TiKV 實例，會有什麼問題？ 操做會衝突。
- TiKV 集羣進行跨機房部署用於容災的時候，如何保證一個機房掉線，不會丟失 Raft Group 的多個 Replica？ 什麼意思？
- 添加一個節點進入 TiKV 集羣以後，如何將集羣中其餘節點上的數據搬過來? 直接拷貝吧，爲何要搬，搬哪些？
- 當一個節點掉線時，會出現什麼問題？整個集羣須要作什麼事情？若是節點只是短暫掉線（重啓服務），那麼如何處理？若是節點是長時間掉線（磁盤故障，數據所有丟失），須要如何處理？ 若是是leader replica掉線須要從新分配leader。萬一replica group都掉線呢？
- 假設集羣須要每一個 Raft Group 有 N 個副本，那麼對於單個 Raft Group 來講，Replica 數量可能會不夠多（例如節點掉線，失去副本），也可能會過於多（例如掉線的節點又回覆正常，自動加入集羣）。那麼如何調節 Replica 個數？ 設置個固定值吧。
- 讀/寫都是經過 Leader 進行，若是 Leader 只集中在少許節點上，會對集羣有什麼影響？ 會頻繁切換leader。
- 並非全部的 Region 都被頻繁的訪問，可能訪問熱點只在少數幾個 Region，這個時候咱們須要作什麼？ 須要配置索引。
- 集羣在作負載均衡的時候，每每須要搬遷數據，這種數據的遷移會不會佔用大量的網絡帶寬、磁盤 IO 以及 CPU？進而影響在線服務？ 怎麼作負載均衡的？
先簡單瀏覽下上面的問題，給大腦留一個映像，再看後面的，題目讀不懂也沒事。學習
感受PD就是運維，維護tikv節點。翻譯
Store都已經下線了，PD怎麼把上面的Region都調度走？code
信息->策略orm
一個 Raft Group 中的多個 Replica 不在同一個位置
這個沒看明白，大概意思就是講Region副本的位置。
副本在 Store 之間的分佈均勻分配
Leader 數量在 Store 之間均勻分配
各個 Store 的存儲空間佔用大體相等
控制調度速度，避免影響在線服務
支持手動下線節點
調度的實現
總結
2020/10/16~2020/10/19 補全zoom會議筆記
issue背景
#2950 來自於 #19805，由於知識點太多，因此須要所有圍繞這兩個issue查找資料，不能擴散，還有就是affinity based range placement · Issue #19805 · pingcap/tidb和Supports co-balance range group · Issue #2950 · tikv/pd。 翻譯了 Supports co-balance range group #2950 · Issue #1 · eatcosmos/pd 翻譯了 affinity based range placement #19805 · Issue #2 · eatcosmos/pd 翻譯了 process cop request by tikv instance instead of region #19381 · Issue #3 · eatcosmos/pd
翻譯了幾個issue，好像懂了很多，其實啥都沒懂，看來仍是要把高老師講的複習下，學習就是不斷輸入信息，輸入多了，會自動地聯繫起來就理解了。
繪製了一個流程圖：
還有一些感受矛盾的地方，不要急着解決，放着問老師隊友，或者多看幾遍而後出去走走大腦會自動理解。
在線版：https://www.processon.com/view/link/5f8d89981e085307a095bfef