国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

TiDB集群在線服務器停機維護主機資源

IT那活兒 / 661人閱讀
TiDB集群在線服務器停機維護主機資源

點擊上方“IT那活兒”公眾號，關注后了解更多內容，不管IT什么活兒，干就完了！??！


  
TiDB集群環境隨著業務的增長，現每臺虛擬服務器（8C+16G）資源已經難以滿足業務需求，需對現有的虛擬服務器進行縱向擴容操作，將虛擬服務器資源擴展到16C+32G。
生產環境集群混合部署如下：

由于TiDB-server層是無狀態服務，并且有Haproxy進行流量負載均衡，TiKV和PD層有Raft協議的高可用保障，停止單臺服務器進行維護對整個集群運行沒有太大影響，但是集群會存在有某些SQL訪問、在線DDL延遲抖動的情況，總體影響不是太大。延遲抖動主要有以下原因：

  • 存在TiKV層Leader region正好在停機維護的服務器上，從而出現Raft重新選擇Leader region，業務已經在運行期間部分SQL在訪問中由于找不到原Leader信息會出現Backoff的情況，從而SQL訪問伴隨有延遲的情況。

  • PD層Leader的轉移類似TiKV，TiDB-server層中owner轉移需重新選擇新owner會對正在執行中DDL有影響。

在線停單臺服務器升級CPU、內存的大致維護流程：
  • 在停單臺服務器進行維護操作之前梳理DM同步到TiDB的任務，確保同步不失敗。
  • 調整max-store-down-time參數(默認30分鐘，如果停機時間超過30分鐘，建議調大此參數)。
  • Tiup正常停止該節點的TiKV、PD、TiDB實例。
  • 服務器停機。
  • 服務器維護。
  • 服務器啟動。
  • 啟動該節點的TiKV、PD、TiDB實例。
  • 觀察Grafana PD相關的metric信息以及Dashboard訪問情況。

  • 應用檢查業務使用情況。

停TiKV組件

通常情況下，線上集群對 TiKV 的部署是單機單實例或者單機多實例，在對服務器做臨時維護時，需要根據部署情況來進行相應的處理，由于現網為單機單實例只做對應的描述；在實際維護中TiKV節點下線過程中Leader region調度對集群的服務影響很小，并且Leader region調度速度也較快。

注：以下運維命令均為其他環境，實際需根據情況對應進行命令更新。

單機單實例臨時關機維護步驟：

  • 修改 max-store-down-time 超過服務器維護時間，默認 30 min，保證在服務器維護期間不發生補副本行為（需要注意維護完成后將參數恢復。）

tiup ctl:v5.0.0 pd -u http://{PDIP}:2379 config set max-store-down-time 60m // 
修改為60分鐘，根據實際情況而定

  • 檢查是否有 label，確保沒有標簽（如果存在標簽需要多帶帶分析是否為單機多實例的情況。）

tiup ctl:v5.0.0 pd -u http://{PDIP}:2379 label
  • 檢查所有服務器上store的情況，找到該服務器的對應的store id。
tiup ctl:v5.0.0 pd -u http://{PDIP}:2379 store

  • 遷移該服務器上所有 store 的 leader到其他節點。

tiup ctl:v5.0.0 pd -u http://{PDIP}:2379 scheduler add evict-leader-scheduler 2 // 
把 store 2 上的所有 region 的 leader 從 store 2 調度出去

  • 檢查 leader 情況：

tiup ctl:v5.0.0 pd -u http://{PDIP}:2379 store 2  // 
檢查該服務器所有 tikv 節點上的 leader count，leader count數量為 0 進行下一步，否則等待為0

  • 停止Tikv組件：

tiup cluster stop tidb-test -N {TiKVIP}:20160

停PD組件

通常大多數的線上集群有3 或5個PD節點，如果維護的服務器上有PD 組件，需要具體考慮節點是 leader 還是 follower（以下1 和 2 兩部分），關閉 follower 對集群運行沒有任何影響，關閉 leader 需要先切換，并在切換時可能存在短暫性能抖動。

1. 當前服務器包括一個 PD follower 節點且集群 PD 總數 >= 3

  • 檢查當前待操作 PD 集群節點信息：

tiup ctl:v5.0.0 pd -u http://{PDIP}:2379 member //顯示當前所有成員
tiup ctl:v5.0.0 pd -u http://{PDIP}:2379 member leader show //顯示當前Leader成員

  • 停止當前待操作 PD follower 節點：

tiup cluster stop tidb-test -N {PDIP}:2379

2. 當前服務器包括一個 PD leader 節點且集群 PD 總數 >= 3

  • 檢查當前待操作 PD 集群節點信息：

tiup ctl:v5.0.0 pd -u http://{PDIP}:2379 member //顯示當前所有成員

  • 檢查當前待操作 PD 節點角色：

tiup ctl:v5.0.0 pd -u http://{PDIP}:2379 member leader show //顯示當前leader 的信息

  • 遷移 leader 節點：

tiup ctl:v5.0.0 pd -u http://{PDIP}:2379 member leader transfer pd-id // 將 leader 遷移到指定成員pd-id

  • 檢查遷移結果：

tiup ctl:v5.0.0 pd -u http://{PDIP}:2379 member leader show
tiup ctl:v5.0.0 pd -u http://{PDIP}:2379 member //顯示當前所有成員，遷移成功進行下一步，否則等待

  • 在待維護服務器上執行停PD節點：

tiup cluster stop tidb-test -N {PDIP}:2379

  • leader 遷回（可選）：

tiup ctl:v5.0.0 pd -u http://{PDIP}:2379 member leader transfer pd-id // 將 leader 遷移到指定成員

停TiDB-server組件

一般情況下，線上使用TiDB會搭配負載均衡使用，在停掉Tidb-server組件之前需確定負載均衡是否需進行對應調整。

1. TiDB-server實例維護

停實例：
tiup cluster stop tidb-test -N {TiDBIP}:4000
2. 風險點
在進行停止TiDB-server 節點時，如果當前節點為 owner 節點（curl http://{TiDBIP}:10080/info ）且正在進行 DDL 變更，直接停止TiDB-server節點會進行新的 owner 選舉，DDL變更會變慢。另外如果當前節點非 owner 節點，在停掉之后有 DDL 操作時，每個狀態變更時也會去訪問該下線的節點，會對集群 DDL 操作有影響，因此盡量避免在臨時停止TiDB-server時以及期間進行DDL操作。

在實際生產環境中，TiDB集群經常會和DM（數據同步工具）配合使用，在停單臺服務器進行維護操作之前需認真梳理DM同步到TiDB的任務，如果DM工具的目標端是直接連接的TiDB-server，在停服務器維護之前需要對DM工具的Task任務進行調整，停掉DM任務連接的TiDB-server節點會導致同步任務失敗。

停grafana、alertmanager、prometheus

中控節點包含多個組件，在停服務器需添加如下組件操作：
  • 停grafana：
tiup cluster stop tidb-test -N {grafanaIP}:3000

  • 停alertmanager：

tiup cluster stop tidb-test -N {alertmanagerIP}:9093
  • 停止prometheus：
tiup cluster stop tidb-test -N {prometheusIP}:9090

關停服務器前檢查

  • 檢查集群狀態，對應的服務器的組件是否都完全停掉。

tiup cluster display tidb-test

停服務器升級CPU和內存并重新啟動。

啟動服務器后檢查集群狀態

  • 檢查集群狀態，是否都正常。

tiup cluster display tidb-test

所有節點都完成后調整參數

  • 修改 max-store-down-time 超過服務器維護時間，默認 30 min，保證在服務器維護期間不發生補副本行為（需要注意維護完成后將參數恢復。）

tiup ctl:v5.0.0 pd -u http://{PDIP}:2379 config set max-store-down-time 30m // 默認30分鐘


本文作者：陳 聰（上海新炬王翦團隊）

本文來源：“IT那活兒”公眾號

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/129344.html

相關文章

  • Cloud + TiDB 技術解讀

    摘要：作為一個開源的分布式數據庫產品，具有多副本強一致性的同時能夠根據業務需求非常方便的進行彈性伸縮，并且擴縮容期間對上層業務無感知。另外本身維護了數據多副本，這點和分布式文件系統的多副本是有重復的。 作者：鄧栓來源：細說云計算 作為一款定位在 Cloud-native 的數據庫，現如今 TiDB 在云整合上已取得了階段性的進展。日前 Cloud TiDB 產品在 UCloud 平臺正式開啟...

    JouyPub 評論0 收藏0

  • 貝殼金服 TiDB 在線跨機房遷移實踐

    摘要：截至年底，貝殼金服業務已覆蓋全國多個城市及地區，為超過萬用戶提供了金融服務。老機房下線完成則表示數據遷移完成。機房遷移實施過程操作描述配置防火墻，將兩個機房所需端口開通。執行下線命令，一次性下線所有舊機房的?？鐧C房遷移，網絡延遲不能高于。 作者介紹 ：李振環，貝殼金服數據基礎架構負責人，目前負責數據平臺和企業級數據倉庫開發。 公司介紹 貝殼金服是專注居住場景的金融科技服務商，起步于2...

    Ashin 評論0 收藏0

  • CNCF案例研究：PingCAP

    摘要：中國論壇提案征集月日截止論壇讓用戶開發人員從業人員匯聚一堂，面對面進行交流合作。贊助方案出爐多元化獎學金現正接受申請即將首次合體落地中國 PingCAP將其TiDB數據庫平臺押注在云原生上 showImg(https://segmentfault.com/img/bVbogKp?w=508&h=477); 公司：PingCAP地點：中國北京和加利福尼亞州圣馬特奧行業：軟件 挑戰 流行的...

    h9911 評論0 收藏0

  • CNCF案例研究：PingCAP

    摘要：中國論壇提案征集月日截止論壇讓用戶開發人員從業人員匯聚一堂，面對面進行交流合作。贊助方案出爐多元化獎學金現正接受申請即將首次合體落地中國 PingCAP將其TiDB數據庫平臺押注在云原生上 showImg(https://segmentfault.com/img/bVbogKp?w=508&h=477); 公司：PingCAP地點：中國北京和加利福尼亞州圣馬特奧行業：軟件 挑戰 流行的...

    notebin 評論0 收藏0

  • 私有云怎么搭建之智能調度

    摘要：智能調度系統實時監測集群所有計算節點計算存儲網絡等負載信息，作為虛擬機調度和管理的數據依據。當有新的虛擬資源需要部署時，調度系統會優先選擇低負荷節點進行部署，確保整個集群節點的負載。智能調度是 UCloudStack 平臺虛擬機資源調度管理的核心，由調度模塊負責調度任務的控制和管理，用于決策虛擬機運行在哪一臺物理服務器上，同時管理虛擬機狀態及遷移計劃，保證虛擬機可用性和可靠性。智能調度系統實...

    ernest.wang 評論0 收藏0

發表評論

0條評論

IT那活兒

男|高級講師

TA的文章

閱讀更多
最新活動
閱讀需要支付1元查看
<